Recently Matt Mullenweg, holder of the dual-hat WordPress Foundation founder/director and the CEO of the for-profit Automattic company, wrote a post on the reasons for Gutenberg. Matt makes many big promises that appear to miss the point of why WordPress is so valuable for freelancers, small business owners, and developers. But before we dive into a look at Matt’s post, let us talk briefly about what Gutenberg is in the context of WordPress.
What is this thing called Gutenberg?
There have been rumblings for a while regarding revamping the WordPress editor into a more modern and user-friendly environment from the tried and true TinyMCE editor. This makes perfect sense for users that are only writing long-form (or short single-focused) content. This also makes sense if we are talking about simply replacing the editor environment for the content.
But guess what, when Gutenberg was initially released (and subsequently iterated), it became apparent that Gutenberg was more than simply providing a modern writing experience but rather an entire editor screen revamp that eliminated meta boxes.
They killed the Meta boxes… WHAT???
With the current direction of Gutenberg, it is clear that meta boxes in the editor environment have become second class citizens. This aspect alone demonstrates the lack of fundamental understanding of what made WordPress so powerful. Those that have been attending my WordPress Developer Courses/Camps over the past 9+ years are already familiar with my phrase, “WordPress is nothing more than a pretty face on a database!”
What does that mean? Let’s break this down to its simplest state.
- Content is stored in the WordPress database.
- Themes interact with the WordPress loop/query to extract content from the database and place the content in a layout dictated by the theme.
- The WordPress editor screens provide simple methods of adding content to the database.
When you firmly grasp that simple cycle it becomes clear that when you are building specific types of sites for clients, you may have to create different types of input fields contained within meta boxes. Before I go too far down this trail, I want to address a number of the sections Matt Mullenweg mentioned in his post to help bring perspective.
Developers and Agencies
Matt was addressing those who heavily use Custom Post Types and meta boxes by basically saying it will all work fine because they can replace meta boxes with the new “block” concept that Gutenberg brings. And that all a developer has to do is to go back and update their old code to work with this new paradigm.
This seems to miss the point that one of the values in WordPress is there can be a stark contrast between structured data and designed content layout. In Matt’s example of an “employee” block that individual content creators could then move and design the employee block into different locations misses the issue that many need “DESIGN” to be different from “DATA ENTRY”. If I’m building a site for a client, they DO NOT want to have to deal with design, they only want to have the flexibility of entering new employee data and have it “magically” appear in the right place, in the right design, and in the right locations.
In this “employee” example, there would be many times you would not even use the Editor field, you would have other fields like phone numbers, staff photo, who their boss is, what department they are in, etc. These types of fields are not “blocks” that can be dragged and manipulated in content editor design field. These fields are ways to provide the client to get data INTO the database so that the theme can EXTRACT the data properly into the designed layout.
There is also the unmentioned usage of meta boxes that are used to store/manage/enter data that will NOT be shown on the front end view of the post. Pushing all this type of data into the new Gutenberg post_content now just throws all of the unstructured data, structured data, and even hidden data into a mixing bowl that will cause more damage to long-term clients and any future development opportunities.
Plugin and Theme Developers
I’ve read many opinions/declarations about Gutenberg and the benefits it will bring to plugin and theme developers. One of the areas of concern is how Matt is saying that Gutenberg will bring a “single entry point”. Let me demonstrate how this “point of entry” is nowhere near simple or single.
- Gutenberg requires plugin and theme developer to write React components.
- These components are needed to interact with WordPress through an API.
- But it doesn’t stop there with the WordPress API… because that API isn’t core code.
- Core code in WordPress is based in PHP.
Matt has also said that “developers will be able to work in modern technology and not worry about 15 years of backwards compatibility”. But this is really hard to take at face value considering the history many developers have been saddled with due to “choices” made by leaders in the past. Here are several historical decisions that you can look up to understand why some don’t trust the statement “Trust me, it will be great!” : shortcodes, wp_kses(), capital_p_dangit(), wpautop().
Gutenberg took the leap and rewrote the entire editor SCREEN not just the editor EXPERIENCE. If Gutenberg wanted to provide a better content creation experience in WordPress, it would have stayed within the boundaries of wp_editor() and not the entire editor page. This fact alone shows that Gutenberg suffered from scope creep from the VERY BEGINNING of its release.
When opponents of Gutenberg raise their voices they appear to be met with the claims of “fear of change”, “don’t want to do work to update sites”, “don’t see the future of the internet”. The fact remains that those pushing the current direction of Gutenberg have difficulty seeing HOW WordPress is currently used OUTSIDE of the blogging/WordPress.COM world view.
Gutenberg may be a great solution for WordPress.com. It may be a great solution for the “page builder” add-on for Jetpack. But Gutenberg, as a full page editor replacement, doesn’t really have a place in the current client/developer environment.
But Ben… you are negative against this why don’t you have any suggestions that would help contribute to the conversation.
There are several options moving forward that I think could benefit everyone:
- Have Gutenberg be an “add-on” for Jetpack that allows users to CHOOSE to use the “experience”. This would also allow Automattic to move forward with Gutenberg being the “default” editor for WordPress.com.
- Integrate Gutenberg into the post_type_supports() function. This way developers/users can specify either editor or gutenberg.
- Keep Gutenberg as a straight WordPress plugin and let it compete with other Page Builders.
What do you think?
Please read Gregory Schoppe’s more technical overview of why Gutenberg is NOT revolutionary.
Fatal error: Uncaught Error: Call to undefined function wpstudio_get_field_value() in /srv/users/serverpilot/apps/enjamin/public/wp-content/themes/voce-theme/templates/content-post.php:37 Stack trace: #0 /srv/users/serverpilot/apps/enjamin/public/wp-includes/template.php(690): require() #1 /srv/users/serverpilot/apps/enjamin/public/wp-includes/template.php(647): load_template('/srv/users/serv...', false) #2 /srv/users/serverpilot/apps/enjamin/public/wp-includes/general-template.php(155): locate_template(Array, true, false) #3 /srv/users/serverpilot/apps/enjamin/public/wp-content/themes/voce-theme/loops.php(39): get_template_part('templates/conte...', 'post') #4 /srv/users/serverpilot/apps/enjamin/public/wp-content/themes/voce-theme/inc/functions/columns.php(10): voce_content() #5 /srv/users/serverpilot/apps/enjamin/public/wp-content/themes/voce-theme/inc/functions/columns.php(87): voce_columns() #6 /srv/users/serverpilot/apps/enjamin/public/wp-content/themes/voce-theme/inc/html/main-content.php(34): voce_columns_singular( in /srv/users/serverpilot/apps/enjamin/public/wp-content/themes/voce-theme/templates/content-post.php on line 37