WordPress 3.2 on Pagodabox

After migrating my portfolio site to Pagodabox, I migrated my WordPress blog next. It was a tough job since I have 3 years worth of posts on it and it is a pain to migrate all those files, configurations, plugins, theme customization and uploaded files. In this post, I will just describe how to do basic WordPress migration to Pagodabox.

Tutorial from Pagodabox

Pagodabox has tutorial on how to install WordPress on their platform. Click here to visit the page. In this post, I may recap most of what is posted on Pagodabox but also insert some of my tweaks done in my setup.

Basic setup

First of all, make sure you already setup your repository but before that, we need to setup first the other necessary components. To make it simple, we will create first our common writable directory for all dynamic files such as those files that are occasionally updated by WordPress and by some plugins.

In my case, I put my writable files in:

wp-content/writable

Boxfile

Next, let’s setup our Boxfile to be used in deployment. Here is how my Boxfile looks like:

web1:
  shared_writable_dirs:
    - /wp-content/writable
    - /wp-content/uploads

As you can see, I have another directory wp-content/uploads in my Boxfile. This is because uploads is also dynamic. Since our application cannot write to our live application directories, we need to exclude them from our codes/deployment and make it a shared writable directory instead and is maintained separately.

Note: Be sure to enable shared writable directories in your application’s admin panel and specify your password for the SSH access. Save your Boxfile under your project directory and name it Boxfile.

.gitignore

So that our writable directories will not conflict with our repository, all dynamic contents must be excluded from GIT repository. All directories specified in shared writable directories must also be ignored in GIT. Here is my .gitignore file.

Thumbs.db
.svn
_svn
*.kpf
*.swp
.buildpath
.settings
*.komodoproject

/wp-content/writable
/wp-content/uploads

.htaccess

Believe it or not, the .htaccess file in WordPress gets modified by WordPress itself and with some plugins. We cannot make our whole project or document root directory as writable therefore we only need to make .htaccess writable. Guess what? The answer to this is symbolic link.

For Linux or Mac machines, it should be easy to create symlink. For Windows 7, there is also a symbolic link equivalent but I’m not sure how it works. However, for Windows, Cygwin is available if you want a Linux like environment in Windows.

What we need to do is create a symbolic link for our .htaccess file and point it to wp-content/writable/.htaccess. Clever isn’t it? Then since shared writable directories are accessible via SSH, we will use our favorite SFTP application to initially create our .htaccess file.

For now, let’s create first our symlink. For Linux and Mac:

cd /path/to/your/wordpress-app
ln -s wp-content/writable/.htaccess .htaccess

Note that wp-content/writable/.htaccess doesn’t actually exists in our current directory. We will just create once the writable directory is deployed.

wp-config.php

Just like .htaccess, the wp-config.php file is also sometimes being modified by WordPress. Aside from that, we may don’t want to commit our database credentials to the repo and let others view it. Just like what we did in .htaccess file, we will symlink it. On the WordPress app directory, do this:

ln -s wp-content/writable/wp-config.php

Database

Pagodabox has a command line client written in ruby language. If you can make it work in your machine, you better off using that method. Click here for Pagodabox command line client. In my case, it didn’t work in my Linux distribution (Slackware Linux) and I don’t know what is the root cause of it.

Anyway, as an alternative, I used phpMyAdmin, just like what I did in my Kohana application.

First, create a database in your Pagodabox apps dashboard. Once the database is created, take note of the database credentials like host, username and password. Add phpMyAdmin to your WordPress app, perhaps you put it in your document root along with wp-content and wp-admin, wp-includes, etc.

On the phpMyAdmin directory, create the config.inc.php file and indicate the database hostname given by Pagodabox. It is usually tunnel.pagodabox.com.

Initial deploy

Don’t forget to configure your SSH keys before you are able to push your code to Pagodabox. For Linux and Mac users, follow the tutorial by Pagodabox for setting up SSH keys for GIT.

We need to deploy the WordPress app this time so that the writable directories will be propagated across your app instances. The following steps will create a GIT repository, add the remote repo and deploy/push to Pagodabox.

cd /path/to/your/wordpress-app
git init
git add .
git commit -m "Initial import"
git remote add pagoda git@git.pagodabox.com:your-wordpress-app.git
git push pagoda --all

Restore your database

Visit http://your-wordpress-app.pagodabox.com/phpmyadmin and login using your Pagodabox database credentials. From there, you can restore your database by using the SQL dump from your previous host or from your local database. If the dump reach the 2MB limit, split the database dump like separating the wp_postsas a separate dump.

Configure your .htaccess and wp-config files

Because our .htaccess and wp-config.php are stored in writable directories we can modify them via SFTP. Using applications like Filezilla, browse the shared writable directories and edit the file needed to be modified. Since we have not yet configured our database, we will edit wp-config.php first.

Using applications like Filezilla, go to ~/shared/wp-content/writable and look for wp-config.php file. Fill it with config taken from the sample config and set the database credentials correctly. You may also set the authentication salt keys, you can generate auth keys from here.

Anything left to do?

If everything is ready and set up, you can now visit your WordPress app at http://your-wordoress-app.pagodabox.com/. You may also want to reconfigure your .htaccess file but you can do it automatically by visiting the WordPress admin page and configure the permalinks.

Plugins?

There may be issues that may arise for plugins like XML sitemap generator or caching plugins, but I’ll post a separate post regarding such WordPress plugins.

Good luck!

This entry was posted in Hosting, WordPress and tagged , , , , , . Bookmark the permalink.

Related Posts

6 Responses to WordPress 3.2 on Pagodabox

  1. Pingback: WordPress – WP Super Cache on Pagodabox | Lysender's Daily Log Book

  2. Hi!
    Are you running the “free” package with additional writable space?
    Is it enough power to run one instance of WordPress when it comes to RAM etc?

  3. lysender says:

    Hi Rob,

    I’m running the free-everything instance. For my type of blog, where I only got more or less 200 visitors per day, it is more than enough. I get some timeout reports sometimes but maybe it is because of so-called sleeping apps but I don’t want to add the 8 dollar/month caffeine service for my app.

    It is working fine so far.

    DB/RAM is always hot since it is too small but overall it is just fine.

    Thanks

  4. Thanks for the answer!
    Where do you store images etc?
    /Robin

  5. lysender says:

    Looks like my database has just rolled back. I use s.lysender.com, a separate app to store images and commit them all, instead of using shared directory.

  6. Al says:

    My sym links to wp-config and htaccess don’t seem to be working. I ssh’d to /home/ and added the sym link without errors and afterwards ftp’d into the directory and added the correctly completed files. But wordpress still thinks the files aren’t writeable.

    Are there any common pitfalls I may be encountering that weren’t mentioned in your post?

Leave a Reply

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