As a part of my job, I develop custom WordPress plugins and themes. The other part of my job is to develop applications using Symfony, so for me is crucial to have a development environment that supports both my activities without compromises. I’ve found my perfect balance using these tools:
I will avoid to explain what are these tools, but I have added the links to let you go directly to each website.
The easy part with Homebrew
Using Homebrew I can install pretty everything, except for the Symfony binary. If it can be useful to you, here is my Brewfile (search for “brew bundle”, it is an easy way to let Homebrew know what to install following a list into a file).
tap "exolnet/deprecated"
tap "garethlawson/php"
brew "node"
brew "composer"
brew "dnsmasq", restart_service: true
brew "git"
brew "imagemagick"
brew "mailhog", restart_service: true
brew "mysql@5.7", restart_service: true, link: true
brew "nginx", restart_service: true
brew "php", link: false
brew "php-code-sniffer"
brew "php@7.2", restart_service: true, link: true
brew "php@7.3"
brew "pkg-config"
brew "postgresql"
brew "wp-cli"
brew "exolnet/deprecated/php@7.0"
brew "exolnet/deprecated/php@7.1"
So let’s start and install PHP, Composer and Laravel Valet following the guide on the Valet website
When it’s time to install the database you can continue to follow the guide or, for example, you can install in the same manner PostgreSql.
If you know that you are going to develop on WordPress multisites, you need to add to Valet a custom driver to manage the multisite: I’m currently using this and it has never failed, just follow the one-line instruction on top for installation
Continuing with the things you can install with Homebrew, proceed installing Mailhog, PHP Code Sniffer and WP CLI.
This is also the moment when I install the Symfony binary.
You can test Valet, WP CLI and the database, but not the others. Now it’s time to finish some configurations.
Finishing the configuration of PHP Code Sniffer
PHP Code Sniffer needs to have the sniffs configured. It come with a basic set of sniffs, but you can add the WordPress ones following the documentation here (I prefer the standalone version)
Depending on your IDE setup, you would have to setup all from the command line, or you can have your IDE to manage the sniffs. In my case, with PHPStorm I need only to setup the PHP Code Sniffer path and the rules to follow at the beginning of the project.
Tweaking Valet
After 2 years I’ve collected 2 setups to apply to the servers: more timeout for MySQL and more timeout for Valet.
For MySQL, add these rows in the file /usr/local/etc/my.cnf (and tweak them to your use cases)
interactive_timeout = 1000
wait_timeout = 1000
max_allowed_packet=160M
For Valet follow this guide
Manage a lot of PHP versions
I develop on a lot of different applications, and I need all the PHP minor versions of the 7. I have found how to install them via Homebrew (look at my Brewfile), and I need that the PHP version used by the web server is the same used by the command line. To achieve that, I have my precious .zshrc file to setup the global PATH:
export VALET_PHP_70="/usr/local/Cellar/php@7.0/7.0.33/bin/"
export VALET_PHP_71="/usr/local/Cellar/php@7.1/7.1.33/bin/"
export VALET_PHP_72="/usr/local/Cellar/php@7.2/7.2.32/bin/"
export VALET_PHP_73="/usr/local/Cellar/php@7.3/7.3.23/bin/"
export VALET_PHP_74="/usr/local/Cellar/php/7.4.11/bin/"
export BREW_MYSQL="/usr/local/opt/mysql@5.7/bin"
export COMPOSER_PATH="$HOME/.composer/vendor/bin"
export SYMFONY="$HOME/.symfony/bin"
export PATH="$VALET_PHP_72:$BREW_MYSQL:$COMPOSER_PATH:$SYMFONY:$PATH"
Every time I change the version with Valet, I also link into the operating system’s path the right PHP version. As you can see, when I picked both the Brewfile and the .zshrc file I was working with PHP 7.2, and there is also the Symfony binary path.
Install XDebug
I have always looked at the installation of XDebug like a pain, but frankly with this environment it is not. Just remember that if you (like me) need more PHP versions ready to work, you will have to repeat these steps for each version you linked in the $PATH into the .zshrc
First, instal XDebug with pecl:
pecl install xdebug
Then into the folder /usr/local/etc/php/[YOUR PHP VERSION]/conf.d put a new ini file, let’s call it xdebug.ini with the configurations to run it, for example mine is:
xdebug.remote_enable=1
xdebug.remote_host=127.0.0.1
xdebug.remote_port=9000
xdebug.remote_autostart=1
# I don't use anymore this last line, but I keep it in case of need
xdebug.idekey="PHPSTORM"
…and that’s it. On PHPStorm I just check the XDebug port and hit the debug icon of the telephone.
Configure Mailhog
Knowing that you are already here (/usr/local/etc/php/[YOUR PHP VERSION]/conf.d) put another new .ini file, call it mailhog.ini and add into it this line without changing anything (except the Mailhog version if needed):
sendmail_path = /usr/local/Cellar/mailhog/1.0.0/bin/MailHog sendmail test@test
Install Image Magick
If you need it, you have already installed something with Homebrew (see the Brewfile, there is pkg-config and imagemagick). If you don’t need it you can remove them from the installation with Homebrew, but if you need it you have to continue the installation with:
pecl install imagick
As you have done for XDebug, this command needs also to be run for each PHP version you want to use.
Conclusion
If you have read this article untill here…well, thank you! Let me know: what are you using for your local development environment? And what do you think I can change to improve mine?
Top comments (5)
Go into docker world. 👍
It doesn't seem but i'm trying :D After 2 days of struggling, I decided to use docker only in the production environment of the servers that I manage, but in local I need the maximum flexibility, and with Docker I haven't had it. It would be really awesome to have all scripted with Docker, but i have the Brewfile and all the .ini files in my backups, I reset the mac every year and recreating the environment is a matter of minutes. I will surely continue to try to have a Docker env, but it's not my priority at this moment...but thanks for your comment! 💪
You reset mac every year? Hmm, interesting. Why?
I prefer a clean upgrade of the operating system. It's also a way of putting order in the lot of things that I try during the year, keeping only the ones that I use (or that I'm working on) and not reinstalling everything from a backup. I own an early 2015 MacBook Pro and with this procedure it is always smooth and fast, and, knowing that i will soon make a "great format", it forces me to keep my data always organized between a NAS and the repositories. It's like a purification ritual 😂
Ok ;) I have MBP from 2009 and 2015 and never do that ;) 👍