UPDATE Jan. 2017
Pressmatic has been bought by Flywheel. And they’ve gone and made it free! They’ve changed the name to Flywheel Local. I’ve updated the article below to take into account the acquisition.
I’ve long recommended DesktopServer as my preferred local development server.
The Musket developer theme framework of which I’m the author, is built around a quick-to-deploy DesktopServer Blueprint.
However, we’ve been waiting a long time for v4.0 (come on guys!) And now there’s a new kid on the block.
Hello Pressmatic Flywheel Local
Out of nowhere, Pressmatic (now Flywheel Local – see the update notice above) has arrived on the scene and delivered pretty much everything that ServerPress have been promising for DesktopServer 4.0.
It never pays to rest on your laurels!
DesktopServer vs Flywheel Local
This is a how-to, not a review, but I’ll give you a quick run-down on the differences between DesktopServer and Flywheel Local.
| Flywheel Local | DesktopServer | |
|---|---|---|
| Supported OSes | MacOS (Windows coming soon apparently) | MacOS, Windows, Linux |
| Technology stack | VirtualBox & Docker. Separate container for each site. | XAMPP. |
| Server | Hot swappable Apache or nginx. | Apache. |
| Database server | A MySQL instance with one db per site container. | One MySQL instance for all sites. Each site gets one db on the global instance. |
| PHP | Hot swappable versions 5.2.5, 5.2.17, 5.3.29, 5.6.20, 7.0.3 | 5.5.24 |
| xdebug | ✔ | ✔ |
| ssh / wp-cli | ✔ | ✔ (Via ds-cli) |
| SSL enabled sites | ✔ | ✘ |
| Multisite? | ✔ | ✔ |
| Site templates | ✔ (Lets you control which files are included / ignored.) | ✔ (Called Blueprints, no control over files included / ignored. Kills .gitignore.) |
| Site export | ✔ | ✔ (Via Blueprint) |
| .zip archive import | ✘ (Coming soon) | ✔ |
| Direct deploy | ✘ | ✔ (Although it’s flaky) |
| Remote tunnel | ✔ | ✘ |
| Mailcatcher | ✔ | ✔ |
| Other plugins | Bypass login, airplane mode, local admin colour bar | |
| Price | Free | $99.95 per year |
A note about updates
To update DesktopServer, you have to download the latest version from your ServerPress account and run an installer.
Flywheel Local updates from within the app and can be set to autoupdate.
Historically, DesktopServer updates have been known to trash a local dev environment. And because all sites run on the same Apache/MySQL instance (and you can’t change the PHP version) if one site breaks, they all break.
Flywheel Local’s updates are untested as it’s still new. However, because each site is containerised, and you can hot-swap the server software and the PHP version (although not the MySQL version as far as I know) the risk of all sites going down is minimal.
Other notes
Flywheel Local’s UI is much cleaner, with a great notification system that uses MacOS’s in-built notifications. It also handles permissions in a much saner way than DesktopServer. Starting DesktopServer, only to have to immediately restart it has always driven me bonkers!
Flywheel Local feels quicker. No doubt a lot of that is due to PHP7, but I haven’t experienced any of the random, temporary slowdowns you sometimes get with DesktopServer. The virtualised containers should also work in Flywheel Local’s favour here.
Flywheel Local takes up more HD space than DesktopServer. This is mainly due to VirtualBox being installed too. If you already have VirtualBox, that won’t be so much of an issue.
However, each site in Flywheel Local seems to be about 100mb bigger than the equivalent site in DesktopServer. If you have a hundred local sites, that adds up.
One last thing to note: Flywheel Local and DesktopServer can run side-by-side. As long as your development URLs don’t clash between the two apps, they will happily run at the same time. If you went through the pain of moving from XAMPP/MAMP to DesktopServer, you will appreciate what a boon this is. It’s another benefit of the virtualisation technology that powers Flywheel Local.
Should you switch to Flywheel Local?
Let’s get one assumption out of the way. If you’re a DesktopServer user and are considering Flywheel Local, I’m assuming you have no interest in Vagrant / VVV (and the configuration headaches that come with it). In that case, there is one overriding reason you should choose Flywheel Local: PHP7.
PHP7 will almost certainly become the de-facto PHP version for serving WordPress in the near future. There are plenty of hosts offering it at the time of writing and more will follow. PHP7 gives a significant performance boost to most WordPress sites and compatibility issues are becoming fewer by the day.
Although WordPress core is fully PHP7 compatible, there are still some plugins out in the wild that might not be.
Flywheel Local gives you the ability to quickly and easily test your site locally in a PHP7 environment. If things don’t quite work just yet, simply swap the environment back to 5.x and carry on working on the site until it does.
ServerPress have mentioned that DesktopServer will support PHP7 in v4 (although nobody knows when that will be). But unless they move away from a XAMPP setup (which is possible) it will be an all or nothing affair – no hot-swapping of PHP versions. If you’re a loyal DesktopServer user, you may be happy to wait and see.
Jan. 2017 update: Now that Flywheel Local is free, there’s really no reason not to try it out!
How to migrate a site
OK. So you’ve taken the plunge and installed a copy of Flywheel Local. You’ve discovered how easy it is to add a new site. But what if you want to move a site from DesktopServer to Flywheel Local?
Here’s a quick guide…
1. Add a new site to Flywheel Local
Fire up Flywheel Local and add a new site. Don’t give it the same domain name as the site you’re intending to migrate from DesktopServer. If you do, there will be a clash when you run Flywheel Local and DesktopServer at the same time. DesktopServer tends to prefix domains with ‘www.’. Flywheel Local doesn’t use a subdomain by default, so you should be safe to use the automatically generated domain name.
2. Back-up wp-config.php
Copy the Flywheel Local version of the wp-config.php into a folder outside of the new site’s directory structure. Note that in Flywheel Local the WordPress directory is at /your-local-folder/site-name/app/public.
3. Clear out the new site files
We need to copy the site files from the old site to the new site, but first, it’s safest to clear out the existing WordPress directory. Remember the WordPress directory lives in /site-name/app/public. Delete everything in this directory.
4. Copy site files from the old site to the new site
Now we’re ready to copy files.
If you’re using Git for version control you’ll want to copy the .git directory. Most development sites built with modern development tools will include a number of other .dotfiles (.bowerrc etc.). Most sites utilise a .htaccess file too. These .dotfiles and folders are typically hidden by your OS and won’t be copied using the OS’s GUI interface. If you’re on a *nix system (including MacOS) you can use the following command at a terminal to copy everything across:
cp -rf ~/websites/www.site-name.dev/ ~/Local\ Sites/site-name/app/publicJust update the directory references to suit your setup.
5. Restore the Flywheel Local wp-config.php
Now copy your backed-up copy of wp-config.php back into /site-name/app/public.
6. Activate the correct theme
At this point, you should be able to navigate to /wp-admin on the new domain and activate the correct theme (you may also get a database upgrade notification – do it). Check the front-end to make sure the site is functioning. If you get a White Screen of Death (WSOD), open wp-config.php in your text editor and enable debug mode. This should give you an indication of why the site isn’t functioning. Fix it!
7. Populate the database
We’ve moved the codebase, now it’s time to move the contents of the database.
If the site you’re moving locally is also running remotely in staging/production and you’re using a tool like WP Migrate DB Pro then you can simply pull the database down to populate your new local copy with up-to-date content.
If not, you can use a tool like WP Migrate DB Pro or DesktopServer itself to create a SQL file you can import into your new site on Flywheel Local.
With WP Migrate DB Pro
To create a SQL file with WP Migrate DB Pro, navigate to Tools > Migrate DB Pro on your original development site.
Choose “Export File” and check the “Save as file to your computer” checkbox. Don’t bother checking “Compress file with gzip”.
Fill out the “Replace” fields with the relevant data for your Flywheel Local install. Here’s an example:
| Find | Replace |
|---|---|
| //www.old-site-name.dev | //new-site-name.dev |
| /Users/dave/websites/www.old-site-name.dev | /Users/dave/Local Sites/new-site-name/app/public |
Just remember that DesktopServer tends to put “www” at the front of its domains whereas Flywheel Local doesn’t (although you may have overridden this in either app).
Also, DesktopServer tends to use the whole domain name as the folder name whereas Flywheel Local just uses the site name (but again, you may have overridden this in either app).
Export the migration file.
Back in the Flywheel Local app, select your new site and open the “Database” tab. Click the “Adminer” button to open Adminer (used to directly edit the database associated with your Flywheel Local site).
From the column on the left choose “Import”. Select the SQL file you created with WP Migrate DB Pro and hit “Execute”.
Your Flywheel Local site’s database should now be populated with the contents of your old dev site’s database.
With DesktopServer
The process is similar with DesktopServer, if slightly overkill.
To get a SQL file out of DesktopServer we need to create a “BluePrint”. This will export the entire site, codebase and all. The SQL file is created in the root of the Blueprint. We can use it to import into the Flywheel Local database via Adminer just as we did above.
To create the Blueprint open your DesktopServer app and choose “Export, import or share a website”.
Next choose “Export or deploy a WordPress website”.
Now choose the site you want to export from the dropdown menu. In the “Export As” input, enter the domain name of your Flywheel Local site.
Leave the radio button set to “Export to a website archive (.zip file)” and hit the “Next >” button.
On the next screen you can leave all the settings at their defaults and hit “Next >”.
Now you can choose the name of the .zip file that’s created and the output folder (neither is critical).
It’s crucial that you check the box for “Customize scrubbing options” before hitting “Next >”.
The app will analyze the database for a while before presenting you with similar options for find and replace as we saw with WP Migrate DB Pro above. Here’s an example of the settings to enter, but make sure you adjust for your setup:
| Find | Replace | Within |
|---|---|---|
| /Users/dave/websites/www.old-site-name.dev | /Users/dave/Local Sites/new-site-name/app/public | Database |
| \\Users\\dave\\websites\\www.old-site-name.dev | /Users/dave/Local Sites/new-site-name/app/public | Database |
| www.old-site-name.dev | new-site-name.dev | Database+Files |
Hit “Next >” again and your Blueprint will be created.
The next job is to unzip the Blueprint and retrieve the SQL file that is in the root.
As above, select your new site in Flywheel Local, choose the “Database” tab and open Adminer. Click “Import” in the column on the left and select the SQL file from the Blueprint. Hit execute and your database should populate with the content from your DesktopServer site.
Job done
Whew… that feels like a lot, but it’s really not that tricky to migrate from DesktopServer to Flywheel Local once you understand the process. Especially if you can simply pull down the database content from a live server with WP Migrate DB Pro.
Apparently, importing directly from a .zip (like a DesktopServer Blueprint) is on the roadmap for Flywheel Local. Until then, the above process works well.
Let me know how you get on in the comments.
À bientôt.
