I recently had an issue with the Hummingbird Pro plugin, on a couple of client WordPress websites I host on Pantheon. Some plugins try to write to directories that Pantheon won’t allow for security reasons. In the case of Hummingbird, the plugin tries to write log files to the /wp-content/ directory. Pantheon will allow plugins to write only to /wp-content/uploads/ directory. Activating the plugin on the Dev or Test environments results in an error on every page. The errors on the Live environment are not displayed, so the plugin can be used there, but it means that every time I push new code from Dev to Test, and pull the database from Live, I end up with errors on Test, and of course, the client sees the error the instant the updates are pushed to Test. I can always deactivate the plugin on Test, but I’d rather not have to deal with it every time.

In my online searches, I came across a post in the WPMU DEV forums, regarding the issue, which led me to the Pantheon docs, and an article titled, Symlinks and Assumed Write Access. Basically, I needed to create a symlink pointing from the directory Hummingbird wanted write access to, to a new directory that it could actually write to. Not being super familiar with symlinks, I found the article a little lacking, and tried several times before figuring out a few things.

Hummingbird wants to write to /wp-content/wphb-logs, so I needed to create a symlink that would make it so Hummingbird would actually write to /wp-content/uploads/wphb-logs. What I was initially unsure about was the symlink syntax.

Pantheon says:

# The first path will be used as the new file destination instead of whatever path the plugin assumed write access to
ln -s ../uploads/new-directory #The last nested directory should mirror the directory name the plugin expects to write to

That wasn’t clear to me, so I searched online for info on symlinks. What I found were lots of examples like this:

ln -s <path to the file/folder to be linked> <the path of the link to be created>

Say what? I still don’t know which parameter should represent the original location (/wp-content/wphb-logs) and which should represent the new, location (/wp-content/uploads/wphb-logs). So, I tried multiple times, and wasn’t sure how successful I was. It took a few tries to get it to even commit to Git. Then, when I pushed, what I thought was correct, I got a new error.

It turns out there are a few more things to note:

1. You have to remove the old location
2. You have to use relative paths for both the old and new location
3. You have to then go create the new location

My final set of steps looked like:

1. From the root of my WordPress site:

   cd wp-content

2. Remove the existing directory:

   rm -rf wphb-logs

3. Create the symlink:

   ln -s uploads/wphb-logs wphb-logs

4. Using SSH or SFTP, create the new wphb-logs in /wpcontent/uploads