Category Archives: Web development

WordPress: stylesheet inclusion order

In WordPress, custom style and script resources should be incorporated with the corresponding API calls, such as wp_register_style and wp_enqueue_style. These API calls are usually only indirectly called: they should be registered with the add_action API call, which supports priorities. WordPress then calls the wp_register/enqueue_* functions automatically at the right time. The order of these calls is given by the priorities set up when calling add_action. A big warning: these priorities, however, do not translate into the order in which the script/style resources end up in the HTML. This has been clarified in this StackOverflow answer: http://wordpress.stackexchange.com/a/91964

Stylesheet ordering can only reliably be achieved with WordPress’ concept of “stylesheet dependencies”. These can be defined with the fourth argument to wp_register_style, e.g.:

wp_register_style('magnific_popup_style', get_stylesheet_directory_uri().'/magnific-popup/magnific-popup.css', array('twentytwelve-style'));

The fourth argument in this call is array('twentytwelve-style'). This would make sure that the /magnific-popup/magnific-popup.css inclusion (via HTML link tag) is done after inclusion of the stylesheet with the internal handle name 'twentytwelve-style' (as you can see, you need to know the handle name of a stylesheet in order to define it as a dependency).

Application scenario: the 'twentytwelve-style' is the theme’s main stylesheet in my case. Without explicitly defining this dependency above, my WordPress would incorporate the magnific-popup CSS before incorporating my theme’s CSS. However, I need the magnific-popup CSS to override some CSS rules defined in my theme’s CSS. Likewise, I need to reliably make sure that the magnific-popup CSS is loaded after the theme’s CSS. Therefore the dependency.

This is quite a simple concept — it’s just that the WordPress docs are not so explicit about all this. The most complicated thing in all this was to find out the internal stylesheet handle name of my theme (these are the little quirks people hate WordPress for). I’ve written another small post about how to reliably find out this one: see WordPress: theme stylesheet handle name

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.

Die richtige Technik für die eigene Website: eine Übersicht

In diesem Artikel möchte ich auf verschiedene Wege eingehen, die man bis zur eigenen Website gehen kann. Der Artikel erhebt keinen Anspruch auf Vollständigkeit, soll aber doch eine Übersicht über dieses komplexe Thema bieten. Er konzentriert sich auf technische Aspekte, denn in erster Linie ist eine Website die technische Implementierung eines abstrakten Konzepts. Damit das Konzept aufgeht, muss die Technik stets unter Kontrolle sein. Eine gute Übersicht über die zahlreichen technischen Finessen ist Pflicht, ansonsten überraschen auf lange Sicht diverse Probleme — wahrscheinlich auch den Nutzer. Allgemein gilt: bei der Implementierung einer Website ist ein besonders großes Spektrum verschiedener technischer Aspekte zu berücksichtigen. Ist die eigene Website von Bedeutung (privat oder für das Geschäft), sollte man auf professionellen Rat nicht verzichten.
Continue reading

Ever been in the forest of lightbox solutions? Found a good tree: Magnific Popup by Dmitry Semenov

Serious engineering: most common tasks have solid solutions

When we deal with software and code, especially open source code, there almost always is a specialized, rock-solid and well-established solution for what we need. Let it be a program such as ghostscript, a library such as OpenMPI or numpy, a web server such as nginx, or a content management system such as Drupal. No need to only name dinosaurs, also quite modern developments often are absolutely professional and rock-solid, considering e.g. pandas and Redis. All of these and many more software projects have in common that you, as a user, can rely on the developers to be awesome and make things right. If it fits your problem, you can be sure that you have a very good tool at hand. Often, you even have no doubt that you are using the best tool the world has to offer. No second thoughts, you can go ahead and combine these technologies and do some serious engineering with serious tools.

Web development: most common tasks have an entire forest of imperfect solutions

However, when it comes to web frontend code snippets, the situation is entirely different, at least from my point of view. I’m not talking about serious projects such as backbone.js, which is great. Did you ever have a quick web search for finding the right ‘Lightbox’ implementation for the website you were just working on? An image gallery? An image slider? There are tons of different solutions out there, because this is an extremely common problem and every semi-experienced ‘web developer’ comes up with her or his own approach and publishes it, sometimes even tries to sell it. I think the issue here is that the community of ‘web developers’ is one of the largest among software developers and that the sub-tasks often are quite small. This leads to quite a low entry level, yielding many solutions. The result, put in extreme words, is a forest of imperfect solutions. It is entirely possible that one tree in this forest is much better than the rest but, in my opinion, the main problem here is: how can you find the best solution? The forest is just too dense, it is difficult to get a good overview. It is clear to everybody that it would be much better to have just a handful of solutions with a high quality standard, resulting from joined efforts and good engineering by people that have a broad experience in the field they are working on and a strong technological background in what they are doing.

Yes, I could start hacking on my own ‘Lightbox’ solution right now and I would get it working, for sure, like all the others did. But it would fail in certain scenarios, it would show inconveniences, because I do not have the experience. In the meantime, browsers and web standards are much too diverse to be able to come up with the perfect solution just because one has done a bit of software development for a couple of years. You have to be a real expert.

Need a lightbox? Have a closer look at Magnific Popup

According to the considerations made above, I recommend people to read Dmitry Semenov’s lightbox article here:

http://coding.smashingmagazine.com/2013/05/02/truly-responsive-lightbox/

I have done research on Lightbox stuff for quite a while now and no solution really convinced me by the criteria outlined in the first paragraph. Nevertheless, I had to use this or that solution here and there, with mixed feelings. Magnific Popup — as published in May 2013 by Dmitry Semenov — is the first solution that makes the impression to me to be able to develop into the one, rock-solid, well-established open source project. Although initially published by Dmitry Semenov, Magnific Popup in fact is joined effort, it combines experiences and seemingly merges the best technologies around the lightbox topic known today.

With this article I would like to provide some orientation in the forest of ‘Lightbox’ solutions. Have a look at Magnific Popup, and, if you think something can be done better, contribute. Magnific Popup at least has the potential to become the best. It should be among the first search results when searching the web for ‘lightbox’ or ‘jquery lightbox’.