Getting better. Still some way to go, but at least it can be used on production
-
I’m updating my previous review to reflect its current state. Gutenberg is now in a more mature state and can be used on a live site.
It still has a number of bugs and missing features, but it’s finally ahead of our main editor (WPBakery).
Considering the effort devs put into this, it makes me comfortable to start building new pages in Gutenberg and phase out our old editor.
tl;dr
1. Couldn’t make it work in 5-minutes on existing site.
2. Make both gutenberg and classic editor as plugins. Allow people to choose which one to install instead of forcing them to override gutenberg via a plugin.
3. Test user acceptance over at least one major release cycle.
4. Spend time decluttering WP core, move legacy code in a separate plugin and help plugins use custom tables instead of wp_posts and wp_postmeta, to make WC core lightweight and FAST. This would have been better use of developer time with less negative feedback.The review:
I’ve been silently following the reviews for months but never bothered testing, as there was no launch date set. Since it’s now part of the next major release, i decided to test and ensure it’s compatible with our sites.I installed the plugin and activated. I then went to pages so i can test it. To my surprise, the menu loaded, but the right hand side was empty. I thought there might have been a PHP error, but our logs were blank.I then installed the WC gutenberg plugin and checked the products section and they were using the old editor.Since we use Visual Composer and have made some custom shortcodes, i tried disabling VC, but i still couldn’t see any content on the add page section.I then tried replacing the theme with twentyseventeen and that didn’t solve the problem either.I couldn’t spend more time testing and debugging so i switched to another project and will review this again at a later stage.I don’t know if that’s an incompatibility with our site, our custom code or just an option that i need to enable, but either way it’s not a 5-minute task.Unfortunately, WP is forcing this plugin upon everyone on the next major release and i think it’s just too soon. In my opinion, they should make both editors optional and force people to select one or the other for at least one major release cycle. Then assuming the usage of gutenberg is significantly higher, they could replace the old editor or keep both indefinetly.As it stands, if WP releases this into core, we’d need to spend time and money before we can figure out how to make it work on our sites or risk staying on an older version of WP and miss out on security fixes. Alternatively, we’d need to install the classic editor plugin and override gutenberg, which means even more code will have to be included on each page load.The WP core team spent a lot of time building a new editor that a lot of people dislike. Instead, they could have spent time decluttering WP core and make a streamlined platform without legacy junk. To support old sites, you could have moved the old code into a new plugin to be installed by whoever needs it. The rest would enjoy a lightweight system.
-
The people behind https://wordpress.org/plugins/classic-editor-addon/ (yet another plugin) understand much better than me how the Classic Editor works in detail.
I’m pretty sure they would be able to clarify this for you if you wanted to add a support question there.
Just to clarify. As it stands Gutenberg is a REACT override of the current editor and not the other way around. The Classic Editor plugin acts like a switch that disables Gutenberg. Other plugins such as Gutenberg Manager and Disable Gutenberg offer more granular options to disable Gutenberg on a per post or user basis.
In fact you can actually disable Gutenberg without any plugin. For example if you have a custom Post type that is not configured to conform to certain requirements required to allow Gutenberg load, it won’t. WordPress fallback to the current editor.
You can even go one step further and add a filter to the functions.php file if you are the vendor of a Theme or the functions.php file of a child theme if you are a user and this will prevent Gutenberg from loading.
For the moment Classic Editor plugin is recommended as the filter mentioned above is slated for a renaming on the release of WordPress 5 with the result that using it now as a safety net to stop Gutenberg won’t work.
It does beg the question why anything needs to be a plugin as technically both Gutenberg and the current editor (Classic) will be in core. Much of the fuss and fear about Gutenberg could be allayed if Gutenberg only loaded on new installs and an option to toggle on or off Gutenberg was put in Writing settings.
Personally I won’t be using Gutenberg as it does not fit with the workflows and use cases I have developed and use in the last ten years I have been using WordPress. I will check closely how progress goes with Gutenberg and I do expect that now that there is a fair amount of feedback that the development team will be cognisant of this and will make some changes to improve matters.
As it stands Gutenberg is a REACT override of the current editor and not the other way around.
That’s good to know, i don’t think this is properly communicated.
I would still prefer to not include its files (around 90 at the moment) every time a php page or script is called, which is why i proposed to keep it as a plugin. WP comes with the hello dolly and jetpack, so why not pack pre-pack gutenberg but keep it separate to core and optional?
I don’t object to adding guttenberg, but as you say it should be an option that enables it only is the admin selects it on the writing settings. It should be disabled on people who upgrade and could be enabled for new installs.
For the sake of clarity, i figured out that Gutenberg would not load due to REST API Toolbox (https://wordpress.org/plugins/rest-api-toolbox/).
This plugin has an option to remove the API endpoints and we had the pages endpoint removed. Disabling this plugin allowed Gutenberg to load on Pages.
This doesn’t alter my views and suggestions about Gutenberg.
The topic ‘Getting better. Still some way to go, but at least it can be used on production’ is closed to new replies.
