9 Comments

  1. Dominique Pijnenburg
    · Reply

    Taking away the build process would be great. We, as PHP developers, can relate exactly to how we are described in the article. In the end we could/should probably transition to the build process, but if that was not necessary that would be so much better.

    Report

  2. David McCan
    · Reply

    This would be great. There are probably a number of plugins that haven’t been updated to use Gutenberg yet and this would make it easier to do so.

    Report

  3. Stephen Vaughan
    · Reply

    If the classic TinyMCE interface is taken away what happens to WooCommerce and the product editing screen?

    While the technical conversation above may be interesting to some, for many usability is more important. The block editor is a great progression but for some use cases it doesn’t offer a great solution.

    The article touches on ACF and you could add Toolset as well. Apart from the tools that these bring to someone designing a site, at the far end of a project, when it is handed over to the end user, some things are missing.

    In the older interface you could set things up with just the required custom fields for a custom post type. The user only needs to concentrate on the key data that needed to be entered. Now the same user needs to think and work through the block editor on each post. Where the key information for a CPT is fronted by a uniform template, the block editor only adds cognitive load and is inefficient. From a time and motion point of view the older meta box with custom fields setup is more efficient.

    It is in catering for these scenarios, even if they seem like edge cases, that I see more value than full theme editing. I am sure that it is not beyond the bounds of the Gutenberg team’s capability to address this, with options to set up a UI that removes the standard bloc editing tools and leaves a simple arrangeable meta box system. In any event Automattic will ultimately have to find a solution for WooCommerce products once the classic editor is pulled.

    Report

  4. Jason Lawton
    · Reply

    This is what advanced custom fields has been doing for a while now.

    Report

    • Justin Tadlock
      · Reply

      Similar but not exactly the same. ACF Pro utilizes server-side rendering (at least the last I checked). That means refreshing from PHP each time an option is changed instead of reacting to changes live. SSR can be reasonably fast and works well for a lot of situations, but it is can also be a clunky experience.

      Report

  5. Page Wood
    · Reply

    I immediately thought of Laravel Livewire as I read this. Perhaps the Gutenberg team could take a look for some inspiration: https://laravel-livewire.com.

    In many mays, Laravel has been leading the charge in pushing PHP development forward for some time now. It would be great to see WordPress try to do some of that as well, as opposed to just focusing on betting the farm on Javascript.

    Report

    • Jason Lawton
      · Reply

      One of the core tenants of WordPress is backwards compatibility. This will always keep it from leading the charge like Laravel might.

      Report

  6. Eric Karkovack
    · Reply

    I love this. The more we can do to simplify the process, the better. It’s going to encourage more designers and developers to adopt Gutenberg.

    Report

  7. CW
    · Reply

    As a custom themer and php dev, I threw myself into learning block creation a couple years ago, surmounted the biggest learning hurdles… and then decided that creating blocks for clients was a bad idea.

    First, the editor code was changing too fast. With much effort I’d created a new subhead block that would appear below the title in the editor but save data to post meta. It took me countless hours to figure out that my block wasn’t working because post types have to support custom fields or the editor won’t save to meta. Then as soon as I finished it, the source = meta feature was already deprecated. My clients don’t want to pay an arm and a leg for maintenance, and I don’t want to build something that will break in a year. The php I write is really stable.

    Second, the block editor hasn’t had anything akin to php templating, where the layout is consistent (and updatable!) but the content is filled out on a per post basis. Blocks are deliberately designed so you can’t update the html and have it apply everywhere. Reusable blocks have the same content. Maybe block templating is at least approaching this? But templates aren’t designed for post content as far as I know.

    Last, particularly with the poor documentation, the learning curve is high enough that I’d have to be making blocks somewhat regularly to really get comfortable with it. If I was a full time dev and not also a designer etc that might be viable, but as is, it simply isn’t. My clients don’t need custom blocks often enough.

    I haven’t used ACF blocks yet because it doesn’t offer the editor’s visual interface (though I agree with Stephen that sometimes form fields are better). Instead I’ve been sticking with styles, patterns, variations, and php for now, and hoping the whole dev situation will improve. This proposed solution certainly looks like a smooth on ramp and I’ve love to try it, but it won’t fix everything because the issue isn’t just that initial learning hurdle or that php devs aren’t interested in trying new things.

    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: