HTML5 Zone is brought to you in partnership with:

David is a systems architect who has been developing software professionally since 1991. He started programming in Java way back with Java 1.0 developing desktop applications and applets. Since 2001 he has been developing enterprise applications using both Java standards and open source solutions. David is the author of "Building SOA-Based Composite Applications using NetBeans 6" and "Seam 2.x Web Development". David is a DZone MVB and is not an employee of DZone and has posted 22 posts at DZone. You can read more from them at their website. View Full User Profile

Hosting WordPress On OpenShift

04.05.2013
| 4364 views |
  • submit to reddit

OpenShift If you’ve not heard of OpenShift, it’s:

“a free, cloud-based application platform for Java, Perl, PHP, Python, and Ruby applications.”

OpenShift uses git to publish files to your site, so the general approach is to make your application locally, commit files to git and then push them to OpenShift. In practice this works very well, but there are a couple of gotcha’s that I encountered – I’ll explain those later.

OpenShift express supports Java (with full AS7 support), Ruby, PHP, Perl and Python apps.

In this post, I’m going to show the steps needed to host WordPress at OpenShift Express.

Installing the client tools
So, the first stage in setting up on OpenShift is to install the OpenShift client tools. On Ubuntu, this is achieved with apt-get

$ sudo apt-get install ruby
$ sudo apt-get install rubygems
$ sudo apt-get install rhc

Creating a domain and an application
After installing the OpenShift tools, the next stage is to create a domain name to host the application in and the application itself.

Creating a domain is achieved with the rhc domain create command.

$ rhc domain create -n <domain> -l <emailaddress>

Where domain is the OpenShift unique domain name for your application and emailaddress is your login email address for OpenShift.

Next, you need to create an application. This is essentially a remote git repository which is cloned onto your local filesystem. When creating an application, you need to specify which “cartridges” you want to use. For WordPress, you will need to use the php-5.3 cartridge.

$ rhc app create -a <appname> -t php-5.3

Where appname is your application name.

If all goes well, your application will now be created and available on the internet at:

http://<appname>-<domain>.rhcloud.com

MySQL Support
The next stage of hosting WordPress on OpenShift is to create a MySQL database. This is again achieved using the OpenShift command tools:

$ rhc-ctl-app -a  "appname" -e add-mysql-5.1

This will give you MySQL support for your application. After running this command, you’ll be supplied details to your MySQL database. To help manage the database, the easiest way I found was to add PHPMyAdmin

$ rhc-ctl-app -e add-phpmyadmin-3.4 -a "appname"

Now that you’ve got PHPMyAdmin installed, a good security practice is to create a MySQL user with the appropriate access rights for accessing WordPress. We don’t really want WordPress running against the admin MySQL account.

Install WordPress
At this point, you’ve created a basic OpenShift PHP application with MySQL support. The next stage is to install WordPress. To install, simply download the latest archive of WordPress and unzip it into the php folder that has been created underneath your appname folder.

After unziping, its tempting to just access the OpenShift application and run the WordPress wizard to create the standard wp-config.php file. Unfortunately if you do this, when you next push your local code to OpenShift, any modifications made on the server will be lost. So, the general procedure is to always make changes locally and then push them to the server. This also applies for installing plugins to WordPress – always install them locally, commit them to git and then push them to OpenShift.

So, to get WordPress up and running, create a wp-config.php file locally within the WordPress installation folder. Its a very straightforward file to create, but check out the WordPress docs for more info.

Pushing to OpenShift
Having created the database configuration file, you can now commit everything to git and push it to OpenShift.

$ git commit -a -m "Initial installation of WordPress"
$ git push

Again, assuming everything has gone OK with no errors, you should be able to access your WordPress site at:

http://<appname>-<domain>.rhcloud.com

Publishing to a custom domain
OpenShift has recently added support to allow applications to be hosted at their own domain names rather than as a subdomain of rhcloud.com

To publish to a custom domain, you need to add an alias in OpenShift for your application to the domain name you want it hosted at.

$ rhc-ctl-app -c add-alias --alias www.somedomain.com -a <appname>

To complete the process, you need to edit your DNS records and add a cname pointing your domain (e.g. www.somedomain.com) to -.rhcloud.com

You should now have a working WordPress installation running on OpenShift

Uploading media to WordPress
One of the side effects of pushing local content to a git repository is that any changes made to the web site are lost when new code is pushed to it. For example plugins installed via the WordPress user interface are lost when you push new code to OpenShift. Also, any images uploaded to WordPress (by default stored in wp-content/uploads) are also lost when you push new code. To overcome this, edit the /.openshift/action_hooks/build file and add the following contents:

if [ ! -d $OPENSHIFT_DATA_DIR/uploads ]; then
    mkdir $OPENSHIFT_DATA_DIR/uploads
fi
    
ln -sf $OPENSHIFT_DATA_DIR/uploads $OPENSHIFT_REPO_DIR/php/wp-content/

Any uploaded data will now be stored outside of the OpenShift git repository and therefore won’t be overwritten each time you push to OpenShift.

Hopefully I’ve shown how straightforward is is to host applications on OpenShift Express. If you’ve got any questions, leave them as comments to the post.



Published at DZone with permission of David Salter, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)