Cache Bust WordPress Assets Based On Git Revision

Cache busting is to rewrite a URL for an asset (JS, CSS, images, etc) so that is unique. This way, you can cache them for as long as you want. If the URL changes, it will use the new file.

I am using deployments tool to checkout the latest version of a given branch, therefore I know that there will be a .git folder on my production server.

The idea is to use the current Git commit as a version number using git head reference.

function project_get_current_git_commit( $branch = 'master', $length = false ) {
  if ( ! defined( 'PROJECT_CURRENT_GIT_COMMIT' ) ) {
    $hash = file_get_contents( sprintf( '%srefs/heads/%s', dirname(__FILE__), $branch ) );

    define( 'PROJECT_CURRENT_GIT_COMMIT', ( $hash ? $hash : false ) );

  return ( $length ? substr( PROJECT_CURRENT_GIT_COMMIT, 0, $length ) : PROJECT_CURRENT_GIT_COMMIT );

// Enqueue WordPress asset
wp_enqueue_script('application','/assets/javascripts/application.min.js', array('), project_get_current_git_commit( 'master', 8 ), true);

Voilá, now you can cache bust everything based upon your latest Git revision.

Of course, there are other ways to do this as well. Another solution is to store environment variables that contains the latest revision and then read it from PHP, that would save some I/O from the physical file.

Installing WordPress core via Composer and finding the proper rewrites for Nginx or Apache

The idea is to separate the WordPress site’s components into their own directories right at the root. This creates a simple modular structure, where parts of a WordPress site are totally on their own. This makes things less complex and less prone to errors.

We will not be touching the WordPress subdirectory, we will only update it when a new version is released. Therefore, we will have to put our configuration and custom development (themes & plugins) outside the WordPress folder.

I’m going to use Composer package manager for PHP to install these packages and this is the directory structure that I want to create.

Directory structure

    wp/ - Will contain the WordPress package
    wp-content/ - Will contain all my themes and plugins

Composer file

The Composer can be used for both the core and plugins, for plugins we will use wpackagist. After you’ve installed composer, create a composer.json in your root folder that looks something like this:

  "name": "parse/demo",
  "description": "Parse: Demo",
  "license": "proprietary",

  "repositories": [
    { "type":"composer", "url":"" },

    { "type": "package",
      "package" : {
        "name": "wordpress",
        "type": "webroot",
        "version": "3.7.1",
        "dist": {
          "type": "zip",
          "url": ""
        "require" : {
          "fancyguy/webroot-installer": "1.1.0"

  "require": {
    "composer/installers": "1.0.x-dev",
    "wordpress": "3.7.1",
    "wpackagist/mp6": "~2.1"

  "require-dev": {
    "wpackagist/debug-bar": "~0.8",
    "wpackagist/debug-bar-console": "~0.3"

  "minimum-stability": "dev",

  "extra": {
    "wp-content": "www/wp-content",
    "webroot-dir": "www/wp",
    "webroot-package": "wordpress",
    "installer-paths": {
      "www/wp-content/plugins/{$name}/": ["type:wordpress-plugin"]

This file defines that we want to install WordPress core in a folder www/wp/ and its plugins in www/wp-content/plugins/


By moving the WordPress core, the index.php that is in www/ will now have to be changed to:

// WordPress view bootstrapper
define( 'WP_USE_THEMES', true );
require( './wp/wp-blog-header.php' );


And since we will not use the wp-content/ folder in www/wp/wp-content/, we need to redefine that in wp-config.php:

define('WP_CONTENT_DIR', dirname(__FILE__) . '/wp-content');
define('WP_CONTENT_URL', 'http://' . $_SERVER['HTTP_HOST'] . '/wp-content');

Now, we have set up the files, your vhost need to be configured to the www/ folder.


After struggling a bit with PHP’s PATH_INFO variable and found a solution, this is the important part:

if (!-e $request_filename) {
  rewrite /wp-admin$ $scheme://$host$uri/ permanent;
  rewrite ^(/[^/]+)?(/wp-.*) /wp$2 last;
  rewrite ^(/[^/]+)?(/.*\.php)$ /wp$2 last;

location / {
  root   /home/username/apps/appname/current/www/;
  try_files $uri $uri/ /index.php?$args;
  index index.php;

location ~ \.php$ {
  fastcgi_index index.php;
  fastcgi_split_path_info ^(.+\.php)(/.+)$;
  fastcgi_param SCRIPT_FILENAME /home/username/apps/appname/current/www$fastcgi_script_name;
  fastcgi_param ENVIRONMENT production;
  fastcgi_param PATH_INFO $fastcgi_script_name;
  include /etc/nginx/fastcgi_params;


    DocumentRoot "/home/username/apps/appname/current/www/"
    <Directory "/home/username/apps/appname/current/www/">
        Options Indexes Includes FollowSymLinks  
        AllowOverride All
        Order allow,deny
        Allow from all

The .htaccess in this case will look something like this:

Options -Indexes

RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]

# add a trailing slash to /wp-admin
RewriteRule ^([_0-9a-zA-Z-]+/)?wp-admin$ $1wp-admin/ [R=301,L]

RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^ - [L]
RewriteRule ^([_0-9a-zA-Z-]+/)?(wp-(content|admin|includes).*) wp/$2 [L]
RewriteRule ^([_0-9a-zA-Z-]+/)?(.*\.php)$ wp/$2 [L]
RewriteRule . index.php [L]

To upgrade plugins or core, you simply need to update your composer.json. We still need to add custom plugins into our repository, but you could create your own repositories for them as well.

Running PHP applications on Heroku

These last weeks I’ve been working on trying to organize my domain names and web hosting accounts. I’m running this blog and several other websites on a VPS as a WordPress multisite. The other applications that I am running are small PHP applications. I’ve been looking into running the other applications on Heroku. By moving these away from my current web hosting account I can cancel that account and use it for domain names and their DNS control panel.

If you would like to try running PHP applications on Heroku I suggest you create an account and create a new app at the Cedar stack (for PHP support). Then sign up for an account at Amazon S3. I use Amazon S3 for their cloud storage and keep my transfers and data (less than 5 GB) beneath their free tier to keep my costs minimal. To stay at Herokus free tier you can’t store more than 5 MB for the MySQL database and not more than 10 000 rows on the Postgres database. The PHP applications I’m running at Heroku is using MySQL as a database backend and databases at Heroku can get costly fast, especially when using several dynos.

If you’re not running your PHP application in the webroot, take a look at for instructions on how to change the webroot at Heroku.


  • Easy to deploy, my old hosting service didn’t support SSH access or any other way to do a proper deployment.
  • Cheap (maybe even free…?) for small applications.
  • Minimal maintenance since I don’t have to administer a VPS.


  • If you start adding dynos, it gets really expensive.
  • Your Ruby on Rails applications on the free account winds down after idling for a while and has a startup time that feels like forever. That doesn’t happen for the paid accounts. This doesn’t apply on PHP applications though.

After doing this test run, I will definitely look into running this WordPress Multisite at Heroku instead of having my own VPS.

WP Multi-Site: Aktivering av tillägg


Stötte för någon vecka på ett nytt problem för min del. Det handlade om att jag skulle skapa ett plugin som används i multi-site. Jag har jobbat relativt lite med Multi-Sites och problemet var att tabellerna inte skapades för alla “siterna” som fanns i nätverket.


register_activation_hook(__FILE__, 'hass_vote_activate');

function hass_vote_activate() {
	global $wpdb;
	if (function_exists('is_multisite') && is_multisite()) {
		if (isset($_GET['networkwide']) && ($_GET['networkwide'] == 1)) {
			$old_blog = $wpdb->blogid;
			$blogids = $wpdb->get_col($wpdb->prepare("SELECT blog_id FROM $wpdb->blogs"));
			foreach ($blogids as $blog_id) {
function _hass_vote_activate() {
	global $wpdb;

	$table_name = $wpdb->prefix . 'yourtable';

	if ($wpdb->get_var("SHOW TABLES LIKE '$table_name'") != $table_name) {
		$sql = "CREATE TABLE " . $table_name . " (
			id mediumint(9) NOT NULL AUTO_INCREMENT,
     			dateadded bigint(11) DEFAULT '0' NOT NULL,
     			subject VARCHAR(255) NOT NULL,
	  		UNIQUE KEY id (id)

		require_once(ABSPATH . 'wp-admin/includes/upgrade.php');

Ovanstående kod vandrar igenom alla dina siter som är uppsatta i nätverket och kör aktiveringsfunktionen för dessa.

Koden ovan raderar inte tabellerna vid inaktivering, det skapar heller inte tabellerna för nya siter som aktiveras i nätverket. Du får i sådana fall använda följande actions:

add_action( 'wpmu_new_blog', 'your_function_activation_on_new_blog'); 		// For new site
register_deactivation_hook( __FILE__, 'your_deactivation_function' );		// For deactivation

jQTouch och WordPress

Eftersom mobila webbplatser är “the shizzle” numera så vill inte jag vara sämre än att haka på tåget. Då jag bygger mycket webbplatser i WordPress så vill jag ha ett “enkelt” sätt att ha ett separat tema för den mobila sidan och låta den rulla med hjälp av jQTouch.


Så, vad är det jag vill göra, jag vill identifiera besökarens webbläsare och om det är en mobil så ska den “on-the-fly” byta till mitt mobila tema. Jag vill sedan ha ett sätt att kunna hoppa mellan den mobila och vanliga webbplatsen.

All kod finns i en Gist på GitHub (mycket anpassad för mina behov) för hur jag löst detta. Jag skapade ett plugin som tog hand om det hela. Om mitt vanliga tema heter ‘xc1-test’, så kommer jag att kolla ifall temat ‘xc1-test-mobile’ existerar.

WordPress ger oss möjligheten att ladda in ett separat tema med hjälp av filtret ‘stylesheet’, så vi gör en kontroll ifall temat finns (och efterfrågas) och i sådana fall hoppar vi över till det.


Temat xc1-test-mobile innehåller inte så mycket annat än exempelkod från jQTouchs lösning, så det är inte mycket nytt under solen där.

Det som inte är så vackert just nu är hur sidor och inlägg hämtas ifrån WordPress, jQTouch hämtar enbart statiska filer, därför har jag fått lov att lägga till .html i slutet på mina sidor. Poster däremot får man lov att ändra manuellt permalänk-inställningen i administrationen så den har .html på slutet. Detta kommer jag nog ändra och skriva om AJAX-hämtningen manuellt, men detta var mest för att få allting att fungera i ett inledande skede.

Temats filer single.php och page.php ska inte innehålla get_header() och get_footer().

Jag kan sedan hoppa mellan de två olika versionerna genom querystringen ?xc1-layout=mobile och ?xc1-layout=default.


Något som är riktigt fint i WordPress 3 är att jag kan skapa en separat meny (i menyhanteraren) för den mobila versionen och använda den i detta mobila tema, då kan jag skapa separata mobilversioner av de sidor som jag vill ha tillgängliga ifrån mobilen.


Jag har tittat mycket på hur andra har löst detta, jag kommer skriva mer om detta när jag känner mig nöjd med lösningen, ge gärna kommentarer på hur ni löst detta.