macOS High Sierra, the magnificent update that killed the development environment.

[UPDATED sep 26]
[UPDATED again on oct 27th, see tags UPDATE2]

macOS High Sierra is awesome, but unfortunately, it killed my “old style” development environment. It was not just High Sierra; brew upgrade also had a big part in the failing of the development setup, if not ALL of it. I brew upgraded my set-up on Sierra (not High yet) and it got F’ed up as well. My guess; 95% Brew’s fault, 5% High Sierra (and only because High Sierra sort of forced me to brew upgrade)

If you are still using the “old” way for development websites (a.k.a., using macOSs own apache2 and brew php), you might want to wait with upgrading to High Sierra; I don’t have a working solution yet.

[UPDATE2] I think I might have a solution :)

PHP does not want to get installed properly brew install homebrew/php/php71 homebrew/php/php71-xdebug --with-httpd should install PHP71 as module, but the apache tap has a fault and won’t install. The default PHP is FPM (which is preferable) installs fine but doesn’t run properly.

[UPDATE2] I did a brew install homebrew/php/php71 --with-httpd followed by brew services stop httpd ; brew unlink httpd and it installed good, but still no mod_php :( I caved and switched to php_fpm, which requires a few changes to the config files, see the addendum at the bottom of the post.

When I get this fixed (and I need it fixed before I can update my work computer) I will let you know :)

If you’re smart, and you’re using Local (by Flywheel), then you just fire that puppy up, you’ll get a “thank you for using Local, would you like to update” message, just click ‘Update’ and you’re done.

to be continued …


many many tests later, still no go :( So I decided to undo a few things and uninstalled all homebrew managed PHP versions. I continued to fix paths in the Apache config files and behold! IT WORKS! macOS comes with PHP 7, so for now all seems ok, but I’m not happy. It should not be hard to use a Brew version for PHP, so why doesn’t it work?

So if you already upgraded to High Sierra and need to get Apache up and running, try for i in $(brew list | grep php); do brew uninstall $i; done which will uninstall ANY AND ALL packages you have installed with ‘php’ in the name. If you uninstalled one too many, just re-install it :) also, if applicable, brew uninstall httpd24.

Currently, I have Apache 2.4 with PHP 7.1.7 running (Apple provided), with these apache modules enabled in addition to the default;

LoadModule php7_module libexec/apache2/
LoadModule rewrite_module libexec/apache2/
LoadModule socache_shmcb_module libexec/apache2/
LoadModule access_compat_module libexec/apache2/
LoadModule ssl_module libexec/apache2/

Hope this gets you going, maybe try an alternate method to downgrade PHP (it should still work), or be smart and start using Local (by Flywheel) ;).

Also, A former coworker suggested Laravel Valet as an alternative. It might help you, it didn’t help me. Valet uses homebrew and therefore I kept having the same issues, but, it might work for you, let me know.

again … to be continued …

[UPDATE2] Addendum: config file changes for FPM to function.

  1. Make sure php 7.1 is installed and running as service
    brew reinstall php71 --with-httpd ; brew services stop httpd ; brew unlink httpd
    brew link php71 ; brew services start php71 ; brew services list
    You should now see something like
    Shell outputphp71 started username /Users/username/Library/LaunchAgents/homebrew.mxcl.php71.plist
  2. Check existence of a config file for FPM and the proxy address listed therein;
    CLI ini should be located here:
    Shell output/usr/local/etc/php/7.1/php.ini
    , check this with php --info | grep 'Loaded Configuration'
    Your FPM config should therefore be located here: /usr/local/etc/php/7.1/php-fpm.conf which at the bottom points to /usr/local/etc/php/7.1/php-fpm.d/*.conf and there is only one file (for me); /usr/local/etc/php/7.1/php-fpm.d/www.conf
    In this file you can see on what port the FastCGI Proxy will listen;
    Shell outputlisten =
  3. Apache needed these modules enabled:
    LoadModule proxy_module libexec/apache2/
    LoadModule proxy_fcgi_module libexec/apache2/
  4. Each virtual host might have lines like
    php_value error_reporting 22517
    These are for mod_php, so they will generate a fatal error.
    A hint on the web led me to believe this might work:
    SetEnv PHP_VALUE "error_reporting = 22517" but I have yet to determine it this works or not.
  5. For PHP to be parsed correctly, add this to each virtual host config section:
    ProxyPassMatch ^/(.*\.php(/.*)?)$ fcgi://$1


  1. check if the proxy-line can be generalised, by using %{DOCUMENT_ROOT} or something
  2. check the SetEnv PHP_VALUE values to see it they all function, if at all

As a final not, I would urge you to start using Local by Flywheel. It’s free and you will no longer have to maintain this Dev-Server-Setup-Hell :)

No, I am not affiliated with Flywheel, nor am I involved in the development of Local (previously PressMatic), and yes, Local has its shortcomings, but weighing the pros and cons; The benefits of Local over a self-maintained webserver set-up vastly outweigh the bad stuff.

Author: Remon Pel

WebDeveloper though not WebDesigner

3 thoughts on “macOS High Sierra, the magnificent update that killed the development environment.”

    1. If that works for you, go for it :) I tried all kinds of variations, the –with-http24 was an actual hint provided by a failed installation attempt.

      I’ll try it :)

    2. At the time of writing, –with-http24 was the only functioning flag. After a few updates, –with-http24 was replaced with –with-httpd. –with-http24 was used to install Apache 2.4, instead of 2.2 which would be installed with –with-apache.

Leave a Reply

Your email address will not be published. Required fields are marked *