WordPress 5.0 Beta 1 Now Available for Testing

WordPress 5.0 is marching forward with beta 1 released this evening. Major items that need testing include the Gutenberg editor, the new Twenty Nineteen default theme, and all previous default themes, which have been updated to be compatible with the new editor.

You’ll want to make sure you are using Gutenberg version 4.1 before updating your site to WordPress 5.0 beta 1. Gutenberg is now considered feature complete as of the 4.1 release. It is active on more than 580,000 installations.

WordPress 5.0 beta 1 has arrived five days after its expected release on October 19. Contributors expressed concern in today’s dev chat over the large number of issues on GitHub in milestones related to 5.0.

Gary Pendergast, who is responsible for leading the merge, said the dates for RC can be changed if necessary.

“We can shift RC if we need to, which won’t necessarily affect the final release date,” Pendergast said. “If we have to shift RC a long way, that would be a good time to have another look at the release date.”

The Gutenberg team has not published a merge proposal to date. In September, Pendergast said “the Gutenberg leads are ultimately responsible for the merge proposal” but the timeline was still to be determined. Unless a proposal is forthcoming, the project seems to have bypassed this stage, which has frequently been a requirement for new themes, APIs, and feature plugins in the past.

Volunteers contributing to the Gutenberg handbook met for the first time today in the #core-docs channel. Chris Van Patten is coordinating the documentation effort to clean up and prepare Gutenberg-related docs for 5.0 over the next  five weeks.

Testers are advised to consult the list of known bugs before reporting to the Alpha/Beta forum or filing a bug on trac.

If this release stays on schedule, Gutenberg is now 26 days away from shipping in WordPress 5.0.


21 responses to “WordPress 5.0 Beta 1 Now Available for Testing”

  1. Beta 1 is a total disaster (unfortunately):

    My theme’s meta box in the side in not showing but I have a plugin that shows up and works up perfectly at the bottom. Also, the 5.0 beta 1 experience is miles apart from a site using WP 4.9 and Gut. 4.1 (just got updated).

    Some examples:
    With WP 4,9/Gut 4.1 I can:

    -Disable Gutenberg with a simple filter.

    – The Classic Editor Block, SHOWS custom buttons in the toolbar placed by themes and plugins (extremely important for shortcodes for example).

    – I can resize the width of the editor from the pathetic 600+ pixels.

    – Again, no issues with ACF and ALL types of Meta Boxes.

    All these things mentioned above (4 of them) DO NOT work with either the WP 5.0 beta1 (official), or by using the WP beta testing plugin. And all these major issues with just 10/15 minutes of testing.

    Gut. 4.1 with WP 4.9 has changes that affect the custom blocks made with ACF 5.8beta1 too, but those are minor which will and can by fixed by Elliot (the ACF developer). But things with WP 5.0 are really messed up, it’s like they rolled the Guten. development all the way back to 6 months or so… simply said, they did not just “embed” the Gutenberg plugin into the core, they “mutated” parts of it for whatever reason. And wow, fresh WP installation 43.2 MB… more than doubled from the previous installation…

    I have no idea how this is going to be released in 26 days…. if it is, there is no way I’m updating anything unless things work at the very least as WP 4.9 with the Gut. 4.1 plugin…

    What happened to quality control here? Months of testing and making things work with Gutenberg will be lost if this beta is the roadmap to the actual version release. I finally had such high hopes for this thing.

    • Hey Nick! I did a little research on the four items you mentioned in your comment. I like to speak with as much accuracy as I can!

      You had five different things, I think:
      – Meta boxes not showing (in WP5.0-beta1 + GB4.1)
      – Can’t disable Gutenberg with a filter (in WP5.0-beta1 + GB4.1)
      – Width of the editor is not resizable (in WP5.0-beta1 + GB4.1)
      – Issues with ACF, but it sounded like you thought they would be resolved
      – Classic Editor Block does not display custom buttons in the toolbar placed by themes and plugins (in WP5.0-beta1 + GB4.1)

      Fortunately, the Gutenberg team is aware of most of these and fixes are in progress (meta boxes https://core.trac.wordpress.org/ticket/45172, improvements to managing the width of the editor https://github.com/WordPress/gutenberg/pull/10956, custom buttons has a patch in the works right now).

      Disabling Gutenberg with a filter is not possible with 5.0, but you can with the Classic Editor plugin. Some of the people who want to learn about the new editing experience at their own pace won’t be familiar with code. We are trying to remain aware of the many people who won’t know how to work with filters.

      • @Josepha,

        Thanks for your assurances…, since I first posted, I found out about the efforts with the Meta Boxes, Still though, it is inexcusable for such a big issue that made it in an official beta release, same goes with the custom buttons in the Classic Block.

        I already found a working solution for the Editor width, which I can share it freely here if anyone is interested.

        Now the bad stuff. Not having the Gutenberg deactivation filter, is very frightening to a person like me, because the “Classic Editor” plugin is basically made by Automattic, and the moment they decide to stop updating it (and act like Microsoft, which in a way they already are), our freedom of choice will disappear, which is extremely ironic, since WordPress talks about the “freedoms” that the users have, and at the same time, their motto is “decisions, not options”.

        As a theme developer, I loved the idea of having an option in the theme customizer to have the site Admin decide if he/she wants Gutenberg or not, and not having to install yet another relatively huge plugin to do the same.

        Nevertheless, a huge reason why the Gutenberg ratings are so low, is that the customization documentation is lacking, and in many cases out of date, and things are changing all the time. I spent months adjusting and fixing things, and with almost every Gut. version, things move around and change, with no or very little communication how to fix our themes and plugins all over again. And here we are almost November, days before WP 5.0 and if we update, there is a good chance that our clients will look at us like we are complete idiots.

        I now love the possibilities and the idea of Gutenberg, but my God, bring along the theme and plugin developers and act like a “community project” as it’s supposed to be, only then the approvals will increase, drastically.

        Thanks again…

      • Update – how to disable Gutenberg in WP 5.0 with a simple filter:

        add_filter( ‘use_block_editor_for_post_type’, ‘__return_false’ );

        Put the code in your theme’s functions file, or in a plugin… things slowly are starting to make sense again… Personally I will be using Gutenberg, the Meta boxes are the only issues left for me which the devs are working on as we speak I guess …

  2. I activated the Classic Editor plugin on all the sites I manage, but I installed the beta on a test site and seeing the amount of bugs it has, I started to prepare bags of popcorn for everyone to enjoy in November 19.

  3. Whoa, that shocked me as well:

    WP 4.9.8:
    zipped: 9.5 MB
    unzipped: 30.8 MB

    WP 5.0 Beta 1
    zipped: 14.5 MB
    unzipped: 49.4 MB

    (I tested on macOS 10.14, and with a non-localized 4.9.8)

    Welcome to JavaScript hell, I would say :-(

    And for the plugin/theme compatibility:
    Yes, WP 5.0 Beta 1 – with Astra theme for example has no in-post Meta Boxes anymore!!!

    But: A WP 4.9.8 with Gutenberg 4.1 and Astra theme has the in-post Meta Boxes in the compat mode — like it was in the last 6 months or so.

    This is another breaking change — I only hope that the Gutenberg, Core and Automattic teams reach out pro actively to Plugin and Theme devs/companies and inform about all those latest changes.

    Otherwise we will have more than one big disaster in release week!

    I for myself and all my clients won’t update existing installs to 5.0, the earliest will be a point release like 5.0.1 or so. And with „Disable Gutenberg“ plugin by Jeff Star or the alternative combo „Classic Editor“ / „Classic Editor Addon“ as the essentials.

    The direction WordPress is heading for leaves me really really worrying.
Sad but true.

    • Hey David. Thanks for the heads up on Astra. When people take the time to point out where software didn’t behave as expected, we all benefit from that. As Drew has mentioned in this thread, it’s best when it’s all in the same spot where people are looking for it, too. :)

      I believe the lead designer and developer have been proactively reaching out to many plugin and theme maintainers, but this doesn’t seem to have been one of them. Fortunately, the beta is the time for developers (of both products) to sort out the solutions to compatibility issues.

      I think the issue with the meta boxes is logged and it looked like the dev team knows about it/is working on it.

      • @Drew Jaynes
        I was actually reporting the issue to Astra support and they reacted promptly and directed me to the Trac ticket that was already linked here. As turns out it was not theme/plugin related this time but really a Gutenberg/Core issue.

        I have NO issue with beta versions having bugs, really not.

        But in this case it is a bit different: the whole Meta Box topic is essential for the whole Gutenberg debate and migration to this editor, it’s at the heart of it.

        I would have expected a trunk nightly to have these kinds of bugs and crashes but really NOT the first beta version of 5.0.

        May sound ignorant, I know, but the Gutenberg team was also kind of hard in listening to feedback from the community as a whole, especially the profound critics from users and developers alike.

        But to be fair: just today I reached out to Gutenberg GitHub issues with a help request for one of my plugins: one guy from the community could help me and point me in the right direction. This is the WordPress community that I know and love. Thanks to you!

        And so you don’t get me wrong: I have yet to make my personal peace with Gutenberg, right, but I work all of my spare time to make my free .org plugins compatible where it is needed, because I feel responsible for my users! And the users themselves decide if they like Gutenberg and use it or not.

        And, my last point, the Gutenberg/ Core/ Automattic team really challenges us users and developers a lot with the whole migration to Gutenberg / WordPress 5.0. I say it again: a lot! The engine of the airplane is changed during the flight.
        Then it is more than natural, if there are also sometimes sharpenings, irony and satire. That may belong to it and you should endure that. We have to get along with Gutenberg.

    • What caught my eye was your sizing info:

      WP 4.9.8:
      zipped: 9.5 MB
      unzipped: 30.8 MB

      WP 5.0 Beta 1
      zipped: 14.5 MB
      unzipped: 49.4 MB

      I decided to take a look at something because seeing those numbers made me remember something I discovered about the difference between WP and Joomla (Joomla which offers a ton more features). So I installed a fresh Joomla on my local:

      Joomla 3.8.13
      zipped: 12.8 MB
      Unzipped: 30.2 MB (after install)

  4. CheckIng our the latest build of WP 5 and Gutenberg 4.1 and I have to say with a minimal configuration of plugins it does show some promise.

    As usual though there are some caveats.

    The first thing I noticed is that the only way to disable Gutenberg is with the Classic Editor plugin. All other methods, simple one line filter in the functions.php file or a third party plugin will not work. For the filter we do know that it is the intention to provide a new version/name for this once Gutenberg is in core and perhaps the third party plugins depend on this filter somewhere in their code. It does beg the question though is the Classic/TinyMCE Editor still extant in core. It is a question that needs to be answered as we have been led to believe that this is what we have been told previously. Automatic core team has been a bit vague on this.

    Of course the other caveats are my usual bug bears namely the lack of attention for the code view both in general and for each individual block. Code badly formatted, often minimised and could do with a bit of love by providing an IDE text editor like environment for it to be more useful.

    While blocks are useful they don’t always work well for many use cases, namely straight forward text entry. On the layout side of things, Blocks need to do a lot more for structure, sections, rows, columns, flex etc. Some third party vendors have made some efforts but I have found these buggy and really it should be the purview of Gutenberg to provide a common foundation and API for theme, plugins and builders to sit upon.

    The one immediate issue that needs to be tackled is the on page UX. targeting and manipulating blocks is rife with pitfalls which is a shame as it detracts from the usefullness of Gutenberg. From experience many of these hiccups lead to bad results.

    Getting these criticism out of the way, i’ll move onto the the results which are not bad once you master Gutenbergs cryptic UI. The new button in the tool bar does help a little to locate blocks but you should be able to find these. Directly in the content.

    The columns block is now improved with padding on the front and now responsive. A bit more work though still needs to be done on spacing and the mind boggles why blocks haven’t had padding and margin strings from the get go.

    Using re-usable blocks as templates has some promise.

    My test site used Divi and while, as has been highlighted, many elements from third party plugins/themes that previously appeared in Gutenberg are missing, I found with Classic Editor plugin activated, that everything behaved nicely ( I do have to pressure test it). I could opt to run with the Classic Editor for Divi pages and custom post types or just do a Gutenberg page. This separation of church and state works well which begs the question why Gutenberg is being implemented and introduced to WordPress users in such a crack handed manner.

    The onbarding tactic has been all wrong and that falls under the remit of UX.

    We would be better served if Gutenberg was only default on new installs, had a simple filter controlled by a switch in Writing settings to enable/disable Gutenberg/Classic Editor. There is no need for an extra plugin.

    • Hi Stephen,

      The first thing I noticed is that the only way to disable Gutenberg is with the Classic Editor plugin. All other methods, simple one line filter in the functions.php file or a third party plugin will not work.

      It was always the case that once Gutenberg was merged into core that class names, etc, were going to change, which is the reason for this happening.

      It does beg the question though is the Classic/TinyMCE Editor still extant in core

      TinyMCE will remain in core for a long time, if it’s ever removed – Gutenberg still makes use of it and other parts of WordPress, where text can be edited but Gutenberg isn’t used, will still use TinyMCE.

      Automatic core team has been a bit vague on this.

      Did you mean Automattic? Although some members of Core are from Automattic, like all core changes, this is a combination of voluntary developers from numerous places. The core team has, imo, been very clear about TinyMCE remaining, so I’m not sure where you believe this vagueness is from (maybe them not giving a definitive timeline, but that’s probably because no-one can).

      • Hi David,

        I was aware of all this. Currently you can use add_filter( ‘gutenberg_can_edit_post_type’, ‘__return_false’ ); with WordPress 4.9 in the functions.php file to disable Gutenberg, no need for a plugin.

        Indeed TinyMCE will continue to be part of core but it is not clear if that includes the the whole backend interface for editing posts, warts and all (metaboxes). On the filter mentioned above you really have to dig deep with the staff supporting Gutenberg if any of this is the case. I have been told on support tickets that the filter would be renamed or a new filter provided once Gutenberg is included in core and effectively would work as before. WordPress 5 beta is now available but I don’t see a replacement filter that will disable Gutenberg.

        On who actually makes Gutenberg, I don’t think it really matters from my point of view as an end user. I was only letting people know, if they wanted to use test the beta the only option at the moment is the Classic Editor plugin if you need to disable Gutenberg. In the long run we will have to deal with whatever option is available to work with or disable Gutenberg. Knowing what those options are going to be would be very helpful for those of us who need to continue working with the current editor.

  5. This appears to be some confusion around this > “All other methods, simple one line filter in the functions.php file or a third party plugin will not work.”

    Even on this post there are conflicting views. I’d like to be more certain before I advise the 40 sites that I currently manage but for now I am erring on the side of caution and using the classic editor.

    Some theme and plugin developers are more proactive which is great but this looks to me the biggest single important change to WordPress in more than 10 years.

    I like the longer term direction but having to manage the transition in the shorter term will be interesting. Some of the other 150 or so sites that I’ve worked on might need some help and it is those people I’m thinking about.


Subscribe Via Email

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

%d bloggers like this: