Gutenberg to Offer New Approach to TinyMCE in WordPress 5.0, a Plugin to Bring Back Old Interface Will be Available

photo credit: Sergey Zolkin

The WordPress community is currently knee-deep in Gutenberg takes, as the new editor is poised to impact nearly every corner of the ecosystem when it ships in WordPress 5.0. With billions of dollars flowing through the WordPress economy, tensions are high, as many people support themselves and their families with the revenue earned from products and services that have been built on the existing editor.

First impressions range from outright rejection of the new editor to those who embrace it and are hopeful for what it will bring to WordPress. For the past several years, most major new features added to WordPress have come through the feature plugin/feature project process where release leads and other contributors decide whether a proposed feature is ready for merge. The Gutenberg project is taking a somewhat different path to core in that Matt Mullenweg has already confirmed that Gutenberg will ship with WordPress 5.0, but the release will come out when Gutenberg is ready. This approach is part of Mullenweg’s new strategy for core development that makes releases more project-based instead of time-based.

One of the most common concerns that developers and agency owners have about the plan to include Gutenberg in 5.0 is that they may need to hold back some of their sites from updating. The most vocal opponents have called for a way to “opt out” of Gutenberg so that it isn’t forced on their users.

In a post titled “WordPress is about to have its New Coke moment,” Nate Hoffelder shared his first impressions of the new edidtor after taking it for a test run. He said he appreciates the changes it promises but was unable to figure out how to create the blocks in the demo and worries about the “average non-techie” trying to use the interface.

Hoffelder referenced Coca-Cola’s attempt to introduce New Coke in April 1985, which quickly ended in consumers calling for a return of the original flavor.

“My gut feeling is that if users share my frustrations with Gutenberg, they will demand the return of the old interface,” Hoffelder said. “But the official release is months and months away, so it is entirely possible that a UX (user experience) expert will force the Gutenberg developers to make Gutenberg easier to use before it is inflicted upon an unsuspecting public.”

WordPress Users Will be Able to Restore the Old Editor with a Plugin after Gutenberg Lands in Core

WordPress will move forward with the Gutenberg editor as the default experience in the 5.0 release, but Matt Mullenweg confirmed in a comment on his blog that a plugin will be available for users who want to restore the old editor.

“Gutenberg uses TinyMCE, so a better way to think of it is that Gutenberg is a new version of our approach to TinyMCE,” Mullenweg said. “It will be the default experience of WP, for people that want to use something more like what’s currently there we’ll have a plugin they can use.”

This should bring some relief to developers who will not yet have updated their extensions to work with Gutenberg, as well as agency owners who are not ready to give their clients access to the new editor.

In his post, titled We Called it Gutenberg for a Reason, Mullenweg shared his vision for how the new editor will will re-imagine TinyMCE and the advantages it will bring for plugin editors:

Plugin developers will be able to completely integrate into every part of WordPress, including posts, pages, custom post types, and sidebars without having to hack TinyMCE or squeeze their entire feature behind a toolbar button. Today, every plugin that extends WordPress does it in a different way; Gutenberg’s blocks provide a single, easy-to-learn entry point for an incredible variety of extensions. Some folks have already begun to port their plugins over, and are finding that they’re easier to build and have a much improved UI.

For developers who are worried about the compatibility of their metaboxes, Mullenweg said a plugin will be available for providing the legacy edit page for metaboxes. One commenter, whose sites are heavily dependent on Advanced Custom Fields (ACF), asked if there is going to be a version of WordPress that will get long-term support for sites that can’t be upgraded to 5.0 without breaking.

“There won’t be a version of WP like that, but there will definitely be a plugin that gives you the legacy / old edit page. Make sure to let ACF know that Gutenberg compatibility is a top priority,” Mullenweg said.

Scott Kingsley Clark, lead developer of the Pods plugin, said this support for legacy PHP meta boxes is welcome news for the project but that Pods is also looking to get on board with Gutenberg once the project’s engineers have a solution for metaboxes.

“I’m very excited to start using the new meta boxes from Gutenberg once the API supports it and gives us more to utilize,” Clark said. “As soon as that’s available, count us in for immediate adoption.”

Despite assurances that a plugin will be available to restore the old interface, some are still concerned about how Gutenberg will impact the WordPress ecosystem. The average WordPress user has never heard of Gutenberg and its inclusion in 5.0 will be a major change.

In a recent article on WPShout Fred Meyer contends that Gutenberg doesn’t go nearly far enough towards giving users what they really want, which he identifies as front-end editing and the ability to create layouts within post content.

“Gutenberg doesn’t go nearly far enough,” Meyer said. “It won’t make WordPress’ core content editor competitive with hosted builder solutions, or even with WordPress’ own themes and plugins (including badly built, bad-for-the-community solutions like Visual Composer.)”

Meyer believes Gutenberg has the opportunity to defragment WordPress’ ecosystem of page building tools, but only if it moves towards providing “a feature-rich, developer-friendly, front-end page builder and content editor.”

In responding to feedback from the community, Gutenberg design lead Tammie Lister has said that the project is currently focusing on editing before tackling the page building experience. The team has also been working with the authors of page builder plugins ahead of the next focus on customization.

“It is still a little early to say what will happen to plugins and builders,” Lister said. “Initially, Gutenberg is focusing on the editor. The next stage is for the Customization focus (the building of pages). One thing that will need to happen is a lot of testing of existing plugins with Gutenberg. That’s how we can ensure things do work and limit issues. Ultimately, more and more plugins won’t be needed – or at least not so many together to achieve simple things. This benefits users and creates a better, more unified experience for all.”

If users’ first impression of Gutenberg is that it is unable to deliver on all of the lofty promises of the project, they may return to the old interface en masse. WordPress will then have a battle to convince users to give it a another chance as the experience improves to include customization.

Multi-column layouts, which are the gateway to page building, are not currently within the scope of the first official version coming to core. Gutenberg’s one-dimensional, vertically stacking approach to designing pages isn’t very inspiring. This may frustrate average users whose expectations have not been tempered with the understanding that a future version will include an expanded page building experience. A plugin that allows users to opt out until it is an improvement over their current tools is going to be crucial for keeping the community happy.

58 Comments


  1. It might prove embarrassing when Disable Gutenberg skyrockets past Jetpack on the “active installs” leaderboard.

    Or, Gutenberg could simply be left as an opt-in plugin for a while?

    Report


    1. And it’ll probably have more favorable reviews too!

      Report


  2. I believe the best way for Gutenberg to be introduced is to only replace the existing editor in themes that explicitly specify support for Gutenberg, which will also avoid a lot of the instances of people needing a plugin to revert. There will be lots of broken sites otherwise

    Report


    1. The question is how long does this legacy support last? If we allow Gutenberg to move forward via optional support in core, then we will be forced to support a split WP admin experience with no foreseeable end. As much as I dislike the idea of requiring a plugin to provide compatibility, at least the plugin signals deprecation and we will move towards a unified admin experience over time.

      Imagine being a plugin developer who extends the functionality of any post type via meta boxes. If Gutenberg is optional in core, then you’re forced to maintain support for the legacy and Gutenberg UIs since you have no control over which UI your users will pick.

      Report


  3. “First impressions range from outright rejection of the new editor to those who embrace it and are hopeful for what it will bring to WordPress.” – This statement conveniently leaves out the fact that the ratio of the “outright rejections” vs “hopeful” is 3:1, and probably an even bigger ratio, since some accidentally gave it 5 stars while writing disapproving comments, and also strong comments on sites that Automattic has influence on being deleted by the moderators, thus reducing the bad reviews and the anger towards this thing.

    The plugin that will revert to the old editor and interface will only work if it does not add any extra load to the server and additional loading times, otherwise many of us will simply not update to WP 5.0 and even disable the update notifications altogether. Automattic for whatever reason is pushing this this so hard, that I would not be surprised to have some sort of a punishment for those of us who won’t “obey” them.

    With all the available tools and page builders that are 1000 times better, I still don’t get the need of this thing…

    Report


    1. …bring to WordPress.” – This statement conveniently leaves out the fact that the ratio of the “outright rejections” vs “hopeful” is 3:1

      Your phrasing implies bias on the part of the author. It may seem a natural conclusion considering the CEO of Automattic owns this site, but it’s not been my experience.

      I’ve always felt that the writers here do an excellent job of providing fair, comprehensive, and unbiased WordPress related news.

      Report


  4. LOL, one more plugin that needs to be installed before wordpress can actually be used?

    Anyway there is no point to pretend that anyone will keep maintaining the metabox api once it will be deprecated by gutenberg, therefor that plugin will be useful to a very limited time until the metabox api will be totally broken.

    Report


    1. Just a little point worth noting, the metabox discussion is about a solution for that, not specifically deprecating. For anyone interested in metaboxes, there’s a really lively discussion going on over on GitHub: https://github.com/WordPress/gutenberg/issues/952. I’d really encourage people to follow that and get involved as the solution is worked out by the community together.

      Report


  5. So if my sites runs ACF or Toolset, Gutenberg would break the sites?

    Report


  6. If one will need a plugin to get metaboxes working, then Metabox API is defacto deprecated and backwards compatibility is broken. In a rather major way too. Something that was asked very very explicitly and was denied.

    Which is not end of the world really. But all the spinning of this is exhausting. We need to hear less of “but it going to be sooo cool” and more of:

    1. Yes, sites are going to be broken
    2. Yes, eternal backwards compatibility in WordPress is over
    3. Here is how we are going to handle this break…
    4. Here is how we are going to handle breaks in general going forward…

    Report


    1. Thanks Rarst, just recovered from your answer cause i fainted. :-) Oh my, this will cost me lots of hours. A thing that bothers me big time: Gutenberg is forced upon us and it looks like it will break sites. But still we support PHP 5.2 cause some sites might break when raising that bar. To be clear, I’m not against Gutenberg and big changes, but this seems to be so rushed that it will be like a burned throphy with no winners at the finish. Why the rush?

      Report


    2. I think a lot of the uncertainties are coming from the fact meta-boxes represent different concepts:

      * Things that might be transformed into blocks.
      * Current meta-boxes reimplemented as JS modules to extend Gutenberg UI.
      * Current meta-boxes working as they are.
      * Custom fields applied through blocks.
      * Custom fields applied through meta-boxes.

      We are not purposely trying to break anything that works! Shortcodes, custom fields, etc, will continue working. I also hope we can improve on them, like the shortcode block that currently exists in the plugin. The UI to interact with them might change (unless you disable Gutenberg completely), and certain use cases for meta-boxes are going to be a better fit for blocks going forwards. With the technical changes we also need to see what is the most viable approach.

      Report


      1. I really, really hope this is true. I have about 70 active websites for clients, using all kinds of meta boxes, some from plugins, most with some custom code I have build. From a simple couple of form fields to fill in meta info for a page to pulling in a google map to let a client pick a location. Even now building a couple of websites using custom post types and meta boxes. All small clients, who will not be able or willing to pay for a sudden need to rebuild things.

        I’m fine with things improving and new possibilities to build things. I’m not opposed to change. The way I build WordPress sites now is different from five years ago. But the thing is, there needs to be no sudden breakage and enough time (many years) to transition code bases.

        Report


  7. Without the ability to create multi-column layouts, Gutenberg provides very little functionality that the existing editor doesn’t already provide. Like TinyMCE, all it basically provides is a single column of content. I was initially excited for something like Gutenberg but the lack of multi-column implementation, the (current) lack of support for Meta Boxes, the lack of any real roadmap as to what is/isn’t going to be included when it gets time to be added to core, is making me extremely hesitant about its introduction. Rather than forcing it upon everyone for 5.0, why not initially release it as an official plugin and keep it that way for at least two full versions. Or better yet, keep it as an official plugin so that people have the choice. As it is at the moment, I see Gutenberg driving more people to full-featured Page Builders, rather than drawing them back from them.

    Report


  8. As far as I know the initial plan was to display legacy metaboxes below the Gutenberg editor in a “Extended Settings” section. Has this plan changed now? Letting users install a plugin to support their metaboxes (which often are a crucial element of their website) would be quite a bummer, to say the least.

    Beyond that, this comment on Github describes the current situation pretty well: https://github.com/WordPress/gutenberg/issues/952#issuecomment-327477694

    Report


    1. As far as I know the initial plan was to display legacy metaboxes below the Gutenberg editor in a “Extended Settings” section.

      You are absolutely right, this is the current plan and discussion being said in the issue focusing on metaboxes. Thank you for sharing that and glad to see you are following the current progress.

      There’s a lot of content in this post, so forgive me for taking a little time to clear up a little confusion. What was actually said in the comment was there would be a plugin that “gives you the legacy/old edit page”. It wasn’t said that you’d need this to simply use metaboxes. The community is having a discussion on those and working on a solution – which is really hopeful as seen by recent work.

      Report


      1. Thanks Tammie for clarification and I’m glad that users won’t need to install a plugin to use their metaboxes. This part of the post was a bit confusing:

        “For developers who are worried about the compatibility of their metaboxes, Mullenweg said a plugin will be available for providing the legacy edit page for metaboxes.”

        I assumed that this means metaboxes won’t be available in Gutenberg unless you install the plugin and it seems others understood the same. But I’m really glad that this won’t be the case. :-)

        Report


  9. I don’t see how plugins to disable Gutenberg site wide and plugins to get meta boxes working again are a solution. Imagine having 100 client websites, all with different (custom build) themes and plugin code. Using different common plugins like Yoast SEO, Woocommerce, and some custom made plugins. After 5.0 and Gutenberg launches, some plugins will migrate to make use of Gutenberg, others won’t. Some of the themes can work with Gutenberg, some won’t. I don’t see how this is technically going to work. I can’t both enable and disable Gutenberg at the same time. And for some sites clients will have to learn to work with Gutenberg, with others (where upgrading is not possible) they have to stick with the old editor. If everything still works that is. This is going be a giant mess.

    And still wordpress developers don’t seem to take the concerns seriously. “We are working hard” is not enough. I do believe the developers work very hard and with the best intentions. But a clear roadmap for what will happen and how everything is going to work is missing. Matt’s post only added to the concerns, in my opinion.

    Report


    1. This is an issue with developer driven products. There are a lot of good things, but in general, such products lack product owners (that aren’t devs), user research and the trappings of product management that try to bring the wider world of endusers to the table so that those concerns are heard and weighed.

      That’s not going to change though.

      Report


  10. Thanks for the mention, Sarah.

    BTW, I also wrote a post that explains Gutenberg to non-techie WP users. (I could not find that anyone had written it yet.)

    Nate Hoffelder, Valiant Chicken

    Report


  11. Make sure to let ACF know that Gutenberg compatibility is a top priority

    If it’s a “top priority” then where is the API to connect to Gutenberg?

    * Where are the code samples of how it will work?
    * Where is the documentation?
    * Where is, y’know, a single demonstration of this working?
    * Where are the design documents so we know what it will look like?
    * Where are the wireframes so that we can evaluate the UX before deep diving?
    * Where are the tests so we know what needs to be changed in the move from PHP rendering to JS rendering?
    * Where is the initial scope of what will work and won’t work?

    Given that none(?) of this exists, how are the users of the large plug-ins, like ACF, able to “let [plug-ins] know that Gutenberg compatibility is a top priority”? Even if these plug-ins were to agree, they simply have no way of acting on it. So how is it a top priority? Who is it a top priority for? Certainly not Gutenberg, which isn’t working on it as a priority. In fact, it’s not a priority at all, let alone top!

    [To be clear, it’s ok that it’s not the top priority. If i was running the development of this project it wouldn’t be top of my list either, nor even in the MVP. If it was from any one else but Matt, I’d say that statement was disingenuous. It is though a lovely deflection/soundbite.]

    This is a plug-in, that is apparently in Beta. But still in development from an architecture sense, no where near feature freeze, and with an ever changing scope, yet tied to a specific release. It is not aligned with derived user outcomes, not tied to user values/expectations/needs. Gutenberg never asks the ‘why’ from a user perspective, not quantifies the ‘value’ to the user. It screams of a lack of well defined vision. Essentially, it’s a half-assed half-way-house solution from something simple, but in the market considered antiquated; and where the market is going.

    We’ve seen this before – it was called Windows Vista.

    Report


    1. With regards to documentation, you’ll be pleased to hear there is a lot already and a lot more planned. You are right, everything possible should be documented and be obvious about where that documentation is.

      The project can do better; you can always do better with regards to documentation. However, for now a starting point is: http://gutenberg-devdoc.surge.sh/.

      Report


  12. I think this is the only good news of all that surround Gutenberg: being able to give up using it, replacing it with the current one with a plugin.

    Although the logical thing would be the opposite: leave the current editor and that person who is convinced Gutenberg, install it as a plugin repository.

    I still can not understand Automattic’s interest in imposing on us an editor that does not really meet the needs or demand of anyone, since it is a long way from becoming a builder like the ones we have today. Maybe it looks a little like the SiteOrigin sections feature, but far from being a page builder.

    The only reason that occurs to me and that I have commented on some occasion is that Automattic needs this change to later market with something and take advantage of it.

    Report


  13. Gutenberg will bring the much needed standardization for drag & drop page building. No more lock in! Client support will become much easier again IMHO.

    WP 5.0 will only be released when Gutenberg is ready. Personally I don’t believe they are rushing it in.

    There will be a new metabox API and I am confident the core team will come up with a good work around for the (legacy) meta boxes. Personally I wonder why they are not just put under the new editor and/or sidebar (depending on the context they are registered for)?

    I can’t imagine they will break backwards compatibility.
    But I agree it would be a good thing if the Gutenberg team would acknowledge that.

    Even if multi-column won’t be a core block in WP 5.x, I am sure the community will fill that gap with a multi-column block and many others?

    I do share the concern about the learning curve for (non technical) end users. Maybe it would be a good idea to include a link to a quick tutorial video (in all supported languages)?

    Report


    1. Bang on, let’s standardise the page builder and make it native.

      Im also a strong believer that the community will work out the columns prior to release, this is the only feature holding me back from using Gberg right now in new projects (although front end editing would be really nice)

      With regards to the front end editing options, I imagine that once the backend editor is finalised the front end part will be pretty trivial.

      Report


    2. This might be the case if they were actually building a Page Builder, but they’re not. And they’ve been extremely clear that they’re not creating a Page Builder. Gutenberg doesn’t even support multi-column layouts. Oh, and not to mention, it doesn’t actually support Drag ‘n Drop either. This thing is FAR from being a page builder! As it is at the moment, Gutenberg is going to drive more people to fully-featured Page Builders, rather than encourage people to drop them.

      Report


      1. You are absolutely right in stating that Gutenberg isn’t a page builder, that isn’t the intention. Right now and for 5.0 it will be an editor. The other focus of Customization will take what is released of Gutenberg into the realms of layout and building. It’s a good point remembering that this is just the first part of a two part story.

        Report


      2. As Tammie mentioned, Gutenberg v1 isn’t a page builder. We’ll be exploring those kinds of features more in the future once we have the underlying structure and functionality of Gutenberg to build off of. :) Would love to hear your thoughts on the kind of features needed once we start transitioning towards the customization focus post-Gutenberg launch.

        Report


  14. A great page builder in WP core is important for all of us.

    I wish that Gutenberg development could show a little more consideration to the many theme and plugin authors that make up this ecosystem.

    What I would prefer to see is:
    1. Develop it
    2. Release a stable version as a plugin
    3. Let it run for a while and get a lot of feedback from users
    4. Tweak and iterate on it at your leisure
    5. Finalize the API for other developers (like us) to connect with the new editor
    6. Let us time to update our themes and plugins to it
    7. Include in core

    The way it’s going now isn’t possible for us. We’re supposed to update production themes and plugins to constantly evolving Gutenberg and be ready exactly with them, before there’s real user feedback for a production release of WordPress. Obviously, that’s not possible.

    I hope that others will join this request and we can get heard, before this causes real damage to all of our livelihood.

    Report


    1. Thank you for this excellent comment, Amir!

      I wish Automattic and the Gutenberg team were that reasonable and presented a clear and intelligent roadmap along the lines of your suggestions.

      But at present, what they communicate comes across to me as rather unstructured and, what is worse, as seemingly mindless of the consequences for hundreds of thousands of people whose very livelihood could be endangered by a premature inclusion into the core. Mindless of hundreds of thousands of web designers, agencies and their clients, whose businesses would be in real danger from broken web sites and ensuing costs (such as lost business, possibly legal costs etc.).

      If they don’t heed voices of reason like yours, I can see this whole project backfiring big time for Automattic, instead of increasing their market share.

      Report


    2. All very valid points and I agree with the above – nice to see a rational response to Gberg from a practical perspective, rather than just ‘I hate it’

      Report


    3. This is exactly how it’s going on from my perspective. We want to have both users and developers using it as early as possible so we can iterate on the experience and APIs until we have a robust solution. These cannot be developed in a vacuum, as we need the feedback to arrive at the right solutions.

      Report


  15. “…which he identifies as front-end editing and the ability to create layouts within post content.”

    AHHHHHGHHH. As if creating layouts is just something dead simple and anyone can put together a site that works well on their lunch hour.

    The more I see the WP community embracing the idea that endusers can build their own sites the less I want to stake my livelihood on WP. Sure, some people can install a nice template and it will work for them but most people can’t design a good, well-converting site that presents their stuff in the best light and gets visitors to engage.

    As for Gutenberg… it needs UX. Having a bunch of developers and other techies be the primary feedback group just scares me – they’re not the main body of WP users.

    Report


    1. “Having a bunch of developers and other techies be the primary feedback group just scares me – they’re not the main body of WP users.”

      Me, too. It really shocked me when I realized this was going full steam ahead even though no one had asked actual users what they thought or whether they wanted this.

      Report


    2. You make a good point, getting feedback just from one single group is not at all going to be the best for the project. Testing wider is a large focus of the project right now and will happen over the next few months. It’s crucial and personally something I believe strongly in.

      Report


    3. As for Gutenberg… it needs UX. Having a bunch of developers and other techies be the primary feedback group just scares me – they’re not the main body of WP users.

      This project has been design lead from the start. It seems a bit offensive to dismiss people who have built their careers around the discipline of user experience as techies.

      Report


      1. Matias,

        This response of yours sums up everything that’s wrong with the development of Gutenberg.

        You asked — and keep asking — for feedback. But when you get feedback you don’t like, you dismiss it as “offensive.”

        I suggest you address the concerns voiced, either by your actions or by a detailed explanation. Otherwise it’s you who is behaving offensively.

        Report


      2. What concerns do you think are not being addressed? We are all happy to discuss the decisions and improvements to be made—that’s the whole point of having this in a plugin form so we can critique and iterate. My only clarification, given this is being built by real people, was that it has always been a design lead project by individuals who have professional experience in these disciplines and should not be discredited.

        Report


      3. My only clarification, given this is being built by real people

        It’s being tested by real people too, Matias. And you asked for their feedback. Yet you insult them when they provide it.

        If you think that professional designers know everything about UX, then why did you ask for feedback?

        One of the characteristics of being a true professional at any discipline is being able to handle criticism — even strong criticism. If you can’t handle critical feedback without resorting to insults, that tells me all I need to know.

        Report


    1. @Eugene Kopich

      Come on now, you know it’s that not simple, right? You made a statement here that is ignorant at worst and uninformed at best. You would seem to presume that one hasn’t learned javascript (at all or deeply enough) and that if the opposite were true it would simply be enough / make everything alright. This is wrong on so many levels.

      The react vs vue debacle needs to be dealt with and the position decided public / officially stated on the record instead of dodging the issue. It’s not a community decision, that’s already apparently so they should at least just clear the air in this regard so people know one way or another definitively. Even those who listened and learned javascript deeply but don’t know react still are unprepared. Even if they know react, they may still be unprepared if the team switches frameworks before Gutenberg is in core.

      So, to cover one’s bases effectively and continue developing for WP…

      1) One must know JS deeply – PHP is not good enough anymore and will eventually be deprecated.

      2) One should to learn react because that’s what they’re using right now and if you don’t like that (or Gutenberg itself) then you can just leave the WP platform, right? LOL.

      3) One should also learn Vue just in case they switch to that.

      4) Lastly, prepare to retire all the knowledge built up regarding the JS frameworks already in WP Core – Backbone, Marionette and Underscore that’s already in core because that’s potentially legacy too now like PHP, metaboxes, etc.

      Report


      1. Tbh, and I’m going to get a fair bit of hate from this – the differences between react and vue are pretty trivial (same goes for angular2 as well)

        Report


      2. I have decent comfort level with all three of those, so I’m not impacted by the choice. Although I really dislike the way React primitives output is horribly nested, and some other downers. I’m less concerned about framework choices than structural data issues.

        Report


      3. I can’t sing the praises of Vue enough – it’s simply fantastic! AND if anyone wants to get their hands really dirty and mess about with jsx, well you can do that , too, as Vue supports jsx. Why they haven’t just got on with this and gone with Vue is staggering… but even IF the powers don’t go with Vue, it really doesn’t matter, because like jQuery before it, if you want to add some magic to your dull old .php pages, you can just dump it on the page/site and hey presto, you have access to most of Vue goodies right out of the box, including templates, centralised data storage and whole world of other excellent “stuff”.

        Report


  16. This is really bad news, at least add an option in the settings to turn the new editor off. I think that it’s a catastrophic UX to have to install another plugin so that you’d get the old capability back. Not to mention the possibly breaking changes for ACF built sites.

    Installing additional plugins just to make your site work the same way it did in the past seems a bit like putting a bandage on a half severed leg…

    Report


  17. If Gutenberg is “feature rich,” does it include a find and replace feature?

    Report


  18. Aside from the technical perspectives on the real benefits of fixing structural problems in core, the biggest mistake IMO would be to release the new editor without multi column support. Really, CSS grid and flexbox ain’t hard. I get the feeling, after just trying out the latest beta, that WP is like GM in the 90s. They know they need to innovate with the rest, but they’re desperately in love with that square trunk.

    Report


  19. What the hell??!!

    WordPress has fundamental legacy baggage, needing to support a version of PHP that hasn’t been receiving security updates for years because, boo hoo, it will break some extremely few (as a percentage of) sites.

    So most developers are being ‘forced’ to accept technical debt, and spaghetti code solutions, due to a very very very limited number of sites using ass-backwards host.

    (I put forced in inverted commas because no one is stopping us from moving to another CMS – something that seems likely to happen if this whole mess isn’t sorted out)

    Yet, core (read Mullenwegg) has no problem breaking thousands upon thousands of sites that rely upon metaboxes?!

    This on top of the whole, “must be GPL, except when it’s good for Automattic’s business”, React debacle…

    I have no problem with removing technical debt, great idea… but the whole “trust me” thing is ridiculous.

    I don’t trust you, since you decided to go after someones trading name just to be vindictive. Small petty minded bullcrap.

    I don’t care if Automattic’s lawyers say the BSD+Patents license is okay for Automattic, what do the independent WordPress Foundations lawyers think about it?

    Decisions are being made and forced through that are based on what is best for one man’s business in a way that is best for that business. It may be right that we need to move to blocks format, more JS, deprecate the metaboxes API etc, but is this the correct path to doing that?

    Proper roadmaps, proper testing, some consideration for the developers who have made WordPress the success that it is.

    Oh and while I’m at it … Give me a fields API, relationships API, restrict WordPress to more modern PHP standards etc etc

    Report


    1. Right on the money! This should be a featured comment at the top!

      Report


    2. You certainly have a lot of stale venom. I actually like/appreciate Gutey, just wish it was opt-in.

      Yet, core (read Mullenwegg) has no problem breaking thousands upon thousands of sites that rely upon metaboxes?!

      This on top of the whole, “must be GPL, except when it’s good for Automattic’s business”, React debacle…

      I don’t trust you, since you decided to go after someones trading name just to be vindictive. Small petty minded bullcrap.

      Metaboxes will have a plugin.

      You can side-step the GPL by not using WordPress.

      Capitalizing off of WordPress? Great. Don’t yap about trademarks, GPL or someone else’s hard work being taken for granted.

      I won’t even address your gimme-gimme-gimme paragraph.

      Report


  20. It’s going to be real fun to see the WooCommerce guys trying to adapt its current comprehensive product metabox to this new blocks paradigm. I wouldn’t want to be in their shoes.

    Report


  21. I agree with so many of the comments above, especially @Amir’s point about the Gutenberg roadmap feeling pretty condensed.

    I’m all for moving things forward, but there’s clearly a lot of concern in the WordPress community about things breaking, and allowing time for developers to learn and make their necessary changes.

    It’s reassuring to hear a legacy editor will be available and I’m eager to know more how this will work. That would calm a lot people! Personally, a default “legacy mode” on all my websites will be my preferred option, then opt-in to Gutenberg.

    I don’t think it’s any exaggeration to say if the release isn’t well managed, we could see millions of broken websites and a huge dent in the reputation of WordPress. But I have confidence that won’t happen – it can’t!

    Report


  22. The world needs another pagebuilder like I need a bullet to the forehead.

    As a general rule:

    Clients suck at design.
    Clients suck at UX.
    Clients suck at content strategy.
    Clients suck at development.

    Why are we trying to let clients be developers?

    Report


  23. @amir idea of…

    What I would prefer to see is:
    1. Develop it
    2. Release a stable version as a plugin
    3. Let it run for a while and get a lot of feedback from users
    4. Tweak and iterate on it at your leisure
    5. Finalize the API for other developers (like us) to connect with the new editor
    6. Let us time to update our themes and plugins to it
    7. Include in core

    ….makes so much sense in a perfect world.

    I said this before….WordPress is going to see a major fail and backlash on the push for Gutenberg; it will happen. Consider the reality of the millions of websites using WordPress, then the plugins, and then the 10’s of 1000’s themes.

    I’m so glad I use Joomla for my own site. I might even start designing themes (templates) for Joomla again if things go terribly wrong later.

    Now if the core team ( and Matt ) would just take a breather, sit back for a moment and listen, they might be able to make Gutenberg a success…if done right. Just as Amir posted and many others.

    Report


  24. I’m attempting to create a standardised page builder using ACF flexible content fields. I’m also trying to standardise a REST API to make it possible for people to create their own frontend editor apps to create/update layout content. The goal is to provide a frontend editor solution once the development of the backend API has stabilised.

    The benefit of using ACF is that it is a well-established plugin (really should be core!), uses post meta data, has an out-of-the-box backend UI to manage the content, and is supported by other really good plugins like WPML for translations. There’s also potential further benefits of using other plugins related to ACF ecosystem with it.

    If you want to view (or contribute!) to the progress of my ACF Page Builder plugin, check it out here: https://github.com/lvl99/acf-page-builder

    It’s under frequent development at the moment so I’d probably wait until a v1.0.0 release when the API has finally stabilised before doing anything in production with it. I’m really interested in people’s comments and feedback on the project.

    Report


    1. ACF is a kickass plugin that does not belong in Core–by its mere definition/nature, it’s perfectly suited as a, well ….a plugin. Imagine that ;-) Also, you should re-think making something “standardized” when it relies on YetAnotherePlugin. Market it to ACF folks, but leave vanilla WP users alone.

      Report


      1. Partially true – wordpress has its own custom fields functionality which is woefully inadequate. ACF remedies this. I dont see why this functionality couldn’t be core – other than the fact Elliot does such a great job on his own. ACF is the best documented plugin for WP developers by a wide margin.

        Report

Comments are closed.