An alternative to the SharePoint default rich text editor in modern pages: Textbox.io with SPFx

An alternative to the SharePoint default rich text editor in modern pages: Textbox.io with SPFx


When we talk about publishing intranet solutions in SharePoint, we mainly talk about content management and especially content editing experience. Currently the default SharePoint rich text editor Web Part offered with the modern page experience in the only way to add your content in your page…and as you can see, it’s pretty limited:

Default SharePoint rich text editor

In this post, I will show you how to replace this control with a more complete one: Textbox.io:

Textbox.io editor with SPFx

The complete code is available in the PnP Github repository via a ready to use SPFx Web Part:

 https://github.com/SharePoint/sp-dev-fx-webparts/tree/master/samples/react-textboxio

Recurring content editing requirements

Content editing is a pretty common requirement in intranet solutions and this sample comes directly from one of my clients using the new SharePoint communication site to build its a portal. My requirements were basically:

  • Copy/paste from Microsoft Word. Very common and important use case.
  • Styles (bold, italic, etc.) and format (bullets, indent, links, etc.).
  • Headings (H1, H2, etc.).
  • Tables.
  • Images support (Base64).
  • Videos support (coming from Office 365 Videos/Stream).
  • Nice to have: inline mode (make the toolbar appear dynamically only when you click on a text area).

Rich text editors comparison

To fit my client requirements, I had the choice between multiple solutions with pros and cons:

Editor

Pros

Cons

  • Classic and inline mode.
  • Many features
  • Configurable.
  • Supports mobile devices.
  • Supports tables, images and videos.
  • Microsoft Word copy/paste support.
  • Easy to integrate with SPFx via CDN.
  • For a standalone integration, a npm package and typings are also available.
  • Simply does not work when combined with the default SharePoint editor on the same page. If you planned to you use the « Fck-Text » Web Part coming from the SPFx 40 fantastics repository, you will be disapointed.
  • Classic and inline mode.
  • Many features.
  • Configurable.
  • Supports mobile devices.
  • Supports tables, images and videos.
  • Microsoft Word copy/paste support.
  • Available trough CDN or standalone installation (download or npm package).
  • The cloud deployment mode via CDN requires an API key and a registration with authorized domains. It can be complicated when dealing with multiple Office 365 environments.
  • Looks little bit old compared to other editors in terms of UI and configuration.
  • Plugin mechanism no easy to use with SPFx.
  • npm package or direct download available but not so easy to integrate with SPFx (plugin system).
  • No TypeScript typings.
  • React control available. Super easy to integrate with SPFx.
  • CDN available.
  • Light compared to other editors.
  • Nice UI and mobile support.
  • No inline mode.
  • Lack of features compared to other editors (no tables, or enhanced Microsoft Word copy/paste support).
  • Same publisher as TinyMCE (Ephox).
  • Textbox.io is very similar to TinyMCE but even better and modern.
  • Improved code view mode allowing users to edit the HTML markup directly (only in classic mode).
  • Improved mobile and Microsoft Word copy/paste support.
  • Default black UI theme fits very well with the modern SharePoint experience without any changes.
  • No CDN integration, only a downloadable standalone version. Requires you to use your own CDN or include the library direcrtly in your solution (the subject of this blog post).
  • Additional Webpack and gulp configurations required when used in standlone mode.

And the winner is…Textbox.io.

Obviously, if you read the title of this blog post, you deduced that I’ve chosen the Textbox.io option. However, my first choice was CKeditor, but when I saw the issue with the default SharePoint editor, I couldn’t use it anymore because it would not have been sustainable. To explain a little bit more about this specific issue, the default SharePoint editor is actually a subset of the CKEditor third party editor with a custom toolbar.

In fact, when you inspect your page, you’ll see the default CKEditor toolbar is hidden voluntarily in the DOM:

It results that if you want to use your own CKEditor widget, first the toolbar won’t show up for this reason and then, you’ll have plenty of JavaScript errors appearing in the console as well.

Integrate Textbox.io with SPFx

In this sample, I used the standalone version of the library. To integrate it in my code, I’ve followed these steps:

  • Download the Textbox.io client SDK from the official site. Then, copy the textbox.io folder directly in your solution (/src/libraries/textboxio).
  • Configure the library as external in the config.json file:
  • Create a TypeScript definition file (textboxio.d.ts) for methods you need. Refer to the official documentation to know about all available methods:
  • Import the library in your TypeScript file (see TextboxioEditor.tsx). After some issues, I’ve discovered when you used the library outside the local environnement you will need to reference the global variable from the window namespace directly:
  • Configure the editor according to your requirements. For instance, this is where you set available options in the toolbar or copy/paste behavior, etc.:
Then, this is where it comes tricky. To get Textbox.io work, the library needs the « resources » folder is located at the same level relatively to the textbox.io.js file (this check logic is hard coded in the library file). This structure is ensured by the script itself by looking to the current script path according to the « <script> » tag (see official documentation). It means that you can’t include the library code in your Webpack output bundle, you have to keep it external and with exactly the name « textboxio.js« . To do this:

  • Create a gulp task to copy the « /resources » folder into the Webpack output directory and tell the SPFx routine to remove hashes from filenames when the bundle is created:

Deactivate auto hashes in file names in the output folder (gulpfile.js) by overriding the default task:

Warning: doing this could cancel the benefit of the cache mechanism. It means that if you update the code of this Web Part in your tenant, users could not see changes automatically (because the file name never changes) so if you plan to use this solution, I suggest you keep it aside in its own solution (i.e. do not include it in your main project).

Copy Textbox.io resources folder in the Webpack output directory using a gulp task (gulpfile.js):

  • Make the content visible by the SharePoint search

In general, an important point when you implement Web Parts with persisted properties is to decide whether or not the content should be visible by the SharePoint search engine. As a reminder, the Web Part content is not mapped to a specific SharePoint column and is not crawled by default. To make your properties crawlable, you will have first to save your data in the Web Part property bag:

and then, set this property as « crawlable » via the propertiesMetadata() method by specifying the type of content (html, link, image or plain text):

This example is pretty simple (one « string » property) but if you have complex structures (like objects and arrays), you will either have to « flatten » content to persist or use the special syntax supported by SPFx. Then the content will be available through the full text search index or via the « Description » managed property.

Conclusion

Even though new capabilities have been recently announced by Microsoft, the current version of the SharePoint rich text editor is far away from the good old ribbon editor in terms of content editing features. It’s a shame because the CKEditor used as a basis already offers plenty of features that could be used natively. Also, because of the modern experience does not allow you to include page field controls like we had in previous page layouts, you can’t even use a multiline text field with rich text support or publishing field in your page. I do not doubt Microsoft will fill this gap in a near future for such a critical feature.

Being said, with this sample you now have the choice to use the Texbox.io editor in your pages via SPFx instead the default one if you want to offer great content editing experience to your users. Also, this sample can be used as a basis to be integrated in more complex Web Parts.

2 Comments

Add yours
  1. russell gove

    Thanks Frank!
    I had no idea SP used the CKeditor. I have am SPFX webpart that I was using on an editform. The CKEditor kept disappearing on me when I un-hid the out-of-the-box form. Now I know why! Will need to look at textboxI.io in the future. They don’t have an npm installer?
    Russell

+ Leave a Comment