Switching Away From MAMP Pro

Why Make The Switch?

We’ve been using MAMP Pro since version 1.x for most of our local testing and development. But after the release of version 5, MAMP Pro has been very buggy and annoying to use. For me, the AMP (Apache, MySQL, and PHP) environment worked well, it was MAMP’s UI that would freeze and turn my cursor into a spinning beach ball accompanied by the message “Application Not Responding.” I would have to force quit and restart the app every time I needed to make a change. And after spending some time troubleshooting by deleting hosts to limit the number, uninstalling/reinstalling MAMP Pro, switching PHP mode to identical/individual versions, etc, it turned out that interacting with MySQL was causing the UI crashes. These crashes occurred when using terminal to import or export MySQL databases or when running the same database commands from phpMyAdmin. I have to import databases locally all the time so this was driving me absolutely crazy. I had searched the internet and tried many alternatives to MAMP Pro but had no luck.

One day I came across an open-source webserver called Caddy that looked very interesting to me. I started reading through their documentation about setting up a local hosting environment which later led me to their forums. Particularly this one [Guide] Local web development setup on a Mac. It starts off by listing all the formulas I have to install using Homebrew; caddy (of course), dnsmasq, php, [and mariadb] along with configuring a Caddy .plist file. My first thought was, “that’s definitely not like MAMP;” and I’ve been through the whole local server install path before. Then I scrolled down to a commentator that said “Another great option is Laravel Valet. [It] does all this fanciness out of the box!” I was like “well hell, now that sounds like MAMP to me”.

Sunset MAMP Pro

What I’ve Switched To

Laravel’s Valet turned out to be a great and easy to use option. The documentation page stated that Valet supported Drupal and WordPress, among others, right out of the box. Given that most of our work is in Drupal or WordPress it was easy to see I came to the right place. It requires using Homebrew to install PHP 7, which is easy enough, and Composer to install Valet. We use Composer for working with Drupal and WordPress so that tool was ready to go on my machine. Valet doesn’t install a database so I had to brew install mariadb as well.

One feature that Valet (and MAMP Pro) has is the option to run a site from any directory. This was a big requirement for me and a feature some of the alternatives I tried didn’t have. Simply cd to a sites docroot directory and type valet link example. After which I could go to http://example.test and get right to work. Additionally I can set up a local cert for any site by typing valet secure example, and now I can go to https://example.test. This is so easy compared to MAMP and it just works.

A Few Caveats To Share

Here are a few issues I came across and wanted to share in hopes it will help someone else interested in switching to Valet.

1. DNS

I preferred to use either .com, .net, or .org at the end of all my local host names, e.g. local.example.com. This way I could easily remove local or change it to dev to bring up the live or development website. Valet uses DnsMasq and appears to allow for only one TLD (top-level domain), so I went with .test and it has worked out very well. You can read more about TLDs for Testing from the Internet Engineering Task Force.

2. Nginx / Valet - 502 Bad Gateway

Drupal 8 was giving me the Nginx - 502 Bad Gateway error along with “upstream sent too big header while reading response header from upstream” which I found in the Nginx log. This could mean a few things but seems Drupal was sending too many http requests which I’m guessing was caused by not having aggregation enabled for CSS and JS. To fix this, I needed to increase the proxy_buffer and fastcgi_buffer size for Nginx.

Create ~/.valet/Nginx/all.conf and include:

Append this to /usr/local/etc/nginx/fastcgi_params:

I found the fix on a Github issue: Valet 2.0.3: 500 Bad Gateway (upstream sent too big header). Once applied, you’ll need to run valet restart && brew services restart php@7.x

3. PHP

PHP memory_limit settings can be adjusted in this file: /usr/local/etc/php/7.x/conf.d/php-memory-limits.ini

I typically increase the memory by adding: memory_limit = 512M

Again, once applied, you’ll need to run valet restart && brew services restart php@7.x

4. WordPress Multisite

The last caveat that hung me up for a bit was a WordPress Multisite. It wanted an .htaccess file for permalinks, but given Valet uses Nginx instead of Apache that wasn’t going to work. Turns out I needed to use a custom Valet driver and after vetting a few I ended up using this gist WordPressMultisiteValetDriver.php. As it states, create a file in the ~/.valet/Drivers/ directory and then you’re good to go. Well, after running valet restart && brew services restart php@7.x of course.

Add new comment

Restricted HTML

  • Allowed HTML tags: <a href hreflang> <em> <strong> <cite> <blockquote cite> <code> <ul type> <ol start type> <li> <dl> <dt> <dd> <h2 id> <h3 id> <h4 id> <h5 id> <h6 id>
  • Lines and paragraphs break automatically.
  • Web page addresses and email addresses turn into links automatically.