As a WordPress developer I run a webserver on my main development system (a MacBook) so that I can develop and test in a private environment before deploying sites to live domains.
I’ve always used XAMPP for this purpose – I’ve found using a pre-packaged environment like this gives me more flexibility to change component versions and configurations without risking messing up my Mac. There are other options of course (MAMP, DesktopServer, etc) but XAMPP works for me. I keep things simple by using a subfolder of localhost for each site and it all works fine.
Or rather, it did until I had to buy a new MacBook and reinstall all my apps and data…
One important aspect of working with WordPress sites is that each site needs to be able to write to its own folder structure, to install and update plugins.
With XAMPP out of the box, it seems this is no longer possible, and some configuration is needed.
Following a lot of googling and experimentation, I’m happy to explain how I resolved this problem (and some other related issues) and made my MacOS XAMPP installation WordPress-ready.
The solution is a combination of folder ownership and folder permissions.
First, you need to make the Apache webserver in XAMPP run using your own user account. This gives it access rights to everything you yourself can access, and is needed because WordPress (rather unnecessarily and annoyingly) does a file owner check as well as a permissions check when deciding if it can write files to a folder.
Open XAMPP’s Application Manager window, select Apache Web Server, and click the Configure button. When the dialogue opens, select the Open Conf File button. This will open the Apache httpd.conf file in TextEdit or whatever your default editor is. You’ll have to accept a warning that XAMPP shows before the file will open.
In the editor, look for this block of code:
<IfModule unixd_module> # # If you wish httpd to run as a different user or group, you must run # httpd as root initially and it will switch. # # User/Group: The name (or #number) of the user/group to run httpd as. # It is usually good practice to create a dedicated user and group for # running httpd, as with most system services. # User daemon Group daemon </IfModule>
Where it says User daemon, change daemon to your own username (e.g. john).
Where it says Group daemon, change daemon to staff.
Save and close the editor, then click OK in the XAMPP dialog box that opened, then restart Apache.
The above tweak may solve the problem, but not always. It’s best to adopt a “belt and braces” approach and change the permissions of your htdocs folder as well.
Open a terminal window and enter the following, to ensure that your htdocs folder is owned by your user account (change john to whatever your username is!). You’ll need to enter your password when prompted.
sudo chown -R john:staff /Applications/XAMPP/htdocs/
Now enter the following, to ensure your htdocs folder can be written to by any account:
sudo chmod -R 777 /Applications/XAMPP/htdocs/
Each of these commands may take a few seconds to run depending on how many folders and files there are in your htdocs folder.
NOTE: If you have moved your htdocs folder (easy to do by editing httpd.conf), replace the standard path with your path in the above commands. For example, my own htdocs folder is actually /Users/andy/Sites/ because that’s where I like it.
Now go back to XAMPP’s Application Manager and restart Apache again.
By now you should be good to go, but there are a couple of PHP settings that will help your local WordPress sites perform better, so let’s sort them out now.
XAMPP’s php.ini file is located at /Applications/XAMPP/xamppfiles/etc/php.ini – so open this with your favourite code editor (I used BBEdit on this occasion).
Find the line that looks like this:
and change the 30 to 60.
Now find the line that looks like this:
and change the 128M to 256M. Don’t forget the M.
Now save and close the file, go back to XAMPP’s Application Manager, and restart Apache.
That’s it – your XAMPP installation should now play happily with WordPress.
Needless to say, don’t follow any of these tips on a web server that is serving to the public. These tips are intended only for private localhost development work behind a firewall and would leave a live server wide open to attack.