One of the cool things about my job as Developer Educator at Delicious Brains is that sometimes I get to try out new things that I might otherwise never discover. Over the past few months, I’ve been testing out two new local development environments: Craft Nitro and DevKinsta.
And you thought WordPress had drama!
The developers behind Craft CMS also decided to build and release their own local development environment, explicitly tailored to Craft CMS developers. It was officially launched in early 2020 and was built on top of Multipass, an application created by Canonical, the folks behind Ubuntu. Multipass provides a virtualization platform similar to Vagrant with Virtual Box or Docker, but is easier to use and set up and uses fewer resources. Unfortunately, at the time, Multipass had a series of bugs that were frustrating users, so they decided to switch to using Docker instead.
That’s a pity because I think Multipass has the potential to be the next big thing in local development environments. It just needs some time to mature as a platform.
Because Craft CMS and WordPress have similar technical requirements, we thought it might be interesting to see if Nitro would work as a drop-in local development environment for WordPress.
Installing And Configuring Craft Nitro
The first thing about Nitro is that it’s pretty technically challenging to set up. Everything is detailed in the installation instructions, but you will need to install Docker yourself first. Depending on what operating system you use, this can vary in difficulty level.
Once you have Docker installed, there are a few alternative installation options, depending on your OS.
If you’re on macOS or Linux, you can run a single terminal command to install Nitro.
This downloads and runs the installer script, which downloads and installs the Nitro executable.
Because I am on Linux, I also needed to copy the nitro executable to a specific directory by running
sudo cp ./nitro /usr/local/bin/nitro. This allows any normal system user to run the nitro executable.
On macOS, you also have the option to install Nitro via Homebrew. Windows users have a slightly more involved set of install steps, making use of WSL 2, so best to check the install doc.
Then, you run
nitro init to initialize the Nitro environment. The process asks you some questions about what specific environment configuration you want and sets everything up.
Adding or Creating a Nitro Site
Once you have Nitro installed and initialized, you can run the
nitro add command inside any website project directory. This will ask you about which hostname you would like to use for the site, as well as which PHP version you want to use. It will also ask if you want to create a database and ask for the database name. Once it has all the data it needs, it will go ahead and configure the site for you.
As soon as this is done, you can browse to your local URL (in this case,
new-site.nitro) and see an Nginx error page, which is expected because the Nginx server doesn’t have anything to display for that site.
You can also use
nitro create, requiring you to pass a parameter for the project name. This will create a new Craft CMS project directory and install the Craft CMS code, ready for Craft CMS development. Not ideal for WordPress development, but useful to know.
Nitro automatically includes things like the DynamoDB and Redis services. However, if you don’t need these things, it’s a bit of overkill. Obviously, it’s tailored to Craft CMS development, and I assume Craft CMS developers use those services. I do like the fact that it comes bundled with MailHog, which is a great way to test email sending on a local development environment.
Using Nitro For WordPress Development
I wanted to see if Craft Nitro could work with WordPress, so my next step was to download and extract a copy of the WordPress core files to a local
wordpress.test site I had set up with Nitro. I already have WP-CLI installed on my workstation, so I could just run
wp core download inside the site directory. If I didn’t have WP-CLI, I’d just download and extract the archive from WordPress.org.
Next up, I decided to run the famous 5-minute install. I know I can do this via WP-CLI, but I wanted to see if I could do it the usual way, through the WordPress installer. Unfortunately, that’s where things started to go wrong.
The first problem I encountered was that the default database username and password weren’t documented anywhere I considered logical. That’s probably because most Craft CMS developers will use
nitro create, which also sets up the project credentials for you. After some digging, I found the details at the bottom of the Project Setup help doc. I also learned that running
nitro context on the command line inside the project directory outputs the database name, username, password, and hostname.
With those details, I clicked through the WordPress installer. I got to the database credentials screen, entered the relevant details, hit Submit, and was presented with a generic WordPress “critical error” message.
Because the error message didn’t really help me understand what was going wrong, I started digging. I first checked the PHP error log, but nothing was reported. So I tried stepping through the
/wp-admin/setup-config.php file using Xdebug and PHPStorm and learned that this file disables PHP error reporting.
I turned this on, which lead me to discover that Nitro does not enable the PHP
mysqli extension by default, which WordPress needs. After some reading through the Nitro docs, I fixed this by running
nitro extensions inside the project directory and enabling
The error changed this time, and WordPress gave me the
Error establishing a database connection error screen. As I had turned on PHP error reporting earlier, I looked in the PHP error log, and saw the following error reported.
To my limited understanding of how Docker works, this error meant that the Docker instance that powers the site could not resolve the hostname of the Docker instance that powers the database, so WordPress couldn’t connect to the Docker database instance. So I used the
nitro ssh command to log into the Nitro Docker instance and pinged the database hostname that Nitro creates. This gave me the IP address of the database instance, which I used in the WordPress setup instead of the hostname, which worked.
So eventually, I have a working WordPress install using Nitro, but it was a bit of a pain to get it installed. I’m not sure if that database IP address will ever change, meaning I’d have to update my wp-config.php if it ever did. I’m also not entirely sure everything else will work as I expect it to, and by the time I managed to get WordPress installed, I was too frustrated to care to find out.
To be honest, I was a little disappointed. Sure, Craft Nitro is made with Craft CMS in mind, but so is Laravel Homestead or Laravel Valet made with Laravel in mind. The difference is you can run WordPress out of the box with either.
On the other end of the Docker-based WordPress local development environment landscape is the newly released DevKinsta, from the folks at Kinsta. If you’ve not heard of Kinsta, they are a managed WordPress host that launched around the same time as Craft CMS. To the best of my knowledge, they were one of the first to build their entire technology stack on top of Google’s Cloud Platform and have quickly become a popular managed WordPress host.
Following in the footsteps of Flywheel’s LocalWP offering, Kinsta released DevKinsta as a way to design, develop, and deploy WordPress sites from your local machine. The goal of tools like LocalWP and DevKinsta is to give you the ability to use the benefits of Docker for local development with WordPress but without all the hassle. DevKinsta is aimed at both those who would develop on or for WordPress and those who would just use it to build WordPress sites for clients, using no-code tools like the Block Editor or Elementor.
Installing And Configuring DevKinsta
Clicking on the download link on the DevKinsta site will present you with links for installers for Ubuntu, Windows, and Mac. I’m guessing that DevKinsta doesn’t anticipate any possible users running non-Debian-based Linux distributions. That, or they’ve done their research, and they know this is not the case. Either way, it was nice to see a Debian install option available about four months after the initial Mac and Windows versions were launched.
When you visit the download page, a “Sign up to download DevKinsta” form appears and asks you to enter your email address to access the download. The actual download links are just below the form, and in my case, I could just ignore the form and click the download link.
Once you run the installer, it handles everything else for you, from downloading and installing Docker to configuring the Docker containers. It does take a little while to get everything set up, so once you kick things off, you can grab your choice of beverage and let the installer do its thing.
One thing to note is that, depending on your internet connection, it can take a long time to download and install everything before you can start building websites. I boiled the kettle, brewed my pour-over, and drank my coffee before it was all finished.
Using DevKinsta For WordPress Development
Being built by a managed WordPress host means that DevKinsta is built for use with WordPress. From the dashboard you can create a new local WordPress site using the defaults DevKinsta provides, download any site from your Kinsta account (if you have one) to use with DevKinsta, or create a custom site, which mostly allows you to customize things like the PHP version or the WordPress version.
Like Nitro, DevKinsta will handle things like mapping a local hostname to your site, so you can browse it in a web browser and map the database instance hostname so that the WordPress site can talk to the database. But, unlike Nitro, this all works perfectly out of the box for WordPress.
I liked the site dashboard. It’s clean but gives you all the site info you need and includes links to open the site locally in a browser, push the site to your Kinsta staging environment, view the database manager (which uses Adminer), or open WP Admin. You also have options to view the local site’s email inbox (I assume this is if the site has sent out emails, and you need to view the contents).
DevKinsta also has some nice touches in the settings that I appreciated, like configuring your local site’s directory, if you don’t want to use the default DevKinsta uses, or setting a default admin username and password for newly created local sites.
My biggest gripe with any of these host-based local environment tools is that they don’t support any other hosting platforms. From a marketing/business point of view, I understand the reason behind making it possible to push a local DevKinsta site to Kinsta hosting. Still, I’d love to see one of these tools make it possible to configure FTP and database details for any other type of hosting. As someone who niched down his freelance WordPress development career in the plugin development space, I rarely was part of the client’s hosting decisions, and so it means I could never use any of these tools.
I probably shouldn’t complain, though, because then we wouldn’t need products like WP Migrate DB Pro, and I might be out of a job!
The WordPress local development environment space is interesting. I recently posted a question about this on Twitter and had at least 12 (if not more) options mentioned, including applications that have been around forever, like MAMP and XAMPP.
And I understand why. These applications are tried and tested, don’t rely on any specific hosting platform, and just work.
They do have limitations though, which is why host-based solutions like DevKinsta exist. If you’re not specifically a Flywheel customer, but you use LocalWP and are considering trying out DevKinsta, I recommend it. I’ve used both, and they’re both good, so really, it’s up to personal preference. Of course, if you are a Flywheel customer or a Kinsta customer, then using each host’s local development tool makes complete sense. I’m just not convinced someone would switch hosting based on the local development tool they offer.
As for Craft Nitro, I can’t say I’d recommend it as a WordPress local development solution. I do like some of the things it offers, but It’s too tied to the Craft CMS.
What is your preferred local WordPress development environment? Do you use some modern Docker solution or rely on tried and tested apps like MAMP? Let us know in the comments.
This content was originally published here.