I’ve been testing the block editor continuously since the beginning, comparing it to the page builder I use everyday. As a method of getting content laid out on a page it definitely has its merits. I will use it say for post content, if the site has a news/blog element to it.

But, when one goes to apply it to anything other than this things get pretty hairy. Exploring the latest innovation of FSE, while workable, is a lot less intuitive and powerful compared to the better page builders. As mentioned, there is no accommodation for other post types, unless one adds something like Toolset. Again, as mentioned, shortcodes are an issue in FSE. This then means adding, again, other plugins so that we can work with dynamic content.

While Wordpress and the block editor needs to think forward on what needs to be implemented, to make a powerful platform, it has overlooked certain quandaries it purports to solve. One of these was some sort of standardised regulation so that one could switch themes and keep content intact to some degree.

From early on it struck me that allowing plug-in and theme authors to make blocks that covered the same ground as the the base install of blocks was really looking for trouble. I see it again and again. You work up some ideas and layouts, adding in extra blocks to fulfil what the new editor can’t achieve. Layer some of these additions need to be removed and some things collapse or one can’t work with some portion of content as something is missing.

This should have been though through from the inception of the block editor. A strict selection of blocks should have been implemented for structure (sections, rows, columns) and the main content elements. After this no other implementation of these should have been allowed, the exception being blocks with specific purposes not covered by the block editor. The base instal of blocks should be reasonably basic, with at least spacing and main typographical controls where necessitated. There then should be a powerful mechanism to allow third party plugins, themes and page builders to hook into this and override it so that their own bells and whistles and UI could be added. Change/turn off themes, builders or plugins and at least content and layout would remain intact. All third parties would be asked to conform to this standard, to some degree at least.

Other thing of note that the block editor lacks.

It isn’t very good at presenting breakpoint previews in the editor. You need something like Toolset or Kadence to achieve anything that is code to a real life representation in terms of spacing and then this is often not as good as some of the better page builders.

When it comes to templating, the block editor leaves a lot to be desired. It has abandoned the concept of separating the content from design and instead mashes things up with patterns and reusable blocks. This has been addressed to some degree with FSE but there are far better solutions out there in the form of page builders and Toolset.

Related to this is a logical UI for working with dynamic content. I work a lot with directories and inventories where content is displayed in a consistant manner through a CPT fronted by a template. On the back end of each post instance all I need or want is a custom post type form for quick data entry. I don’t need the block editor part of the UI getting in the way. I do like how the new editor saves asynchronously without reloading the page so I have had to hack together a rudimentary plug-in that removes the block editor. I see we still don’t get a Gutenberg styled editor fir Woo products?

It seems Matt and the Gutenberg team have been focused too much on the blogging origins of Wordpress and have neglected to recognise all the dynamic ways the platform has grown into. This is a pity because the block editor has a lot going for it.