Improve MAMP for WordPress local dev with 3 upgrades
Web development tool MAMP is a local server app which I love because it’s 1) free 2) it’s a little bit hard to use, which forces you to dig into the code and learn things to get it to work. Here are three things I’ve learned lately to make it work better for WordPress projects.
I’m using MAMP version 4.2.1 on a MacBook Air running macOS High Sierra.
Use the ImageMagick library
MAMP’s PHP libraries come packaged with ImageMagick, a superior processor for working with images via the WordPress Media Library than GD. ImageMagick won’t strip color profiles from images by default, has compatibility with more file types (like making thumbnail previews for PDFs), has excellent optimization and resizing features and is what WordPress will use when it’s available. So let’s make it available for our development.
The ImageMagick integration for PHP is called Imagick. To turn it on, we just have to uncomment one line of code from the PHP version we’re using.
Check your PHP version in the MAMP preferences. You’re using PHP7, right?
In the Applications folder, navigate to MAMP > bin > php and chose your version. I’m using php7.1.8. Open the conf folder and open the php.ini file with a text editor.
Here’s the full file path we’re looking for for this version:
/Applications/MAMP/bin/php/php7.1.8/conf/php.iniWe can open it with a text editor with a Terminal command. I’m using Atom, but you could open it with a native command line editor such as Nano.
$ atom /Applications/MAMP/bin/php/php7.1.8/conf/php.ini(If you’re new to Terminal, don’t type the $. It’s there to indicate you’re on the command line when using the command and not writing some other code.)
In the php.ini document we’re looking for this line:
;extension=imagick.soThe ; marks a comment. Delete the semi-colon to un-comment it and enable the extension, save, and restart MAMP. Rinse and repeat for other PHP versions to activate ImageMagick on all of them. Make sure to test for any compatibility issues.
You can read more about ImageMagick and its workflow capabilities at Smashing Magazine.
Get WP-CLI to work with MAMP
WP-CLI is one of the biggest upgrades you can make to your WordPress development, but it can occasionally trip over MAMP. If you’ve installed WP-CLI in a typical location, it’s not using the same version of PHP as MAMP, which means commands like database imports can break. We just need to point it in the right direction.
We’ll do this by adding MAMP’s PHP folder to our bash path, so when we run WP-CLI commands from our shell session, it will be able to interact with the right PHP.
From the command line, open your bash profile with a text editor. Let’s use nano this time.
$ nano ~/.bash_profileNow we’ll add the PHP path. I’m going to use PHP7.1.8 from above, except we need to point it to the /bin folder, not /conf folder we used to edit the php.ini file.
The full path is: /Applications/MAMP/bin/php/php7.1.8/bin
So we’ll add this line of text (without the $):
$ export PATH="/Applications/MAMP/bin/php/php7.1.8/bin:$PATH"Save and exit the file and close and re-open Terminal. WP-CLI should be ready to go.
Thanks to Christopher Geary at Indigo Tree for sharing this fix.
As with the ImageMagick edit, if you upgrade your PHP version, you’ll have to do this process again.
Adding virtual servers for better domain names
If you’re using MAMP to work with a single WordPress installation, working with the http://localhost:8888/ URL isn’t bad. But if you add multiple site folders and are using code that looks at root directories, like moving WordPress core into its own folder, it’s better to fool the website into thinking its main folder is the end of the line—the same way web servers deal with multiple sites on the same computer. Each one of these directories is called a virtual host, and enables a folder to connect to a domain name through an IP address and act as an independent website.
It would also just be nicer to type in rawkblog.test or rawkblog.dev instead of localhost:8888/rawkblog every time you’re loading the site, and then again every time you have to do a search-replace to change the site name when you send it up to a live website.
Since we’re using MAMP to create a local server, it’s pretty straightforward to use either Apache or Nginx—the two web server options MAMP gives us—to create a virtual host, the same way we would on a web server. I’m doing this with Apache, which is the more common WordPress option.
We’ll create the virtual host first and then use the macOS host file to give the domain name a local IP address, the local version of setting up a public domain name with Hover or Godaddy.
This is a great opportunity to safely test stuff like domain redirects, how .htaccess works, and general server configuration—if you’re interested. Dig through Digital Ocean’s tutorial library. But here’s how to get your dev site set up properly.
Find your document root in MAMP preferences. This is the directory you have your website folders. Mine is in Users/Greenwald/code/sites. (The capitalizations matter.)
While you’re in MAMP, we’re also going to set it to “listen” on the standard port, 80, so we strip the 8888 from our custom URLs. In preferences > ports, set the Apache port to 80. You can leave Nginx and MySQL the same. If you’re having issues with your sites later or want to go back to the old localhost:8888 domains, you can put this back in.
Next we need to enable virtual hosts on our local server. This is a feature of MAMP Pro, but we can do it by hand. We need to open the httpd.conf document MAMP’s Apache configuration folder. Navigate to Applications > MAMP > conf > apache > httpd.conf, or just open it in your text editor from the command line:
$ atom /Applications/MAMP/conf/apache/httpd.confThere’s a lot of information in here we don’t want to touch. Find these two lines. They’re on like 574 and 575 in my installation.
# Virtual hosts
#Include /Applications/MAMP/conf/apache/extra/httpd-vhosts.confJust as we did with ImageMagick, we’re to remove the comment to enable the file. This time, the # mark on the Include line is setting the comment. Delete it. Leave the hashtag on # Virtual hosts: that’s a comment (in this case, a section heading), not code, and it should stay that way.
In the same document, we need to make one more change.
<Directory />
Options Indexes FollowSymLinks
AllowOverride None
</Directory>We want to allow overrides, for reasons I can’t 100% explain to you. Sorry. Change “None” to “All.”
<Directory />
Options Indexes FollowSymLinks
AllowOverride All
</Directory>Save and close. Atom doesn’t have auto-save on by default and once in a while I lose code this way—make sure you actually save the file if you are using this editor.
We are now ready to use the virtual host configuration file we just enabled, httpd-vhosts.conf. Since we already have the file path, let’s open it up.
$ atom /Applications/MAMP/conf/apache/extra/httpd-vhosts.confIf you’re not a command line person (and I have only been one for, like, two months), you can also just click into your Applications folder, dig your way down to it, and edit it with TextEdit. That is also totally fine. I actually made an alias link and saved it to my shortcuts folder so I don’t have to remember the file path every time I want to add a new website.
O.K., you have the file open. There is a lot of commentary explaining virtual hosts which is pretty interesting, but let’s just make our hosts for now. You’ll also see some example virtual hosts. Here’s what that should look like:
#
# Use name-based virtual hosting.
#
NameVirtualHost *:80
#
# VirtualHost example:
# Almost any Apache directive may go into a VirtualHost container.
# The first VirtualHost section is used for all requests that do not
# match a ServerName or ServerAlias in any block.
#
<VirtualHost *:80>
ServerAdmin webmaster@dummy-host.example.com
DocumentRoot "/Applications/MAMP/Library/docs/dummy-host.example.com"
ServerName dummy-host.example.com
ServerAlias www.dummy-host.example.com
ErrorLog "logs/dummy-host.example.com-error_log"
CustomLog "logs/dummy-host.example.com-access_log" common
</VirtualHost>
<VirtualHost *:80>
ServerAdmin webmaster@dummy-host2.example.com
DocumentRoot "/Applications/MAMP/Library/docs/dummy-host2.example.com"
ServerName dummy-host2.example.com
ErrorLog "logs/dummy-host2.example.com-error_log"
CustomLog "logs/dummy-host2.example.com-access_log" common
</VirtualHost> You can delete all of this section and replace it with the code below. Anything that’s commented (with a #), you can leave as it is, but we need to add this code with no comments:
NameVirtualHost *:80
# Base configuration for sites without their own virtual host
<VirtualHost *:80>
DocumentRoot "/Users/YourUser/code/sites"
ServerName localhost
</VirtualHost>
# My first site
<VirtualHost *:80>
DocumentRoot "/Users/YourUser/code/sites/example"
ServerName example.test
</VirtualHost>We’ve set up virtual hosts at port 80, set a default virtual host location (localhost, formerly localhost:8888) for site folders that don’t have their own virtual hosts yet, and set up a new virtual host for our example site.
Change the document root here to your own MAMP document root, user, etc., and change the information under the # My first site comment to the domain name you’d like to use.
I’m using the .test domain to differentiate the local site from the .com version I’ll be using publicly. Many developers have historically used .dev for this, but it’s now owned by Google and they are forcing HTTPS use with it, which can be an issue for local sites that haven’t set this up. .test, .example, .localhost are all reserved top-level domains that cannot be used online ever, making them safe for local development. You could also use .dev.cc, which is owned by the local development company DesktopServer, who announced recently they will be keeping it safe for devs. I would just use .test and call it a day.
If you plan on using other domains or subdomains with this local site, like a www. address, you can add those with the ServerAlias directive. Add as many lines of this as you like.
# My first site
<VirtualHost *:80>
DocumentRoot "/Users/YourUser/code/sites/example"
ServerName example.test
ServerAlias www.example.test
</VirtualHost>Now we need to tell our computer to point the local server IP to this virtual host. Before we do this, we need to make sure WordPress is ready—set your local site to the new URL you’ll be using so it’s ready to make the switch.
To point the domain in the right direction, we need the /etc/hosts file. /etc is a hidden folder above your computer user, directly under the Macintosh HD directory in the Finder. It’s easiest to open this with a text editor in the Terminal instead of going hunting for it.
I’ll open it with Atom as usual.
$ atom /etc/hostsThe line 127.0.0.1 localhost tells us we are already pointing our computer’s local IP (127.0.0.1) to the domain localhost, which means our new base virtual server configuration will work. Let’s add our example site in the line below it.
127.0.0.1 example.testIf you’d like to use another domain with this site, we also need to declare it here, so you might want to use:
127.0.0.1 example.test
127.0.0.1 www.example.testSave and close. Restart MAMP if you haven’t already. You should now be able to open http://example.test in your browser and land on your local development site.
To repeat the process, add a new virtual host configuration to httpd-vhosts.conf and add a new line matching it to /etc/hosts.
There are other neat tricks you can do with the hosts file, including using it to test a domain with a real IP address. For example, you might have staging.example.com on IP address 1 and example.com on IP address 2. We want to move the example.com name to IP address 1 but want to test it first. You can use the hosts file to assign IP address 1 to example.com only on our computer, to make sure the staging.example.com site works under the new domain before making the switch. (Along with changing the site name in the database and so on.) But make sure to take this line out of your hosts file after you’ve changed the names and IPs online so there’s no confusion.
Thanks to Tania Rascia for her excellent walkthrough on virtual hosts with MAMP. Her site is a super-clear resource on a lot of dev topics.
Wrapping Up
Now your MAMP set-up has a powerful image processor, WP-CLI compatibility, and you can add as many custom domains as you want. Make some websites!