Local “Lightning” first impressions
Local “Lightning” is the latest iteration of Flywheel’s popular local development environment. Local is a suite of web server components that allows you to run PHP applications on your computer – a vast improvement on the bad-old-days when we had to FTP files to a remote server to test our work. Shudder.
Flywheel is a WordPress hosting provider so Local is aimed at WordPress developers, but can theoretically be used for any PHP application regardless of where it will be hosted.
I ignored Local for a long time because early versions ran inside a virtual machine. In my experience virtualisation is painfully slow, even on fast host systems, and by many accounts that was the case with Local too. In fact performance was bad enough that Flywheel decided to rebuild Local from scratch as a native application. They even dubbed the new version “Lightning” to emphasise the speed boost.
I am a long longtime MAMP Pro user, and despite having no major complaints about MAMP I was curious about Local’s new direction and recently took it for a spin.
Unfortunately, things got off to a rocky start. After launching Local and configuring my first site, my browser hit me with a 404. After some head scratching I deduced that there was a conflict between MAMP and Local. MAMP was listening on ports 80 and 443, which are the standard HTTP and HTTPS ports, and was blocking Local from doing its thing. After quitting MAMP and restarting my computer Local’s server ran smoothly. Little did I realise that my port-hijacking woes were far from over – more on that shortly – but for now let’s focus on the positive.
Once I got Local up and running, its features really impressed me.
Installing a new site with Local takes about 30 seconds. A setup wizard asks you a few basic questions about the site – what is it called, what username and password you want for your WordPress admin user – and then it installs a fresh copy of WordPress for you, pre-configured and ready to go. It really couldn’t be simpler.
One-click certificate trust
In this day and age every website should have an SSL certificate. When you’re developing locally this may not seem important, but having a certificate ensures that your WordPress database doesn’t get polluted with http:// prefixed URLs. Plus, eCommerce applications will complain loudly if you try to make a transaction using an unsecured connection.
With MAMP, the process of adding a self-signed SSL certificate goes like this:
- Generate a certificate inside MAMP
- Choose a location to save it on your hard drive
- Navigate to that location, and drag the certificate into Apple’s Keychain Access app
- Double click the certificate to edit its preference, and change the Trust setting to “always trust”
- Type your macOS password to authorise the change
I’ve done it so many times that this process takes me about a minute, but it still irks me that I need to jump through these hoops.
When you create a site in Local it creates a certificate for you automatically. Then, you can trust the certificate without leaving the app (trusting a certificate stops your website browser from displaying a security warning).
My one niggle with this feature is that Local doesn’t configure WordPress to use HTTPS by default. You’ll need to change WordPress’ home and site URL to use the https:// prefix yourself.
Automatic database dumps
This is a big one. After working with MAMP for years I have resigned myself to the fact that to back up a site’s local database I need to manually export it to disk. Local has an elegant solution to this problem. Anytime a site is stopped within the Local application, a database dump is performed. No more manual MySQL dumps!
One of the drawbacks of developing locally is that without a mail server none of your site’s transactional email is delivered, which makes testing difficult. For instance you can’t verify that an eCommerce system is actually sending order notification emails.
Local comes bundled with Mailhog, a nifty application that runs a simple SMTP server that “hogs” any mail sent from your site so that you can view it later. As someone who’s gone without this feature for so long, it feels like magic.
Config and files stored together
Unlike MAMP, which stores each site’s configuration files who-knows-where, Local stores them right next to your application’s database and public files. It feels very tidy to have everything in one place.
To import a website into Local, you can simply drag a .zip file into the app. The only requirement is that the archive needs to contain a WordPress wp-content directory and an SQL database file.
If the domain of the site you’re importing doesn’t match the .local domain you chose in Local, you will be prompted to fix the issue, which will perform a find & replace in the site’s database. It gracefully handles serialized data too, which a naïve find & replace won’t.
Sequel Pro integration
Local uses Adminer to let you administer your site’s’ MySQL databases, but it will also detect if you have Sequel Pro installed and give you a button that opens a database in Sequel. It’s a nice touch that shows Local’s developers are in touch with their user’s workflow (or they just really like Sequel Pro).
Free as in beer
Did I mention that you get all of this for free?! There is a paid version of Local, but as far as I can tell its additional features only benefit Flywheel’s hosting customers.
Remember how I said that my port-hijacking woes weren’t over yet? I ran into more problems when I needed to fire up MAMP to work on one of my other projects. I knew that Local and MAMP didn’t play nice together, so I quit Local first, but MAMPs server still didn’t seem to be responding. For some reason Local wasn’t releasing ports 80 and 443 when I quit the application.
After extensive debugging I concluded that the problem is specific to macOS High Sierra, since it doesn’t affect my MacBook which runs Mojave. On High Sierra Local installs a launch daemon that starts NGINX when the OS boots up, and never stops it again. It is an obscure bug (feature?) that most people won’t notice, but it irritated me so much that I upgraded to Mojave!
No subdirectory or custom table prefix
Another shortcoming of Local is that it doesn’t officially support installing WordPress in a subdirectory, or choosing a custom database table prefix (which the standard WordPress installer does).
Ultimately not a big deal, but if you’re accustomed to changing the installation directory or table prefix then you might find Local restrictive in this respect.
No hot swapping or Apache
Unlike its virtualised predecessor, Local Lightning doesn’t offer an option to hot swap between different versions of PHP, or between Apache and NGINX. These features are on the roadmap, though.
Overall I’m very impressed by Local. It is an elegant software suite that improves on MAMP in some important ways. Local is a little more prescriptive than I’m comfortable with, but I guess that’s the price of its simplified workflow.
“Lightning” has only been out of beta for a couple of weeks, so of course it’s not perfect, but the development team seem to be hard at work adding features and squashing bugs, and I am optimistic that it will continue to improve.
2 thoughts on “Local “Lightning” first impressions”
Since the latest update of Local, I have been unable to create any new sites. I keep getting an error about Local not being able to access the hosts file. Never had this issue until the latest update, which is currently 5.5.3. I spent hours trying to figure out how to resolve this. Tried everything with no luck. Sent a question to Local, and they were totally unresponsive. I’ve since moved to Laragon, which is causing me no problems whatsoever and is MUCH faster than Local.
I moved to Laravel Valet after writing this post. The Local GUI is nice, but I felt uncomfortable about working with software that was so closely tied to a hosting provider.
Comments are closed.