A new experience for Planet 4 blocks: the WYSIWYG upgrade
Why and how the P4 blocks switched to the new what-you-see-is-what-you-get user interface
WYSIWYG indicates you can edit your documents in the very same format they are “printed”, for example, selecting a text and making it bold. We take this for granted today, but it didn’t exist in the past, when you had to add special markers in a text to make it print as bold. The WYSIWYG paradigm spread from text editors to every kind of software. Photoshop, for instance, is “WYSIWYG” too in the sense that you can directly paint over a layer and see how it will look in the end immediately.
In the early Internet age, the first forums and blog editors were not as powerful as “word processors” like Microsoft Word, so sites resorted to other solutions for formatting, like adding special brackets around a text: [bold]this[/bold]. Then the web advanced and WYSIWYG or “rich text” editors started to proliferate in content management systems such as Wordpress.
So we started seeing this “Word-like” kind of interface:
Of course making a text bold or painting over a photo are very basic examples, what about more complex content? How do you edit a 3D pie chart in the same place you’re seeing it?
As content creation moved more and more out of paper and into the digital realm, interfaces became more interesting as screens can do much more than paper.
The New Kid in the Block
So what’s the state-of-the-art in terms of WYSIWYG editing of digital documents? The industry’s response seems to be “block editors”. This new paradigm has been adopted by some of the most influential players like Medium, Notion and Wordpress (see the Planet 4 adoption of Gutenberg), which all ended up in organizing content in “blocks” rather than treating the whole doc as a page with formatted text.
These blocks can have different options and UIs depending on the content they contain: there are Heading, Paragraph or Image blocks, or pretty much anything you can imagine put on a website. Videos? Yes. 3D Content? Of course. Can you have Mario Kart in a block? That’ll take longer, but yes 🏎️.
From Rich Text to WYSIWYG, from Shortcodes to Gutenberg
With the adoption of Gutenberg, Planet4 now has a series of blocks specifically designed for the type of content editors need to create.
The new editor offers a much better experience, a wide variety of WYSIWYG blocks and a complete API to integrate with the different sections of the UI. This toolset enables richer experience for editors, allowing total visual consistency from editing time to the final result on a page.
With the WYSIWYG approach, P4 blocks in edit mode look exactly the same as in the frontend site, with most of their elements editable in place and some options moved to the right sidebar, with a specific tab to add block properties without overloading the main editor panel. The sidebar also includes real-time previews of different styles for the same block, which change as you edit the block properties.
Technical Bits
Built using React (actually, a wrapper around it), Gutenberg blocks are “registered” to make them discoverable by the WP API and added into the collection of blocks for editors to browse. After following some conventions from WP’s Block Editor Handbook, you can do pretty much anything using React components.
As the site is powered by PHP, rendering the stored content is a bit different than in a typical single-page React application. Depending on the type of block there are a few options to render the blocks in the final site:
- Static blocks: the block is stored as pure static HTML in the database, WP outputs that content directly.
- Server side rendered blocks: no content is stored in the database, only the blocks’ options and attributes. Then the rendering is handled by PHP from those attributes.
So far these are the “canonical” ways of rendering blocks as suggested by Wordpress. WP does not enforce the use of React on the frontend site, actually there is no documentation about it. So at Planet 4 we came up with our own way of including React components in the frontend site:
- Standalone React blocks: we store a placeholder <div> with the block options as data- attributes, and then we inject React components into those placeholders.
This approach has the advantage of being able to render dynamic blocks without resorting to PHP for handling dynamic attributes, using the same React code for the editor and the site. Of course there is caveat: we are shipping React to the frontend, which increases the page load and there could be a hit in performance but we are working on strategies to minimize the impact.
To dig deeper in this, have a look at these slides from one of the latest P4 Dev Community Call or check out the video recording below:
What’s Next?
We are still continuously refactoring the way we render blocks in the frontend to improve performance, save content statically where possible and avoid flashes of “unstyled” content in the web. We won’t go further in this post but please, if your Organization is planning to / has completed the switch to WYSIWYG or you plan to do it differently or if you want to dig deeper in our render flow please reach out! You can leave a comment below, tweet at #planet4 or send the team an email. We regularly also host community calls about these and other tech issues.
Last but not least, in the upcoming Greenpeace Tech Camp, we’ll probably host a session about the lessons learned in one year of developing with Gutenberg. Stay tuned.
Originally published on October 15, 2020.
