WordPress on Pow: Rack-powered WP

So, you got WordPress running on Heroku already? Congrats! But what if you are primarily a Rails developer like me, and use only Pow for local app serving needs? Have no fear, there is a way to run WordPress as a Rack app, so Pow can serve it up for you.
Having a local installation is key when running WP on Heroku because, alas, Heroku’s php doesn’t have zlib compiled. This means you need to do all plugin installations and updates from your local environment, and deploy the changes.
To make WP work with Pow, we need to set it up as a Rack app. To do this, we can leverage the handy rack-legacy gem to parse the PHP content from within the ruby/rack environment.
Here’s the steps I took to get this working.
  1. You need a rack-up file to turn WP into a Rack app.
    • I found one here, and then modified it a bit (following along with the comments on the original one).
    • Here’s my config.ru with all modifications needed for WordPres.:
  2. My OS X php didn’t want to play with Pow:
    • The PHP version shipped with OS X doesn’t have php-cgi installed, which this approach relies on
    • The app was returning blank pages or screens with no content
    • Remember to do “touch temp/restart.txt” after any/all changes to your config.ru file
    • Also remember you can check the pow logs with Mac OS X app: Console (look under ~/Library/Logs, Pow)
    • Somewhere it was suggested that you can symlink the php binary to php-cgi…That did not work for me
    • I tried using this set of steps to do another php build via homebrew:
      • It downloaded some stuff, took a long time, and hit an error:
      • “Undefined symbols for_xsltLibxmlVersion, referenced architecture x86_6″
      • Google was no help on that one. Uninstalling/reinstalling libxml2 didn’t seem to help.
      • brew install php --with-mysql --with-cgi --with-gmp
      • I don’t know what gmp is, and don’t care
      • using –with-cgi gave me the php-cgi binary
      • I added this to the bottom of my .bash_profile to ensure I hit the right binaries:
        • export PATH=`brew –prefix php`/bin:$PATH
  3. Now, at long last, after one more restart of Pow, I get… a WordPress error!
    • "Your heroku DATABASE_URL does not appear to be correctly specified."
    • Right, this is the error we put in above, and we are getting it because we aren’t on heroku now
  4. We need to set up a development environment:
    1. Create your local db:
      • mysql -u root -p -e "CREATE DATABASE ;;"
    2. In the spirit of a properly factored app, let’s store local creds in an environment variable
    3. All we need to do is save our local values in a local DATABASE_URL env var
    4. This could be done in a number of places… php.ini, .bash_profile, a .gitignore’d project file, etc
    5. I want it to not conflict with other local WP installs, so…
    6. We can use .powenv to pass project-specific env settings to the rack app:
      • echo 'export DATABASE_URL="mysql://root@localhost/repo-name"'
      • Or, slightly easier, if you have my fork of powder installed:
      • powder env DATABASE_URL mysql://root@localhost/repo-name
    7. Open the local site. If the env var is read correctly, you should see the site setup screen.
    8. Rather than re-entering what you put on the heroku server, just suck it down, using the server and credential info form heroku config command, or from the ClearDB info linked from heroku.com. Something like:
      • mysqldump --host us-mm-auto-dca-01.cleardb.com --user 4ecf8dbd0f00b7 --password=3b2e4402 heroku_fd542dc123475e0 | mysql -u root -p ;
      • Before running this, put the app in maintenance mode so the db won’t change:
      • heroku maintenance:on
  5. Go hit your root URL again, and you should see your site, as you had configured it on the server.
    1. Sign in at http://local-app-name.dev/wp-login.php with the same user you set up on production.
    2. Now you can install and update plugins, add themes, etc.
    3. When you are done: commit, deploy, push the db back up with by reversing the dump command, and switch the app back on…
      1. git commit -am "Updated this AND that\!"
      2. git push production master
      3. mysqldump -u root LOCAL_DB_NAME | mysql --host us-mm-auto-dca-01.cleardb.com --user 4ecf8dbd0f00b7 --password=3b2e4402 heroku_fd542dc123475e0
      4. heroku maintenance:off
  6. You are up and running, Champ! With a modern workflow even!

Other issues you might run in to:

  • Heroku reports “No such file or directory – php-cgi”: I hit this when I included a Gemfile that contained rack-legacy. Restricting it to the :development group enabled me to get to the next error…
  • App dies, and Heroku logs say “can’t find executable rackup”: Looks like WP on Heroku just doesn’t want to work with anything in the gemfile. Deleting Gemfile and Gemfile.lock from the repo, and adding both to .gitignore got the app going again on Heroku. Any ideas why this is happening? I’d love to hear a better work-around.
  • Pow reports: “LoadError: cannot load such file — rack-legacy” (or just rack). It seems to me a newer version of RVM caused Pow to not get the right gemset. There are lots of suggested fixes, but this one is what worked for me (followed by .gitignore’ing my .powenv file, which is the right behavior anyway).


10 Responses to “WordPress on Pow: Rack-powered WP”

  1. Austin Ginder April 17, 2012 at 5:16 pm #

    Thanks for the post. Really like the idea of using pow to host WordPress locally for development. I have it mostly working however half of my .js files in return a 500 Internal Server Error. Kinda strange considering they should be passed straight through as content files. Curious if you ran into anything like this. Screenshot: http://cl.ly/3q0j3c09220u0M290o2n

    • brookr April 19, 2012 at 3:26 pm #

      Odd! I haven’t seen anything like that. But it does seem that it is a bash error message, eh? rack-legacy may be using bash to process the php, and your js file might be caught in the middle. Any consistent patterns around which js files are giving that kind of error?

      • Austin Ginder April 19, 2012 at 4:59 pm #

        Okay this one had me stumped but I finally figured out what’s going on. I discovered files other then .js files seem to be affected by the same glitch, for example font face kits and so forth. The only thing is common was the files were copied not written from scratch. That lead me to take a closer look at the file permissions. I figured out the file permissions were set to execute. I was able to resolve the issue by running chmod 644 on those files (Only owner can write, others can read).

        • brookr April 19, 2012 at 5:04 pm #

          Wow, great detective work. I’ll definitely keep that in mind.

          Thanks a ton for sharing your fix with us here!

  2. tombh June 2, 2012 at 7:00 pm #

    Great work. I needed to make a few tweaks to get it working in my Linux environment https://gist.github.com/2860953

    • brookr June 4, 2012 at 11:21 pm #

      That’s great, thanks for sharing it here!

  3. Austin Ginder June 5, 2012 at 3:02 pm #

    Discovered another quark. The max upload seemed to be stuck at 2MB no matter how much tinkering I did with WordPress Multisite. The solution was to make a php.ini like so: https://gist.github.com/2878345.

  4. Ren July 10, 2012 at 9:58 pm #

    Thanks for the great write-up! It was super helpful.

    I was finally able to get my local environment up and running after running into a couple of issues. I went with MAMP instead of POW as I’m a little more familiar with WAMP and figured MAMP would be easier to get going.

    I obviously skipped over much of the first part of your instructions but got bogged down with the “Your heroku DATABASE_URL does not appear to be correctly specified.” issue. For whatever reason wordpress would not read the DATABASE_URL environment variable when I set it in php.ini or .bash_profile. I did all the expected restarts etc. but could not get it to work. I eventually shoved it into httpd.conf which finally solved the issue.

    Also, your following example left me a bit confused because it doesn’t include the password:

    echo ‘export DATABASE_URL=”mysql://root@localhost/repo-name”‘

    I didn’t notice that it was excluded at first but after a quick change things started working just fine. This is what my httpd.conf entry looks like:

    # Set wordpress database_url environment variable
    SetEnv DATABASE_URL mysql://root:root@localhost/database-name

    - Ren

    Quick side note: I couldn’t get wordpress to work on port 8888 (which is what MAMP defaults to). It was doing some weird redirect to port 80. My psuedo solution was to go ahead and change the MAMP apache port to 80 which fixed the issue but left me having to stop the MAMP server whenever I want to fire up JBoss or anything else running on port 80 – which kinda sucks…

    • brookr August 31, 2012 at 1:53 pm #

      Wow, good work with those workaround! Yeah, the port 80 issue is one of the reasons I wanted to stick with Pow. I use that for all my Rails development, and turning things on/off all the time would be annoying.

      You are right about me not including a password for my local db. I really should do something about that…

      Thanks a bunch for sharing your process! I’m sure you are not the only one who is interested in making this work with Apache.


  1. WordPress on Heroku: Up and Running! | Wisps & Snippets - March 16, 2012

    [...] inconvenient, but I’m working on some tools to make it smoother. Once you are up and running, see the followup post for details about what’s [...]

Leave a Reply