Issue when executing PowerShell scripts with characters outside of A-Z

I have a PowerShell script in which I pass a parameter to command containing the Norwegian character ø, where the command sets a value on a web page.

When checking the result, it looks like this:

Hvem gjør hva

Clearly an encoding issue. My .ps1 file was saved in UTF-8, and to make it work I changed it to UTF-8 with BOM (byte order mark). This way PowerShell can correctly detect the script as being in UTF-8 and encode the characters correct. To change encoding use for example VSCode or Notepad++.

Summary

If you have characters outside of a-z in your scripts, be sure to save them as UTF-8 with BOM to avoid any encoding issues.

Cover photo by Krisitan Strand at Unsplash

Gotcha when adding Office UI Fabric React to SPFx

(Update for SPFx v1.7 - 2018-11-09)
This post is still valid for SPFx v1.7

When installing a reference to Office UI Fabric React make sure to run

npm i office-ui-fabric-react@lts --save

and not

npm i office-ui-fabric-react@latest --save

Lts is the latest stable version, which currently is v5.122.1 and in this case compatible with React 15 which is what SPFx uses. The latest version is 6.57.0 which require React 16, and won’t build with SPFx.

Stable photo by Ryan Yeaman at Unsplash

Modifying terms using app-only tokens in SharePoint – undocumented work-around

Photo by Alekzan Powell at Unsplash

In a rage of fits yesterday where I was running a PowerShell script against SharePoint Online with an account using multi factor authentication – which just don’t work reliably due to the use of login via web browser I decided to use app-only authentication instead.

I used the following permission manifest which should ensure god rights, right?

<AppPermissionRequests AllowAppOnlyPolicy="true" >
  <AppPermissionRequest Scope="http://sharepoint/content/tenant" Right="FullControl" />
  <AppPermissionRequest Scope="http://sharepoint/taxonomy" Right="Write" />
</AppPermissionRequests>

But since I’m dealing with modifications to terms in this script, that quickly broke down. More rage, more fits!

Reading https://msdn.microsoft.com/en-us/library/office/mt210897.aspx?f=255&MSPPError=-2147217396#sectionSection0 states:

You can't use the app-only policy with the following APIs:

• User Profile

• Search

• Taxonomy (this only applies to scenarios that write to the managed metadata service)

An even better bundle optimization method for SPFx using webpack dynamic imports

Photo by Rose Elena at Unsplash

In my last post I ventured into how you dynamically can load script resources in your SPFx web part or extension. Typically you might have parts only needed in edit mode, or parts only used in certain view scenarios. By not including everything in the SPFx bundle you will reduce loading time and page bootstrapping of your solution.

For example, if you use a lot of Office UI Fabric components or an external library like moment, then your overall bundle size, or downloaded .js file increase a lot. If those components are not always needed, loading them dynamically at will is a better solution.

And, it’s so easy! SPFx uses web pack to create the bundle, and webpack allows for something called dynamic imports. And this is such a golden nugget – sitting there without anyone knowing :)

An adventure into optimizing SharePoint Framework runtime bundle sizes

(See https://www.techmikael.com/2018/08/an-even-better-bundle-optimization.html for an even better solution)

When I wrote the Modern Script Editor web part I went with using Office UI Fabric React (ouifr) for the editor UI. The web part bundle yields a zipped script file of 84KB when used on a page. Not that much really, and it will be cached in the browser. But most of the bundle size is due to the use of ouifr in the edit experience of the web part – not needed in view mode for a page.

Thus I’ve had a nagging feeling working on my mind for a while, and it occurred to me; why can’t I have the editor experience separate from the run-time experience?

And you can!! which I will explain how further in this post.

The result is that the updated web part now will download 4KB zipped on run-time instead of 84KB. A whopping 95% decrease. The editor experience will be another 141KB, which is more in total than before, but this only happens when you edit the page and web part – certainly a good trade off.

Highlighting which page is the welcome page in a site

A week ago Joanne Klein posted a request on twitter where she asked if it was possible to easily see which page is the home page or welcome page of a site. In a library with hundreds of pages, this can be quite useful indeed.

Technically the information about which page is the home page is stored as property on the root folder of the web (almost a mouthful there), which translates to that it’s not stored on the page it self, thus not “easily” set by adding a column.

The developer in me figured I could whip up a quick custom field renderer for the modern page library and have this working in a matter of minutes. Turns out, it’s not that easy. (A field renderer is a piece of code which shows a column value in any way you decide, instead of the default way – for example add a red background color.)

Either way, head over to https://github.com/Puzzlepart/spfx-solutions/tree/master/Pzl.Ext.HighlightHome if you want to download and install a solution which does highlight the home page for you. Install instructions are on that page as well.