Best way to initialize a class on a WordPress plugin

When you’re developing a WordPress plugin, there are certain patterns and practices that are extremely useful to know and apply in order to get a better fit with the platform as a whole.

One of these things it’s what’s the better way to initialize a class on a plugin, which this answer on the WordPress StackExchange covers in great detail, while also explaining other interesting topics and recommendations such as using an autoloader and global access, registry and service locator patterns.

While you’re at it, you might also want to check these posts from Tom McFarlin:


Pixel Density, Demystified

…or “what you must know about designing for retina display and high-density screens”.

Pixel density it’s an often misunderstood subject: some people think that the solution it’s just to design everything at twice the size that they used to, but actually it’s a little simpler and more complicated than that… at the same time.

Be sure to also check the text version on Medium and remember:

  1. Design in vector shapes
  2. Design at “1x”


The greatest countries and administrative subdivisions database ever

The United Nations Code for Trade and Transport Locations it’s probably the greatest countries, states, regions, cities and localities database you can ever find; or at least the most complete you might hope for. It includes over 100,000 locations in 249 countries with detailed administrative subdivisions info and even geographic coordinates (rough, but still).

Getting response headers data from an AJAX request with javascript

Response headers can contain valuable information and may help to keep your API responses simpler by separating the actual response data from accessory metadata.

For instance, when querying the WordPress JSON API for a list of posts, the response body includes just the posts data but the pagination info it’s sent as headers:

HTTP/1.1 200 OK
Access-Control-Allow-Headers: Authorization
Access-Control-Expose-Headers: X-WP-Total, X-WP-TotalPages
X-WP-Total: 7
X-WP-TotalPages: 2

Whether you’re using jQuery or just plain Javascript, it’s quite simple to get response headers.

Using jQuery

I’ll keep using the same case of getting a list of posts from the WordPress API.

The jQuery code for the AJAX request would look something like this:

var posts = $.ajax({
  type: 'GET'
  url: '/wp-json/wp/v2/posts/',
  data: {
    'per_page': 10

In jQuery, an AJAX request returns a promise, so after that we could do something like:

posts.done( function( data, textStatus, jqXHR ){
  var receiver = $('#posts-receiver');
  for ( var i in data ){
    receiver.append( data.title.rendered +':'+ );
  var current_page = parseInt('paged'), 10 ),
      total_pages  = parseInt( jqXHR.getResponseHeader('X-WP-TotalPages'), 10 );
  if ( curent_page == total_pages ) {
    $('button#load-more-posts').attr('disabled', 'disabled');
} );

The jqXHR object it’s a superset of the native XMLHttpRequest object. It exposes a jqXHR.getResponseHeader() method for getting a single response header (which it’s always returned as a string) and jqXHR.getAllResponseHeaders() for getting all of them as a single string.

Using plain javascript

The same getResponseHeader method is available in plain javascript as part of the XMLHttpRequest object; the only thing that changes it’s the way you create and initiate the request:

var request = new XMLHttpRequest;'GET', '/wp-json/wp/v2/posts', true);
request.onload = function(){
  // do some stuff
  var total_pages = parseInt( request.getResponseHeader('X-WP-TotalPages), 10 );

The most complete localization data you’ll ever need

The Unicode Common Locale Data Repository it’s “the largest and most extensive repository of locale data available”, so it’s pretty much the perfect solution when you need information such as:

  • Currency values, with ISO codes and visualization formats
  • Dates and times patterns, including timezones
  • List of “territories”, countries, continents, etc. with their corresponding languages, currencies
  • Translations of all of the above

You can get their data from their Downloads page in XML format (follow the links in the Data column) or, if you prefer JSON, you may the Releases on their GitHub repository.

The JSON data it’s also available for use with NPM or bower.

Un-breaking lighttpd’s broken mod_access

A client let us know that the server where her company’s site was hosted had an unusually high load.

After checking the access log for the web server, it was clear that the cause was repeated access attempts at a single URL, which was not essential to the site. So I though this should be easy, I’ll just block the request in the web server config. Unfortunately, they were using a very outdated version of lighttpd, so it wasn’t that easy.

It seems that older lighttpd builds had several bugs with mod_access, but the worst in our case was that instead of blocking the request and send a 403 Forbidden, it passed the request on to the 404 error handler, and this loaded the entire app enviroment.

So here’s what I did. The lighttpd config looked like this:

$HTTP["url"] =~ "^/foobar.php" {
    url.access-deny = ("")
    server.error-handler-404 = "/403.php"

… so request to foobar.php would be handled by 403.php. And then, 403.php:

<?php header('HTTP/1.0 403 Forbidden'); ?>

Very silly, but effective. Just because status codes matter.