Category Archives: WordPress

WordPress: theme stylesheet handle name

In this blog post, I clarified how to reliably define the order of stylesheet incorporations in WordPress with the deps argument to the wp_register_style function. In my application scenario, I needed to make sure that a certain custom CSS resource becomes loaded after my theme’s CSS (so that this certain CSS code can override rules defined in the theme’s CSS). For doing so, one needs to define the custom CSS code as depending on the theme’s CSS code. For this, on the other hand, one needs to know the internal stylesheet handle name of the theme’s stylesheet. This name is usually defined when registering a custom stylesheet, using the handle argument:

“Name of the stylesheet (which should be unique as it is used to identify the script in the whole system)”

The theme’s stylesheet, however, is loaded automatically, we don’t register it ourselves. Likewise, we don’t provide its name ourselves. So, what is its name? I could not find any hint in the WP docs, also searching the web gave no direct help. I have a solution for finding it out, therefore this blog post.

I figured I need to do some debugging and print all the stylesheet handle names known to WordPress, under the assumption that the theme’s default stylesheet is among them and has an unambiguous name. So, I noticed a function called wp_print_styles in the WP source, you can have a look at it here (as of WP version 3.8.1). For calling this function in the context of WP, I used one of the many PHP code execution plugins in order to call

var_dump(wp_print_styles());

in the context of a private page. Displaying this private page (or post, whatever you wish) in preview mode prints the stylesheet handle name array as built up by the WordPress ecosystem during page rendering. In my case, it looked like this before defining the stylesheet dependency:

array(10) {
[0]=>
string(9) “...”
[1]=>
string(9) “...”
[2]=>
string(9) “...”
[3]=>
string(15) “...”
[4]=>
string(20) “magnific_popup_style”
[5]=>
string(18) “twentytwelve-style”
[6]=>
string(18) “twentytwelve-fonts”
[7]=>
string(15) “twentytwelve-ie”
[8]=>
string(27) “...”
[9]=>
string(8) “...”
}

I changed those unimportant to this issue to "...". Since my theme is a child theme of the twentytwelve theme, from here it is quite clear that “twentytwelve-style” is the stylesheet handle name that I was looking for. Another important information from this variable dump is that the “magnific_popup_style” comes before the “twentytwelve-style” one. After defining the stylesheet dependency as explained in this blog post, the order changes:

array(10) {
[0]=>
string(9) “...”
[1]=>
string(9) “...”
[2]=>
string(9) “...”
[3]=>
string(15) “...”
[4]=>
string(18) “twentytwelve-style”
[5]=>
string(20) “magnific_popup_style”
[6]=>
string(18) “twentytwelve-fonts”
[7]=>
string(15) “twentytwelve-ie”
[8]=>
string(27) “...”
[9]=>
string(8) “...”
}

As it turns out, this array reflects the order of stylesheet inclusion in the final HTML output. After this tiny bit of debugging work, one can be quite sure about how the system works and how to reliably configure and use it.

Up again

I had some bad luck. Last week, my hosting provider performed a previously announced routine maintenance with the server running this website. During this maintenance, they managed to destroy the RAID (thanks, guys). All data lost. I did not have a very recent remote system snapshot and therefore needed to re-create the entire system from scratch.

A couple of months ago already, I have put Cloudflare in front of my website, so first I thought: hey, that gives me some time to restore things while the incident is largely transparent to the visitors of my website. I had activated Cloudflare’s “always online” feature months ago. That’s basically just a cache that jumps in when the backend is down. But wait, what does “down” mean? Cloudflare says that “always on” is triggered when the backend sends a 502 or 504 type response. Currently, when the backend is just dead (not responsive), this cache does not serve anything at all (in a support ticket, they said that they will “add this” in the future). My server went down at night and by the time I had a system and web server running again (and also sending a 502 response in order to trigger Cloudflare’s “always online”) — that was about 10 hours after the machine went down — the Cloudflare cache already assumed that my website does not exist anymore. Pah, “always online” useless. So, I am sorry, the downtime lasted quite long. I had to put all components back together manually.

Good thing is that I had up-to-date remote backups of my WordPress database (via Dropbox), my nginx config and other configs (via Bitbucket), and a more or less up-to-date remote backup of the directory structure behind my website. While settings things up again, I used the opportunity for re-structuring my website a bit. I am now running a modified version of the WordPress’ TwentyTwelve theme, for a cleaner appearance and a certain responsiveness.

A few hours before all data was lost, I wrote another blog post. That one was not contained in the latest (daily) WordPress database backup performed before the crash. When I realized that, the first thing I did was cp -a ing my Firefox and Chrome browser caches on the machine where I was writing that post. I then started digging in these caches in order to find residual pieces of the article’s content. And I found a golden piece. Chrome had cached a gzipped HTTP response containing the final version of my article, found via the chrome://cache/ list. Chrome displays the contents in a hexdump -C fashion. I copied this text, used a Python script to parse the dump, re-create the binary data, and to unzip this data. Based on the resulting HTML view of my article, I could quickly add it again to the WordPress system.

Some lessons learned:

  • Don’t trust scheduled routine maintenance, perform a backup *right* before that.
  • Cloudflare cache does not help in the situation where you need it most (that’s the current situation, at least).
  • Caches can still be of essential help in such a worst-case scenario. I recovered an article from the browser cache. I use the Google cache in order to see if something is still missing on the new version of my website
  • Google Webmastertools are pretty convenient in the sense that they inform you about crawling errors — I frequently check their interface and realize that there are still some missing pieces of my web presence (files, mostly).
  • Using (remote) code repositories for configuration stuff is the best you can do. First of all, it’s perfect bookkeeping if done properly. Secondly, if regularly pushed, it’s the best configuration backup you can have.

If you are still missing a file here and there or find some dead links, please don’t hesitate to notify me. Thanks.

WordPress deployment: super simple and super fast with nginx caching

WordPress (+plugins) is not exactly the most resource-efficient content management system. In order to go easy on CPU and memory, to guarantee short website load times, and to be able to stand up to page requests with high frequency, WordPress must be served from a cache rather than answering each request via PHP and from the database. In this post, you can find my nginx config for deploying PHP-FPM-based WordPress behind nginx whereas most of the requests are served from the nginx FastCGI cache. No changes to WordPress and no WordPress plugins are required. Continue reading