I’m a fan of using both Homebrew and Valet when it comes to setting up and configuring a basic WordPress development environment. Though using package managers and simple software for such like this should make things easier, it doesn’t absolve us from the occasional problems.
Case in point: There are times in which we may have to update our TLD to play nicely with Chrome and other browsers, or even upgrade the entire installation.
Unfortunately, it’s not always as easy as it should be. Technically, we should be able to uninstall Valet and update it via Composer. But I’ve personally run into some problems that relegated having to:
manually uninstall Valet,
use Homebrew to uninstall PHP and clean up what was left completely,
reinstall Homebrew packages,
verify the browser uses the same version of PHP as the installation of Valet.
It sounds like a lot of work for something that should more or less “just work” and it is quite a few steps, but they are pretty quick to set up.
For years, developers have used the dev top-level domain as a way to work with local development versions of their projects.
But Google changed all of that last year.
If you’re interested in reading a bit more into this, check out the post by Justin from WebDevStudios does a good job of going into some of the details (as does this post via Daryl Koopersmith – previously working on WordPress, now working at Medium).
But for this post, I’m trying to keep it short and pragmatic. So, the former is this:
If you’re using HTTPS and a dev domain on your local machine, it’s likely going to stop working. Yes, you can add an exception with some browsers, but not all.
If you’ve read this blog for any particular length of time, then you know that I’m a fan of using Valet as part of my local development environment. Part of doing that means that I also secure the local sites to simulate, as much as possible, but staging and production are going to be like.
By default, Valet uses dev as it’s top-level domain, so how do we change that? Luckily, it’s pretty easy.
Some time ago, I went back to using Valet for local development, and I’ve been happy with it since. Up until sometime last week, I’d yet to run into any problems.
But when working on a WordPress plugin that imports data using admin-ajax, I kept getting a curious message in the console no matter how large or small the data was. Specifically, I was getting an error about “502 (Bad Gateway).”
The server, while acting as a gateway or proxy, received an invalid response from an inbound server it accessed while attempting to fulfill the request.
And if you try to diagnose it based on thatdefinition, you won’t get very far. It’s not that it’s wrong, but it’s that you need to modify your server configuration.
I’ve written a number of posts about Valet (here and here) and why I think it’s a solid option when it comes to working as a local web server for WordPress-based development.
It’s easy to setup, it’s got built-in support for WordPress, it uses Nginx (which is often faster than Apache is my experience), and it provides a great way to allow others to tunnel into your machine for testing if that’s something you’re into doing.
But if you’re someone who spends time debugging both through Xdebug and through reading through error logs, then you may be interested in reviewing the Valet error logs (if you can find where they are kept) when debugging your projects.
Just Getting Started with WordPress? I write a lot about WordPress development but if you're just getting started, I recommend checking out WPBeginner. They have free training videos, glossary, and more.