Gutenberg Development Team Confirms Meta Box API Will Not be Formally Deprecated

photo credit: Doors Open Toronto 2008 – Toronto Archives(license)

The discussion surrounding how Gutenberg will handle meta boxes heated up over the weekend after a participant commented on the GitHub issue with concern regarding meta box support being removed from the most recent milestone.

“I see this vital issue has been removed from any milestone,” @steveangstrom said. “It has been de-prioritized again while bells and whistles for blog editing get lots of work and are added to betas. This is very worrying for the future of WordPress as a CMS.”

James Nylen, one of the lead developers on the project, reassured followers of the topic that the Gutenberg team has not forgotten about the issue but rather that it is “an extremely complicated issue that we are only beginning to look into, along with many, many other priorities for getting the editor working well.” He also asked for help from the community in planning and testing implementations for supporting meta boxes.

This response left many things unclear. Participants in the discussion, many of whom are developers concerned about about the prospect of having to rewrite all of their meta boxes as React components, are wondering why meta boxes cannot work alongside the new Gutenberg editor and why the team chose to include meta boxes in the scope of the project.

“Is it possible to replace the existing TinyMCE post editor with Gutenberg while leaving the rest of the interface, including meta boxes and existing hooks, unchanged?” Kevin Hoffman asked. When Nylen clarified that Gutenberg, as written today, is intended to be a post_content editor, Hoffman summarized the concerns that many developers have expressed:

If Gutenberg is truly intended to be a post_content editor, then meta boxes should be left alone as they are not concerned with post_content.

Furthermore the need for an API to translate PHP meta boxes into React meta boxes is a manufactured problem. It does not have to be a problem, but it has become a problem because somewhere along the line it was decided that rewriting the post_content editor should also completely change how meta boxes work.

You’ve outlined the tremendous challenge of writing such an API in #2251. Translating PHP meta boxes into React for a popular custom fields solution like ACF is challenging enough, let alone trying to do so for every meta box implementation that exists today, popular or not. It does not scale.

As the Gutenberg contributors shared that they have only just begun to look into the meta box issue, it’s now clear why there is no roadmap for how the project will handle “legacy” PHP meta boxes. In July, Nylen said, “If I had to guess where we will end up here: current metaboxes will be moved to a “legacy” area and we will provide APIs, documentation, and examples for registering ‘new-style’ metabox-block-thingies.”

Plugin developers who manage meta box libraries, agencies, and other concerned parties are following the ticket to find out how to plan for the WordPress 5.0, which has been targeted as the Gutenberg release. Andrey Savchenko asked if WordPress plans to formally deprecate the meta box API, which finally drew a clear answer from the team. Matias Ventura responded:

“Does WordPress intend to formally deprecate Metabox API?”
No.

The question that is not fully answered yet is how do meta-boxes work in the context of the Gutenberg editor. Should they remain the same or evolve? How can we move towards the design goals with the least amount of disruption possible?

This issue has been lingering not due to a lack of desire, but lack of resources. The primary focus for this project is to offer a rich content editing interface that optimizes for direct manipulation of user content through the notion of blocks. (Having used meta-boxes extensively for various projects, I believe blocks can offer a better step forwards for many of those needs while providing a better user experience.)”

Ventura listed several options the team has considered for handling meta boxes and requested help from the community to build the best solution:

  • If we detect a meta-box is registered we can fallback to the old interface, nothing changes.
  • We could split editing the content and modifying meta information into two screens or stages.
  • We can try to see how feasible it is to render these as they are (PHP) below the content: #2251.
  • A theme/plugin/CPT could unregister the new interface as needed.
  • Various items that relied on meta boxes could be converted to blocks for UI (still storing data separately).
  • We could implement API based meta boxes extensibility like the Fields API.

When pressed to answer the question of why meta boxes are being included in the context of the new editor, Gutenberg design lead Joen Asmussen clarified how the team decided to include meta boxes in the scope of the project:

Gutenberg did start just with the editor box. The kickoff goal was to unify multiple disparate interfaces under a single unified block interface. It quickly become apparent that in order for us to create a compelling experience revolving around this unified block interface, we had to consider the full writing flow, including settings and publishing.

If the key strength of WordPress is to make it easy for anyone to create rich posts, then we can’t just design for those of us who already know how to use the editor. We have to consider users who’ve never used WordPress before, and what they expect in a modern publishing interface. Otherwise we’d just be adding cognitive load to an already heavy interface.

The question of how meta boxes will fit into the context of the Gutenberg editor is still open. Participants in the discussion are eager to have this question answered for the sake of backwards compatibility and also because it affects ongoing decisions regarding Gutenberg development and screen design.

“I completely get how much work has been done towards the ‘screen’ replacement approach,” Xavi Ivars commented on the issue. “But shouldn’t a project that started with the goal of a ‘post content editor’ replacement, have gone back to the community before deciding unilaterally that it would replace the whole editor screen?”

The meta box API isn’t being deprecated but there’s also no clear path forward for how Gutenberg will support “legacy” PHP meta boxes. The Gutenberg team said the issue has not been solved due to lack of resources. The project needs community input and better communication if the team is going to land on a solution that will seamlessly usher the majority of WordPress sites into the Gutenberg era with the least amount of breakage.

Currently, the feasibility of rendering legacy PHP meta boxes below the content is fraught with challenges and still up for debate. If there isn’t enough time or client resources for developers to rewrite their work into JS-driven meta boxes, then a clear path for opting out of the Gutenberg interface may be necessary for sites that need to preserve the legacy “PHP” meta boxes.

37

37 responses to “Gutenberg Development Team Confirms Meta Box API Will Not be Formally Deprecated”

  1. Meta boxes is only 50% of the battle for developers. How about the custom TinyMCE buttons that countless themes and plugins use to generate shortcodes among other things?

    There is a reason why Gutenberg has so many 1 stars in wordpress.org. It has to stay as a plugin, or at least have an option in the settings to get rid of this disaster and go back to TinyMCE that most of us prefer. It should be an alternative to TinyMCE and not a complete replacement, this is so dumb it’s not even funny anymore. Do they understand that thousands of themes and plugins will be broken? Do they even care?

    • I worry about these issues too. Thanks for bringing them up. I agree with you that Gutenberg would make an excellent plugin.

      If not a plugin then what about handling this whole situation like Windows for example. They support the older versions for a period of time, case in point currently Windows 7 is still supported with security updates. Could security updates for WP TinyMCE continue for a while giving folks time to catch up after WP Gutenberg is released?

      • Gutenberg would make an excellent plugin!?!?!?!?!

        What drugs have you been taking???

        Right now Gutenberg looks like bloatware as we do not know how any plugin will even work with this interface.

      • I’m sorry Sue that you misunderstood me. I never said that Gutenberg, the worst joke Automattic could ever play on us was an “excellent” plugin. I merely commented that it should stay as a plugin and never infect the core with this stupidity. 2 of out 5 like it, so let them use it if they want to. However, if they replace TinyMCE with this %$#@, they are taking OUR choice of choosing how to work. Keeping it as a plugin, is all about the freedoms and choices, but adding it to the core that the vast majority don’t need, don’t want, and simply downright hate, is like a socialist/communist government shoving things down our throats.

        @Richard: I agree with you almost 100%, and I can add some $%#@ behind your sentiments as well, but Sue is not the enemy here. I feel your anger, and multiply it by 1000 times, but our rage should be towards the developers. I read their Development posts and comments today, they are tone def and live in a bubble, surrounded by “yes” people. They realize that some of us have “anxieties” about Gutenberg, and in the comments section, they marginalize the amount of push back. They think they are having messaging issues, and not the product itself. And I bet, they think we are too stupid and uneducated that do not understand what Gutenberg is all about. They think that if they promote Gutenberg, that will fix everything. They are so tone def and wrong, it reminds me of the US presidential elections of 2016!!!

        Let me make it clear for them. We have dozens of capable page builders, that do not break anything, and are 1000 better than Gutenberg. Gutenberg is 5-6 years late, and it does not even have column support. There is no point and no need for it. What is the real hidden agenda behind Gutenberg? Even if we get to keep our php meta boxes, and the custom TinyMCE buttons, the interface is so stupid, we will need to open and close a million stupid boxes just to do simple things. How is that an improved interface?

  2. My concern is that the don’t even seem to care – The whole reason we use WordPress for client work is “heavy” plugins like The Events Calendar, Woocommerce and various other listing plugins or Custom CPT’s we have built with ACF fields to help structure data. We have Beaver Builder installed so all pages are in a clear, easy to use editing mode but portfolio items, events, products, lists of businesses, sponsors etc all need a simple structured editing flow. Gutenberg rips this up without providing a replacement other than potentially “opt out”. It’s crazy – we would opt out in an instant or hold all sites at an older version of WordPress until this is resolved. And by resolved we mean when all the kinks have been ironed out and ALL the plugins we use have been updated with robust support – other wise we are maintaining multiple ways of editing for different clients which is always a nightmare.

    Also the idea of a second “stage” for editing meta is crazy as well. Products or events are not split into “content” and “other meta information” all of the fields on the screen is relevant. The Meta information is often more important than the content to get that product, event etc to show up in the right place on the site and the “content” is just the description, the icing on the cake as it were. It keeps sounding like these guys haven’t used the system for client work at all.

    • We always like to stay away from the cutting edge on our publishers’ sites and to keep control of updates. We also like having access to some hidden preferences and to be able to tone down WordPress branding.

      Hence we built BusinessPress to help ourselves, freelance developers and agencies retain control of their WordPress sites. It will help you keep hard at work while the “editor question” works itself out. Either Gutenberg will get much better in the next couple of years or eventually the core team will be forced to back away from the abyss.

      On the sidelines enjoying security updates is a good place to be during unstable times.

  3. The conversation that never comes to the surface in regard to many WordPress controversies is the fact that these ideas and decisions are largely due to Matt Mullenweg and Automattic being primarily concerned with monetizing WordPress.com. In fact, one could argue the entire Gutenberg concept started when Medium.com began growing rapidly and stealing some Silicon Valley limelight, causing Mullenweg to panic and look to outshine them.

    That’s all fine, but when you are the gatekeepers of the world’s most popular open-source platform, it raises some issues.

    Most notably, the typical user at WordPress.com is clueless when it comes to web dev, whereas the entire reason WordPress.org has become so popular is because it is simultaneously simple yet powerful, meaning not just post-editing, but an entire CMS.

    Now that Medium.com is “dying” and many publishers are returning to the WordPress.org world (as recently reported), it would behoove the Mullenweg crowd to consult more with the community as this could be the straw that breaks the camel’s back and results in a fork of WordPress that splits the community in half.

    Perhaps a parallel story is that Google just decided to permanently remove their “instant search” in favor of the traditional search method that requires manually clicking. The obsession with javascript (etc) in the past few years with things like Infinite Scrolling and now Automattic’s Gutenberg are ultimately trends, but if WordPress goes this route the damage could be forever.

    For a company that emphasizes compatibility — even continuing to support PHP 5.3 a decade later — this is truly bizarre.

    Update… similar views:

    http://gschoppe.com/wordpress/improving-wordpress/improving-wordpress-pt-4-where-project-gutenberg-lost-me-open-letter-to-core/

    https://www.mhthemes.com/blog/gutenberg-wordpress-marketing-problem/

    https://premium.wpmudev.org/blog/gutenberg-editor-wordpress/

    • Dead on Jesse. Gutenberg will either usher in a new golden era for WordPress or it’ll shatter it into a thousand forks. Automattic has bet the house on Gutenberg. Problem is, they’re the ones with nothing to lose. They will be fine regardless of the outcome. It’s the community who will feel the burden of this.

      Here’s my opinion: The desire to build Gutenberg is being driven by Calypso. The largest hurdle Automattic has faced with Calypso is the lack of compatibility with plugins. I think Gutenberg is a trojan horse to get plugins to be compatible with Calypso. If a plugin has to be rewritten in React for Gutenberg, it will de facto become compatible with Calypso. It explains why they’re dead set on building Gutenberg in React. It explains the haziness on the future of metaboxes.

      • I can bet you that every Automattic employee contributing to this project (and many more other non-Automattic contributors) are doing their absolute best to make this work for everyone using WordPress both today and in the future. Automattic has everything to lose. In fact as one of the largest companies relying on WordPress in the world, Automattic could be the biggest loser as it pretty much depends on WordPress continuing to gain marketshare.

        WordPress community on the other side has a lot to gain. Gutenberg could prove to be the giant effort that will take WordPress to the next level and it will happen transparently (and magically) for 99.999% WordPress users that are not involved with the effort to create it. And if it doesn’t do what it promises, do you think it would be pushed into WordPress? I don’t and it wouldn’t be the first time.

        If you do want to be involved there is a preferred method to that. Even if you are not a developer you can open new issues and make sure your voice is heard in the existing ones. Start here:

        https://github.com/WordPress/gutenberg/issues

        All it takes is a github account.

        While at it, hats down for Gutenberg contributors. Not only working on a giant, challenging project but also under immense pressure of the community and a slew of negative comments. I imagine it can’t get much harder than that.

    • I agree this is exactly what happen when matt decided to build post formats few years ago out of “fear” of tumblr, etc.

      thank god the core team cancel the project to add post format UI.

      let’s hope they finally get to the right mindset *again

  4. I do not understand why the community is being so ignored on this issue.
    How do I explain the bills we will have to send out to fix everything that will break if this is included in the WP core.
    We have run the Gutenberg plugin on our test bed and my staff have universally said dump this crap, it’s not needed.
    Other than the fact that everything from themes, plugins and child themes will instantly break if this is included in the core what will it do to major plugins like EDD and VC.
    How long will it take us support people to fix the potentially thousands of broken sites and how do we justify the cost which in some cases will be in the thousands of dollars to repair a clients site.
    We don’t need this and from everything I have read the WordPress community is completely against it.

    • I’m sorry you feel like you’re being ignored. That’s not intentional, and we are absolutely listening to feedback.

      We’ve built the plugin to what it is today in 4 months (the first 3 months of the year being the prototyping phase), and we are doing weekly releases and changelogs. It’s just been a lot of work, and if we’ve seemed hard to reach, it’s probably because we’ve been deep in building the thing.

      None of us want to break existing sites. I wish this article had emphasized Matías response:

      – If we detect a meta-box is registered we can fallback to the old interface, nothing changes.
      – We could split editing the content and modifying meta information into two screens or stages.
      – We can try to see how feasible it is to render these as they are (PHP) below the content: #2251.
      – A theme/plugin/CPT could unregister the new interface as needed.
      – Various items that relied on meta-boxes could be converted to blocks for UI (still storing data separately).
      – We could implement API based meta-boxes extensibility like the Fields API.

      Those are all options on the table for how Gutenberg could coexist with the ecosystem as it exists.

      Our focus and our north star has always been to try and build an editor that would make someone who’s never used WordPress before look at it and go “Oh, I want to write in that”. If we do have to break backwards compatibility, we want it to be worth it. We’re clearly not there yet.

      Personally I don’t consider Gutenberg being merged into core a done deal. I’m approaching it like any feature plugin probably should: we are doing our very best to build something that might some day get the blessing of the community.

      • Should the north star really be to impress people who have never used WordPress before? Statements like this are the exact reason for the anxiety within the community. It sounds like you’re only focused on attracting new users instead of serving your existing ones.

      • Should the north star really be to impress people who have never used WordPress before? Statements like this are the exact reason for the anxiety within the community. It sounds like you’re only focused on attracting new users instead of serving your existing ones.

        It’s not about impressing people, it’s about making sure when our kids grow up and want to start writing or building a site, they’ll seriously consider using WordPress instead of instantly jumping ship to walled garden offerings by Facebook or Google. It’s about considering the user experience from the perspective of someone who’s never used WordPress before, in hopes that we can make it easier to perform basic tasks.

        I’m sorry you got the impression that we were ignoring old users at the expense of new users. We’re working hard to make sure the user experience is actually better than the current experience, in ways that matter to all users. That includes thinking about how we can accommodate existing users and sites, as Matías noted in his comment on the thread. We’re not there yet, I concede that.

      • I don’t disagree with your motivation to defend against walled-gardens. However, it doesn’t have to happen at the expense of existing websites.

        Why is there no serious discussion about making 4.9 a LTS version? Let’s make some much needed breaking changes in 5.0, and not have to make concessions like structured data inside of HTML comments.

        I’m all for moving into the future with a block based editor. In fact, I’ll be first in line to start using it on new builds. But why do we have to force it upon existing sites that have been functioning for years without it?

      • It is not my personal intention or even prerogative to force Gutenberg on anyone. If we are able to get Gutenberg into a state where it excites enough people about the potential that blocks bring (check this out), and to a point where a merger into core is likely, then there are a myriad of things to consider before that could happen. I don’t know exactly what it might look like or what’s feasible, but the one Matías suggested as an option — “If we detect a meta-box is registered we can fallback to the old interface, nothing changes” — seems like it would be pretty transparent no?

      • Matías suggested as an option — “If we detect a meta-box is registered we can fallback to the old interface, nothing changes” — seems like it would be pretty transparent no?

        Agreed. This is probably the least intrusive path forward for metaboxes in particular. If I had to guess, the vast majority of WordPress sites have at least one plugin registering a metabox. Would merging Gutenberg into core be acceptable if only a small percentage of users even see it? I understand the idea is plugins will update as time goes on, but out of the gate it would lead to all kinds of confusion.

  5. Why is it that the vast majority of Automattic’s dev focus is on blog users? Have they not heard WP is is doing pretty well as a CMS (and will continue to do so if they don’t muck it up)? It’s almost as if the blogging community is the only community that matters to Automattic.

    I think it’s pretty obvious it has to do with (as Jesse has noted above) Automattic’s plans for making WP.com more profitable. Fine with me, as long as Gutenberg is built as an add-on, and not part of core. Not fine if it breaks WP as a CMS.

    Isn’t it time to fork WP as a CMS platform?

    • It’s almost as if the blogging community is the only community that matters

      I’ve seen the opposite argument used against Gutenberg—that it’s meant as a page builder and not for blogging.

      Have they not heard WP is is doing pretty well as a CMS (and will continue to do so if they don’t muck it up)?

      The reality is many people struggle using WordPress for anything more advanced than writing; people struggle to get their site to look like the theme demo says it could look; people struggle to connect what they edit in a certain field somewhere in the UI with how it will look.

      WordPress can build incredible sites, but the usability and clarity that people expect from modern web apps is not always up to those standards anymore. It needs to be, for it to remain a great CMS system that both users and developers choose to create their web presence. WordPress has also always been about the user experience, and that needs to continue to improve under newer demands.

      Gutenberg is an attempt at fundamentally addressing those needs. An attempt at improving how users can interact with their data in a visual way, wherever that data may be, not at removing the flexibility and power that has made WordPress thrive.

      • I’ve seen the opposite argument used against Gutenberg—that it’s meant as a page builder and not for blogging

        Page builders are fundamentally not a great solution for CMS. I’ve seen too many people in business get mired in the choices required by page builders, when all they really wanted was to make some quick and necessary updates and get back to their ‘real work.’ The job of the designer/developer is to provide a simple, quick, and clean UI to make that possible (and for CMS purposes, WP doesn’t come out of the box able to do that for non-developers).

        Unlike many blogs, business/professional sites are maintained by people for whom fiddling with their website isn’t the high point of their day.

      • Make wordpress as dumb as possible? no client with any aspiration of monetary success will just leave the theme as it is without hiring some developer to enhance it. The assumption that wordpress users are idiots that can not contact the theme support to ask for instructions, or that themes are so awful they have no documentation is just a snobbish attitude.

        WordPress is probably almost never used as a content creation tool. Content is created in an off line way in a word document and is just being copied to the editor. Add to that content created via xml-rpc and OMG an automatically generated content. How does gutenberg answers those use cases? no one have an idea so far.

        Page builders like gutenberg might be nice for “designing” a page or two, but seriously, people do not use wordpress to create a 5 page site, there are better tools for that.

        Last but not least is that at the current state gutenberg is so bloated the UI is unusable. With gutenberg we have “options not decision” :( seriously, all the widgets as blocks? who ever asked to have a widget in his content?

      • The reality is many people struggle using WordPress for anything more advanced than writing

        THAT, folks, is a blog-centric perspective.

        The ‘reality is,’ out of the box, WordPress is JUST a blog platform with the ability to easily add pages. If what you want is a blog, it’s pretty much good to go, and with the customizer, most themes are fairly easy to tweak even for non-techs.

        To meet the specific requirements of specific businesses (like a CMS must), however, usually requires significant customization of UI, post types, custom fields, and templates, just to start with. Those customizations are hung on a reasonably stable platform (so far).

        When proposed changes to the platform threaten existing customizations and the people working on the changes brush aside our criticisms as though ‘we don’t get it’, expect the criticisms to grow increasingly negative.

      • WordPress can build incredible sites, but the usability and clarity that people expect from modern web apps is not always up to those standards anymore.

        I think this is where the communication is breaking down. You’re saying WordPress is a web app. It’s not. The majority of WordPress sites built by professional web design agencies and developers make use of WordPress as a Content Managment System, not as a DIY SquareSpace like web app.

        Clients can spend anywhere from $25,000 – over $1,000,000 to have professional designers and developers to build them a website from very specific design specs. Not to build a “build your own site” platform, so that any office jockey to go in and build a page without following the companies design specs.

        Believe it or not, this is where that “WordPress is 25% of the web” is coming from. Companies using WordPress as a CMS, not as a DIY site builder.

        This is where all the concerns about Gutenberg are coming from. The professional market, not the casual market. Us professionals are seeing all these shiny features that keep getting ham fisted into WordPress as a threat to our services. Not that it’ll take away from our business, but that it makes it that much harder for us to build the types of websites our clients demand and need.

        And it’s not that we hate these features. Just the opposite. We can totally see these features like Gutenberg being a very useful in certain situations, but that’s the key. Certain situations, not all situations, like is being forced upon us.

        The reason we feel like you’re not listening to our concerns is that the Foundation leadership and core team is only looking at this from the DIY casual user side and is completely ignoring the professional agencies, designers, and developers side.

        Sure, build this stuff into wordpress.com where the vast majority are bloggers that would like to have these features built in, but leave them out of the .org version and allow the professional community make the decision to include it if needed.

        And I don’t want to hear that same old crap argument “Well, you can always disable it”, again. That attitude just makes WordPress a bloated, slow platform. You know, those things professionals try to avoid to make the best experience possible.

  6. Gutenberg: the Metro of the WordPress world. Nobody asked for it, nobody outside of the people developing it really want it, and it’s shiny, but ultimately pretty useless.

    Let us all, as WP users and developers alike, hope that WordPress never goes full Windows 10.

    • I see it from a different angle. Gutenberg, the iPhone of the WordPress world. Nobody knew they wanted or needed an iPhone, and it changed everything. The first version was shiny but many considered it to be useless since it didn’t have copy/paste. Today, it’s still flying even higher than then.

      • The difference between this issue and Iphone is we have had a chance to look at the rough Gutenberg Alpha (they call it a beta) and do not like any of it and cannot see how it will improve the WordPress experience but can see how it will damage the 25% market share of Web Sites that WordPress currently enjoys and can see the issues and problems this ill thought out project will have on our clients. Bloggers are not the ones creating that market share, Business, education, government and entertainment web sites are.

  7. As the Gutenberg contributors shared that they have only just begun to look into the meta box issue, it’s now clear why there is no roadmap [emphasis added] for how the project will handle “legacy” PHP meta boxes.

    The mention of “roadmap” got me looking for a roadmap and wondering is that actual or only visionary? I’ve gone over the Editor Technical Overview that charters the project, but I haven’t seen a big picture roadmap on longterm WordPress integration of Gutenberg, which would help mitigate these discussions. Please advise, anyone.

    Searching through Slack and WordPress.org, I quickly landed on the official WordPress Roadmap, which opens with “features primarily driven by ideas voted on by our users” followed by Dev cycle information. I surfed to the top Editing Ideas, which are primarily about an improved Visual Editor with suggestions and comments going various directions.

    I had given up testing Gutenberg, as I couldn’t relate it to an Author Experience framework that guides my perspective for digital content workflows. Seeing the overall debate emerge, I realized it wasn’t merely my own confusion.

    So, THANKS for the roadmap mention, as I’m inspired to go back through those Ideas that generate use cases as a framework for testing Gutenberg.

  8. I hope Gutenberg is rolled out as an auto-update that only supports emoji. I’m a bit disappointed that it wasn’t built into the customizer though perhaps that can come in Version 2? Perhaps it can also remove the text editor, and drop support for PHP7? 5.2 4 lyfe.

  9. One problem with WordPress in general is that right now there are no prominent devs that champion its CMS features. Scribu, the guy who did the amazing Posts 2 Posts, left years ago, so right now there’s no core dev campaigning for features useful for non-blog sites. Correct me if I’m wrong, please.

    So, now we have this new editor who will treat custom meta boxes, the foundation of most client work, as an afterthought. All kinds of data, ranging from products to events, including more complex content types in which the description is not the most important part, risk being treated like second-class citizens with Gutenberg.

Newsletter

Subscribe Via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.