How I manage the WordPress theme with Git

Posted on   September 30th, 2010

I thought it might help somebody the way I’m currently managing my WordPress theme. First of all, I have to say it would be better to have an actual WordPress installation in my localhost, so it would be easier trying out changes (on themes and plugins) before committing them. I’m just too lazy for that, so I’d rather have only one running installation of WordPress on my server and a moving git repository for the theme alone. So this is how I do:

1. I have a Github public repository to share my theme (not like anyone is interested anyway)
2. I have another private repository in my server to store all the changes of the theme and actually update it.
3. I have a local repository in my computer for the theme.
4. The theme is actually stored at my_server_root/my_wordpress_path/wp-content/themes/bernatfarrero/

Let’s start out creating the local repository in your local computer:


mkdir bftheme && cd bftheme
scp -r my_server_root/my_wordpress_path/wp-content/themes/bftheme .
git init #We initialize the local repository
git commit -a -m "Initial commit" # And we make the first commit

We’ve just made a local copy of our theme and we’ve set up a local Git repository. Now let’s synchronize it with our server’s repository. In my server I have a special directory for all my repositories called repo. So, now I have to login via ssh to my server and do the following:


cd my_server_root/repo #this is were I store my repositories
mkdir bftheme.git && cd bftheme.git
git init --bare
git config core.worktree my_server_root/my_wordpress_path/wp-content/themes/bftheme
git config core.bare false
git config receive.denycurrentbranch ignore
vim hooks/post-receive #Open this file with your favorite editor and write inside it:

#!/bin/sh
git checkout -f

#Save it and close it
chmod +x hooks/post-receive #Give it running permissions

The denycurrentbranch set to ignore (or warn) basically makes the server not complain for having uncommitted changes on the remote repository. Even so, as we only want it to mirror our local changes, we don’t care. We’ve set the post-receive hook so it resets our repository to the latest changes received by our last push. Now in our local computer, we have to tell our repository who will be the remote:


git remote add origin username@host.com:repo/bftheme.git
git push origin master

And that’s it. We’ve established the connection between our local repository and the actual changes made public in our blog. In order to deploy your changes just do:


git push

And you should see them right away. If you do not, there will be some problem with the paths, or make sure you don’t have any caching plugin (like Super Cache) activated at the moment. If you are like me and want to push every now and then the changes to Github, you can do (in your local computer):


git remote add public git@github.com:bernat/blog.bernatfarrero.git #In my case
git push public master

You can do that every once in a while. In case you don’t want to push all commits to Github because you are shy to show a zillion of irrellevant changes, what you can do is set the Github repository as origin and the other as, say, deploy. Every 10 commits or so, you can do (in your local computer):


git rebase -i master~10

pick A
pick B
pick C
pick D

replace all the pick by squash (except for the first one) and then give it a nice message name. This way you assemble one big commit with the changes of your last ten commits. Then, to push it to Github, you can do:

git push origin master #In case you set Github remote as origin

This way you will push a bigger and more controlled set of changes to Github and only after a while. In the meantime, to see your changes in your actual blog you would just go

git push deploy master

Tags:

4 Comments »

Reading WordPress from Rails

Posted on   February 8th, 2010

I found odd how few places were talking about reading a WordPress database from a Rails app.
If you want to flash your blog updates somewhere in your Rails app it comes handy to have your WP posts mapped as if they were any other Rails model. How to do so is not complicated so long as you consider a few details.
First off, add a new database in your config/database.yml.

blog:
  adapter: mysql
  encoding: utf8
  host: YOUR HOST
  database: DATABASE OF YOUR WP
  username: USERNAME
  password: PASS

Add your WP model: /app/models/wp_post.rb:

class WpBlogPost < ActiveRecord::Base
  establish_connection :blog
  set_primary_key 'ID'
  set_table_name "wp_XXXXX_posts"
  #Only in case you want to add comments as well:
  has_many :comments, :class_name => "WpComment", :foreign_key => "comment_post_ID"
end

In case you want to add comments as well, /app/models/wp_comment.rb:

class WpBlogComment < ActiveRecord::Base
  establish_connection :blog
  set_table_name "wp_XXXXX_comments"
  set_primary_key "comment_ID"
  belongs_to :post , :class_name => "WpPost", :foreign_key => "comment_post_ID"
end

Attention! You need to tell Rails what field is the primary key since these tables do not follow the Rails convention, and also you need to specify the name of the table within the WP database, something like wp_234f8_posts, or wp_234f8_comments.

When that’s done, you can start using it from your controllers and views. Remember to get all posts marked as “publish”, as WP registers a lot of redundant data in the DB as well. Something like this would work:

@posts = WpBlogPost.find(:all, :conditions => ['post_status = "publish"'], :limit => 10)

One other important thing should be considered. Be sure you configured your host db server to accept access from the outside if you want to try your controllers from your local development server. Also, you need the last MySQL installed as a gem (sudo gem install mysql).

Tags:

6 Comments »