OS X Yosemite brings newer bundled runtimes, and older development tools often assume the previous versions. After the upgrade, several parts of a local stack stopped working at once: PhpStorm, Homebrew, Node.js, Apache, and MySQL. Most of the repair work came down to finding hard-coded paths and outdated runtime expectations.

PhpStorm

PhpStorm refused to start and asked for jre6. The issue is Java versioning. JetBrains has explained why it cannot simply move to newer JDKs:

Current JDK 1.7 and 1.8 versions have several critical issues. We can’t default to the new JDK version until these issues are resolved.

Oracle’s OS X downloads only offered JRE 7 and 8, not 6. The JRE 6 package is available from Apple: https://support.apple.com/kb/DL1572

Homebrew

Homebrew depends on Ruby. Yosemite replaced the bundled Ruby 1.8 with 2.0, so brew failed with:

/usr/local/Library/brew.rb: /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/bin/ruby: bad interpreter: No such file or directory

One workaround is to edit /usr/local/bin/brew and comment out the system detection so it runs brew.rb with Ruby directly:

#BREW_SYSTEM=$(uname -s | tr "[:upper:]" "[:lower:]")
#if [ "$BREW_SYSTEM" = "darwin" ]
#then
#    exec "$BREW_LIBRARY_DIRECTORY/brew.rb" "$@"
#else
    exec ruby -W0 "$BREW_LIBRARY_DIRECTORY/brew.rb" "$@"
#fi

Another option is to create the missing Ruby 1.8 path as a symlink to the system Ruby 2.0:

sudo mkdir -p /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/bin
sudo ln -s /usr/bin/ruby /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/bin/ruby

This tricks Homebrew into using the newer Ruby until it handles the change natively.

Node.js

Node.js surfaced later, when grunt tried to generate a site and returned env: node: No such file or directory. Both node and npm were present under /usr/local/bin, but they could not be opened and produced the same error. The cause was not pinned down; reinstalling the latest Node package from the Node.js website solved it.

Apache

apachectl -v showed Apache at 2.4.9. The main httpd.conf appeared to have been reset, so two lines needed to be uncommented again:

Include /private/etc/apache2/extra/httpd-vhosts.conf
...
LoadModule php5_module libexec/apache2/libphp5.so

The virtual host definitions in httpd-vhosts.conf were still there, but Apache 2.4 requires updated access control. Without that change, requests return 403 Forbidden You don't have permission to access / on this server. In the <Directory /> block, this:

<Directory />
    Options Indexes FollowSymLinks Includes ExecCGI
    AllowOverride None
    Order deny,allow
    Allow from all
</Directory>

needs to become:

<Directory />
    Options Indexes FollowSymLinks Includes ExecCGI
    AllowOverride None
    Require all granted
</Directory>

MySQL

MySQL did not officially support Yosemite yet, and its service did not start in the background after the upgrade. It had to be started manually. Adding these lines to ~/.bash_profile makes that easier:

export MYSQL_HOME=/usr/local/mysql/bin
alias start_mysql='sudo $MYSQL_HOME/mysqld_safe &'
alias stop_mysql='sudo $MYSQL_HOME/mysqladmin shutdown'

After running source ~/.bash_profile, start_mysql and stop_mysql control the service.

One more failure looked like Git: a push to GitHub failed, while pushing to GitCafe succeeded. That pointed to GitHub rather than local Git, and the push went through the next day.

The overall pattern is consistent: Yosemite updated system components, and tools that hard-coded old paths or expected older runtimes needed either a compatibility shim or a reinstall.