Idea: Static Templates for WordPress

I was helping out a friend a few days with their fairly complicated WordPress website. Complicated because it had over 40 different page templates, rendered exclusively by PHP.

Each page template had something special about it, like a form and form handler, a JavaScript calculator, a list of registered users, the current user profile and more. Page Templates worked pretty well, and the other “simple” options were shortcodes (bleh!) or page-{slug}.php templates.

Anyway, when this friend of mine was porting the site over from his development environment to production, he had to recreate those 40 pages, make sure their slugs matched, and assign the appropriate page template from that drop-down list of over 40 times. What a nightmare!

Static Templates

I thought there should be an easier way. One that would work similar to page templates, but without that extra database overhead, without the UI and everything else. Obviously this would render a WordPress theme completely useless outside of the original context, but so do 40 page templates.

I drafted up a plugin, a proof of concept, and called it Static Templates. The idea is for a theme to have a static-templates folder, with .php templates named after certain slugs. For example:

/about/           => /themes/foo/static-templates/about.php
/about/contacts/  => /themes/foo/static-templates/about-contacts.php
/foo/bar/baz/     => /themes/foo/static-templates/foo-bar-baz.php

So when /about/ is requested, you don’t need to worry about creating a page in WordPress, creating a new template and assigning it to your page. All you have to worry about is your /static-templates/about.php file.

Obviously if a page with that slug exists in the WordPress database, it’ll be loaded instead, so static templates have a lower priority, and there’s still that little overhead of trying to fetch a non-existent page from the database before a static template is invoked. It also does not (yet) distinguish between /foo/bar/ and /foo-bar/ requests.

Anyway, as I mentioned this is just an idea, and I would absolutely love to hear your thoughts about it.

Debug Bar Slow Actions

If a typical WordPress page load takes more than one second, chances are there’s something terribly wrong with your site, a theme or a plugin is probably doing something it shouldn’t. Obviously you don’t have time to review every single line in your codebase, so Debug Bar Slow Actions might help you out.

Debug Bar Slow Actions is an extension for the popular Debug Bar plugin. It adds a new panel with a list of the top 100 slowest actions (and filters) during the current page request.

Debug Bar Slow Actions

It’s fairly lightweight (as opposed to xdebug and other profiling tools), but I wouldn’t recommend running it on a production environment, or at least not for long. It does hook to each and every action and filter (twice!) to time it, though timing is pretty fast and it’s highly unlikely that it’ll ever become a performance bottleneck.

After you’ve found out which action is the slowest, you can easily lookup the callback functions hooked to that action, perhaps using tools like Query Monitor, or a simple var_dump:

add_action( 'init', 'whats_at_init', 9999 );
function whats_at_init() {
	var_dump( $GLOBALS['wp_filter']['init'] );

Update: version 0.8.1 and above will show you the number of callbacks hooked to each action, and it’s also possible to expand the callbacks list.

You can get Debug Bar Slow Actions from or GitHub.

Happy profiling!

Fail2ban + WordPress + Nginx

I’ve been using the Limit Login Attempts plugin for WordPress for quite a while. It basically logs failed login attempts and automatically blocks multiple attempts from a single IP address. A few days ago I’ve switched to fail2ban instead, which is pretty new to me.

Fail2ban with WordPress and Nginx

Fail2ban is a fairly simple yet very flexible framework that monitors log files for certain patterns, and runs preconfigured actions upon certain events.

Out of the box fail2ban comes with many so called filters, which are sets of matching rules, for example SSH auth failure, vsftpd login failure and more. As well as predefined actions, like block the IP address via iptables, send an e-mail with the IP WHOIS info, etc.

I haven’t had too much time to play around with the configs, but I did manage to get it to work with my WordPress install on nginx, and here’s how.

Continue reading

Retina MacBook Pro

At Automattic we get to upgrade our computers once every two years or so, and a few weeks ago I got a brand new 13″ MacBook Pro with Retina display. This was my first reaction:

Even large sites like Facebook and Twitter are not Retina-friendly, despite the fact that it’s now been well over a year since the first Retina MacBook hit the shelves. It’s like looking at low-quality JPEG.

Working with screenshots is very painful, because when you take a screenshot and then share it, the image you get is twice as large and also low-quality. Well, low-quality as in non-HiDPI. I guess that’s an annoyance I can live with.

I’m still getting used to the slightly larger font size, down to 1280 width from 1440 (13″ MacBook Air), although the Display settings allow you to configure that, and bring it up to 1440 or even higher, thus bringing quality down. Not something I see myself changing, unless it’s for testing purposes only.

Other than that, the Retina laptop is not too different from my older 13″ MacBook Air. It’s slightly smaller and weighs a little more, but the battery lasts much longer, which is perfect for travel. I haven’t really measured it, but I think the Retina MacBook generates a little bit more heat.

Overall I’m happy with my new MacBook, especially since I now have more room for WordCamp stickers :)