Month: August 2009

Using custom error pages in Varnish

by

While playing around with the fancy error pages I wanted to use them with Varnish as well. Since there is no means to include a file or serve a file from Varnish (without serving from a back end server), I went with inline C snippet to read and serve the error pages. Please note that the style sheet and the images are being served from a CDN. Otherwise it will have to be cached prior to the back end server becoming inaccessible. Here is the whole vcl_error sub. You will notice that we fall back to default Varnish error page for anything other than 5XX errors.

[code lang=’c’]sub vcl_error {
set obj.http.Content-Type = “text/html; charset=utf-8”;

if ( obj.status >= 500 && obj.status <= 505) { C{ #include
#include

FILE * pFile;
char content [100];
char page [10240];
char fname [50];

page[0] = ‘\0’;
sprintf(fname, “/var/www/errors/%d.html”, VRT_r_obj_status(sp));

pFile = fopen(fname, “r”);
while (fgets(content, 100, pFile)) {
strcat(page, content);
}
fclose(pFile);
VRT_synth_page(sp, 0, page, ““, vrt_magic_string_end);
}C
} else {
synthetic {”




“} obj.status ” ” obj.response {“

Error “} obj.status ” ” obj.response {“

“} obj.response {“

Guru Meditation:

XID: “} req.xid {“

Varnish



“};
}

return (deliver);
}[/code]

Hope someone will find this useful as I had to put some effort to find out all the internal Varnish function names

Fancy HTTP Error pages – 5xx

by

If you hadn’t noticed my site was giving HTTP 500 errors last couple of days. The issue was found to be a segfault and it’s fixed now. That got me to come up with a set of funny and slick HTTP error pages. I only came up with HTTP 5xx error pages, I believe HTTP 4xx error pages should be specific to the site. You can download them here. If you want to take a peek, here is the list. HTTP 500, 501, 502, 503, 504, 505. Feel free to modify them and share what you come up with.

How to customize a WordPress plugin and upgrade

by

Sometimes you want to make minor changes to WordPress plugins that no body except your self would want. Then comes the issue of upgrading to new versions of the plugin. git-svn is the perfect tool for this. It has all the cool features of the distributed SCM git and ability to pull from subversion (and push to it as well). Here is how I do it:

  1. Clone the trunk [code language=’shell’ options=’toolbar: false; gutter: false;’]git svn clone http://svn.wp-plugins.org/web-invoice/trunk/[/code]
  2. Make your changes
  3. Commit changes locally [code language=’shell’ options=’toolbar: false; gutter: false;’]git commit -a[/code]
  4. Pull new changes (e.g. new release). Git is very good at merging, you will not have conflicts unless you edit exact same lines in the local version. Still a manual merge shouldn’t be too complicated [code language=’shell’ options=’toolbar: false; gutter: false;’]git svn rebase[/code]

In the example I have taken the svn trunk of Web Invoice WordPress plugin. Hope you find this information useful next time you hack a WordPress plugin.