1 Comment

  1. Stephen Vaughan
    · Reply

    While, all these new additions are to be lauded in terms of ambition, I would like to see WordPress more focused on getting the block editor properly implemented and polished. Yes, the upcoming improvements in WordPress 5.5 will be a big step up for the block editor.

    But, now that we are getting used to the benefits of the block editor such as saving without having to reload the UI in the browser, is it not time for Auttomattic to give us these benefits on the back end of WooCommerce products?

    WooCommerce opperates primarily in the realm of metaboxes. That’s all you need for data entry. So, I don’t see too much work to done there. Just strip out the the block building side of things. The front end should be provisioned by templates in any event: build once, use many times.

    I have, in fact built a rudimentary plugin (for personal use) for custom posts types where the purpose is to just show the associated custom field groups in metaboxes in the block editor. It’s designed for clutter free data entry. The client can’t screw things up by a sudden urge to add loads of elements in the block editor part because I have that part of the block editor styled out. In any event, disastrous creations would not appear anyway because a template is slapped on the front end to ensure uniformity and correct layout of elements and data provide via the custom fields.

    There is nothing wrong with the block editor in and of itself. It is quite a good solution out of the box but suffers from things like a plethora of third party block solutions to add extra functionality to things like headers fo example. The result is many blocks doing the same thing but different interfaces to apply things like padding. The danger, down the road is that the third party plug is disabled, not developed anymore or, and other myriad of issues leading to the block malfunctioning. If third party block solutions were designed to override core blocks they are disabled, the core block and content is not effected.

    The beauty of overriding blocks is that it would also address the whole question of page builders. To use or not to use? By providing an API to override block elements, builders such as Elementor, Beaver Builder or Divi could integrate over the block system by adding their own functionality and interfaces. If any of these are not to anybody’s taste, at least if they are disabled the content would remain intact.

    I suspect though, anything as sensible as this is not considered by the people behind the Gutenberg project because the agenda there is to deprecate what they call the mystery meat of things like short codes and and metaboxes and to create something proprietary in the vain expressing an opinionated view on how things should be done. The problem with this is it doesn’t take into account many practicalities and in a funny way introduces it’s own new world of mystery meat.

    Report

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: