WordPress 5.0 and Gutenberg are coming at some point. And people are getting ready to test it.
In fact, the April meeting of the Fort Worth WordPress Users Group, Gutenberg was all we talked about. And a couple of folks asked about how they could test it before it came out in 5.0.
Of course, the easy answer is to use the Gutenberg plugin that’s available before it’s merged into core. But there was another, more intriguing answer: use the Beta Testing plugin to test pre-release versions of WordPress.
I find this to be intriguing because this is probably the most helpful answer in general with WordPress. After all, this, eventually, will be the official way Gutenberg is rolled into core. And it’s a great way to test out other features coming in major releases.
I realized that the instructions (or the knowledge for that matter) might not be as widespread. So here’s a very simple guide to getting pre-release versions of WordPress for testing.
First set up a staging or development environment
Before you do anything with testing non-production versions of WordPress, you need to create a staging or development environment for your site. This is absolutely paramount. Your site can easily break with an alpha, beta or release candidate version and you never want your live site to break if you can avoid it.
For local development, you can use Local by Flywheel or DesktopServer. And for staging site on your web hosting, I know at least of a couple of hosts offer it. It’s also a pretty good idea to use a staging or development site to test out production core updates and plugin updates to see if they break anything before updating the live site.
Get the Beta Tester plugin
The easiest way to get and install pre-production versions of WordPress is to download the Beta Tester plugin. The second option would be to download the versions from the WordPress SVN repository, but we’ll just focus on the Beta Tester plugin.
Once you install and activate the plugin, you have two options: point releases and bleeding edge. Point releases will give you the latest work on X.X.X releases. So for example, since we’re still waiting on 5.0, the point releases have the latest commits for 4.9.X releases.
Conversely, if you want to test pre-release versions of 5.0, you would use bleeding edge. This will have the alpha, beta and release candidates for the major releases. You’ll want to stay up-to-date with where WordPress core is in the development cycle at the Make WordPress Core blog.
Reporting issues
Finally, with pre-release versions, there are going to be things that don’t work. There might functionality that doesn’t work or something that breaks a plugin or theme. That’s why they’re pre-release and why you should only test them on staging or development sites.
The important thing to do when testing is to take note of those issues and to document them. Then, you can file a ticket to the WordPress Trac. This way, the folks working on that release of WordPress core can take a look at it and fix the problem.
This is a vital part of any open source project. You can learn more about the bug-reporting process on the WordPress.org site.
I hope as WordPress 5.0 and Gutenberg creep closer to being released to the world that you go ahead and take advantage of testing things with the pre-release versions. It’ll make the adoption process much easier for you and others.
