WordPress 5.0 is now here, which means the new Gutenberg editor is now a part of our daily lives. This update to WordPress’ editing interface will forever change the platform and the way we create content. As such, it’s a big transition to make, particularly if you’re not well prepared.
As with many other new additions to WordPress’ core, testing the editor before it goes live will get you better acquainted with the multitude of new features. What’s more, you can do this via your own computer using a tool such as Local.
In this article, I’ll discuss why you should test the new editor on your site, and talk you through how to do it in four steps.
Here’s how to test the WordPress Gutenberg editor on your site:
- Create a local site using Local
- Backup or clone your live site
- Migrate your files to your local environment
- Update to WordPress 5.0, then thoroughly test the new additions
Let’s get started!
Why you need to test the Gutenberg editor
As you may be aware, the existing TinyMCE editor has been overhauled. The new editor uses “blocks” to create content – pre-built elements that can be added to your pages with ease. These changes will simplify the process of editing your site, along with attracting a whole generation of new users to the platform.
Of course, such a huge change requires a lot of testing – by developers and users alike. However, this will put you in a much better position, as you’ll be able to get to grips with all of the new features Gutenberg has to offer before making the commitment. There’s a lot to pick up, so spending the time getting to know the new editor will ensure that business remains as usual, with as few roadblocks as possible.
Testing the waters will also benefit the wider WordPress community, as there are several ways you can help shape the editor moving forward. For starters, there’s a dedicated section of the WordPress support forum, where you are encouraged to discuss what works and what doesn’t.
You can also carry out up to three usability tests, which are almost identical but increase in complexity. However, these aren’t obligatory, and you’ll probably have more pressing concerns initially. For example, making sure the new editor works on your own site.
How to test the Gutenberg editor on your site with Local (in 4 steps)
Fortunately, the process of testing WordPress 5.0 and the new editor is a breeze with the right tools. Let’s start at the very beginning.
1. Create a testing environment using Local
You’ll very rarely want to push the changes you make during testing to your live site. Instead, you can create a sandbox environment on your own computer to do so, without affecting the live website. Of course, this means you can carry out tweaks without disrupting the User Experience (UX).
As for the tool you’ll use, Local makes it incredibly easy to install WordPress on your computer, clone your site, and even push your local site live when you’re finished.
There are versions for macOS, Windows, and Linux, and Flywheel users have ‘batphone’ access to their server. In other words, you can push a site direct from your local environment to your live Flywheel server.
Rather than explain how to set up and run Local here, there’s a great blog post offering three simple steps to getting up and running. I encourage you to read it in full, then meet me back here!
2. Clone your live site using a plugin
Once you’ve installed Local, you’ll want to import your live site’s content to it. While there are a number of different ways you can do this, a great approach is to use the Duplicator plugin:
This essentially creates a “package” – i.e. a copy of your entire WordPress site and its database. Of course, this is perfect for creating a local version of your site.
After installing and activating the plugin on your live site, head to Duplicator > Packages within your WordPress dashboard. From the Packages >> All screen, select “Create New” from the right-hand side:
Next, give your package a suitable name. Leave the other settings as they are, then click “Next” when you’re ready:
Duplicator is now ready to run a test to confirm your content can be exported without issue. If all goes to plan, you should see a screen with several “Good” confirmations. From here, select “Build”. Duplicator will then begin putting together your package, and could take a while depending on the size of your website.
When the process is complete, you’ll be sent to a confirmation page featuring two downloadable files:
Rather than walk you through this step-by-step, click the “Archive” button to get your files, then read through the “How do I install this Package?” instructions, as they’re comprehensive and thorough.
3. Migrate the live site to your local environment
At this point, you’re ready to import your live site’s data into Local. To do this, simply drag and drop the Archive ZIP file anywhere onto the Local interface.
You’ll then come to the Import Site From Archive screen, where you can now add a name for your new local site:
When you’re ready, click “Continue”. You’ll then be asked to choose your environment settings, which you should leave as “Preferred” for now, then click “Import Site.”
Local will now import all of your WordPress files and database – this could take some time, but be sure not to close Local until the process is complete.
Once the import is complete, clicking “View Site” lets you preview your website:
If the process has been successful, you’re now ready to test out the new editor!
4. Update to WordPress 5.0 and begin testing the new editor
At this point, you’ll have successfully imported your live site into Local. The penultimate step is to make sure WordPress is updated to the latest version – of course, this is now 5.0, which includes the new editor. This process is as you’d expect, and the same as any other update you carry out. In fact, you may not see any new screens at all after the update.
Even so, while you’ll want to read up on the general feature set, the concept of blocks is an important one to focus on. They are literally the building blocks used to create your website, and each content type has its own.
When it comes to testing, I recommend looking closer at the following:
- Looking at whether the functionality of your primary theme is intact.
- Testing the features and functionality of each installed plugin for any issues, and fixing them.
- Determining whether your posts and pages can be converted to blocks adequately.
- Testing out the content creation process and fixing any concerns you have.
At this stage, it’s important to mention that you don’t have to upgrade your live site to WordPress 5.0 straight away. You can essentially test for as long as you need in order to get things perfect.
However, if it transpires you’re not yet ready for the upgrade to the new editor, you can install the Classic Editor plugin, which ultimately gives you WordPress 5.0 and the previous editor. The good news is that this version will be supported for the next few years.
Conclusion
WordPress 5.0 is now here, so you’ll need to work fast to test the new editor out with your live site (if you haven’t already done so). It’s a massive change to the platform, so it’s in your best interests to be as prepared as possible.
In this post, I went over how to test out WordPress 5.0 and the new editor on your site in a snap using Local. Let’s recap the steps quickly:
- Create a local site using Local.
- Backup or clone your live site
- Migrate your files to your local environment.
- Update to WordPress 5.0, then thoroughly test the new additions.
Do you feel fully prepared for the transition to WordPress 5.0? Let me know in the comments section below!
Comments ( 6 )
Teshome Woldeamanuel
January 29, 2019
I have a website based on wordpress.com. Is it possible to transfer using my domain and host including all my contents to Gutenberg Editor? What would be the cost?
David DeWitt
January 5, 2019
If I’m already being hosted by Flywheel why wouldn’t I just set up a staging site with Flywheel rather than set up a Local site on my own computer?
Joshua Masen
January 9, 2019
Hey David, you could definitely do that also! We tend to follow the workflow of testing larger changes in a local environment first, then refining the update in staging before going live. It's really just a matter of what works best for your own workflow! :)
getpremium
December 18, 2018
thank for this great information. i learnt alot from this post.
Steve
December 7, 2018
Hi Will,
Forgive me if this appears twice but I'm not sure the last comment went through.
I'd like to know what the benefits of using the method you describe above would be over using Local to pull the live site, test and when happy all is well, push back to the live site?
Steve
December 7, 2018
Thanks for the article Will,
If I have a live site on Flywheel could I not use Local to pull the live site, test it and if all okay push it back to the live site without having to go through the process of installing more plugins to archive etc.?
Joshua Masen
December 10, 2018
Hey Steve, you're spot on! If your site is hosted on Flywheel, you can skip the plugins and importing, and simply pull down your live site for testing in Local :)
Mark
December 7, 2018
Do you have a plan or any suggestions for those running a multisite setup? The Local by Flywheel does not work with multisite. Each site has a different theme, functions and plugins.
Benjamin Turner
December 7, 2018
Hey Mark,
Local does work with Multisite WordPress installations.
When you create a new site, on the "Setup WordPress" page. On that page, expand "Advanced Options" and select the kind of Multisite installation -- either "Subdomain" or "Subdirectory".
Importing a multisite installation into Local is a little more work, but that's true for any migration of a Multisite due to the way that urls are stored in the Database.
I would recommend taking a look at this post in the community forums for more information on getting a WordPress multisite imported into Local:
* https://local.getflywheel.com/community/t/multisite-migration-live-to-local/4576
If you have any more questions, please reach out and create a new post in the community forums:
* https://local.getflywheel.com/community/c/support
-- Ben