SharePoint Online for a long time, has multilingual support. On classic experience, there were language packs and Variations available for that. Yet also the modern experience has multilingual capabilities for that.
It might look that SharePoint is well capable of providing the language chosen by the user for the user. While I had to take a closer look under the hood over the last couple of month, multilingual and SharePoint has a complicated relationship.
Over the last couple of days, I banged my head against the wall. I hate when things don’t work as expected. On the other hand, I love challenges.
The thing we are talking about the documentation on “Supporting section background“. To be clear, the documentation is correct. It works as described. The issue I and many others have with this documentation it does not apply to your project.
This time we take a look at the fundamentals on the page and text layout on modern SharePoint pages in communication sites. The text layout is the essential design element on web sites and the intranet. 95% of a current information system is base on just text.
First, let us define some basics on typography on the web to have a better understanding later on the available layout options we currently have.
When you like to version your SPFx solutions correctly, then it is not enough to upgrade only the ‘package-solution.json’ in the config folder. You might also want to upgrade the ‘package.json’ file with a corresponding version number too.
Whenever you save a TypeScript file in your SPFx project, the build chain creates a new build and refreshes the local workbench automatically.
There are some situations you like to have this support for other asset or frameworks too. In most cases with the PnP/SPFx generator, we need to force a build when a Handlebar or VueJS file get saved.
So the goal is to hijack the build process and add some custom file watch based on the requirement of the framework or file. Why file? Imagine you have an SVG file in your solution. The expected outcome is that you see the changes immediately in your browser.
The key word to this is watch. It requires a custom file extension watch that than trigger the build.
When you write a new web part with the SharePoint Framework you might create a genius web part, where all the business logic is compiled into your web part. This approach makes sense when the web part is an isolated piece of work.
Sometimes you like to write pretty simple web parts that only access a backend or third-party API from somewhere on the Interweb. In this case, you can write all the data access inside your web part. Give the user the option to store APP Key, APP Secret and particular access token directly in the web part. Might pre-populate some of those properties of with your company-wide secrets and API keys too.
Microsoft recently released the new Communication Site template. It is a great first look into a new way to publish web content in SharePoint only.
Sadly some important features are missing yet in the first version of this new site template. One of such things is the creation of new content pages based on templates.
When you like to create two pages that should look identical, but with different content, all web parts need to be placed in the same order as you have added them previously.
Luckily there is a workaround to the missing page layouts.
When you create a new project without any framework, the default web part content in the code will be added through innerHTML.
Technically there is nothing wrong with this approach, but you might run into a problem when you add more content to the web part afterward using the same method. In this case, the previously added content will be overwritten.
To avoid this behavior, you can use jQuery and the ‘append‘ or ‘prepend‘ methods to add your content. It works well but requires an external library.
Instead of using jQuery, there is a native method in the document object model of HTML available.
This was actually the first question I asked after the new framework has been released. Since then there has been an ongoing discussion on that issue.
When you created a new project using a yeoman generator you’d expect a proper gulp/grunt/whatsoever file that list all the task required to build and develop the project.
When you open the gulp file of the new SharePoint Framework you see just the following lines of code.
The rest of the SharePoint framework is well hidden and deeply nested inside the node_modules folders. Theoretically, you can whatever you like in this folder, but your changes will get lost whenever fresh version will be checkout out form the source control and/or npm install will be exited, upgrade your project to the newest drop of the SharePoint Framework or install an updated version of any package. The node_modules folder is the _layouts folder of the new SharePoint Framework but you can be sure that files in there will be always replaced.
My mate Waldek wrote a great blog post on how to extend the SharePoint Framework with a custom build task.
I think his article is suitable for a deep integration in the SharePoint Framework. From my point of view, it solves a problem that exists because of the Framework.
I working with yeoman generators for more than two years now and I’ve never seen a gulp implementation that only contains of a simple function call. The new SharePoint Framework follows in this case a pretty uncommon approach. I was clueless for a while.
In SPFX everything is built on gulp and it turn’s out that adding a custom gulp task is much simpler than I have expected. However, sometimes it is hard to see the forest for the trees.
Let me explain how to accomplish the same thing Waldek describe just by standard gulp methods but first let me explain some basics.