Lazy load all the things!

It may not be obvious to everybody, but everything that relies on the use of the src attribute can be “lazy loaded”. If you’re unsure about what the term “lazy load” means, it is the deferred loading of a resource, performed through JavaScript, which, in simpler terms, can be rephrased as “I won’t load it until I really need it”. Now, what most people do is defer the loading of images: you take your img tags, strip them of their src attributes, and store the value somewhere else, like a data-src attribute. This way, the browser won’t load the resource (image, in this case) at all. When you do need to load the image, simply convert the data-src attribute to an a src attribute with the same value, and the browser will start loading the resource instantly.
var image = document.querySelector( "img" );

image.setAttribute( "src", image.getAttribute( "data-src" ) );
Recently, I was working on a project that required a lot of embeds to be present in page, with more of them optionally loaded upon clicking on a pagination element. Embeds can be heavy. No, heavy is not quite the word I’m looking for. Lots of embeds can kill a web page performance. But, again, I had no other choice but to have a bunch of iframes together side-by-side. Then it dawned on me: the same reasoning that we use for images could be applied to those iframes as well. As a matter of fact, whatever relies on a src attribute, even stylesheets, can be lazy loaded like that. And that’s exactly what I ended up doing: having a bunch of inert iframes, each one with its data-src attribute regularly filled, waiting to be converted to the standard src attribute. Sure, if you load a lot of those iframes, you’ll end up having a pretty resource-demanding page at the end, but sure enough, the initial load will be much much lighter.

jQuery force element redraw

So, today I’ve discovered a neat trick to solve an issue that’s been bothering me essentially since I’ve started web development.

As you know, jQuery offers the ability to modify the DOM at will. Now, all of the functions available to perform DOM operations are syncronous, meaning that the next instruction will start only when the one that preceedes it will have finished its task.

This is not necessarily true for the actual DOM manipulation, leaving us in the middle of a muddy unfathomable jungle, where one thing is syncronous, but actually isn’t.

Before complex UI libraries came around, this led generations of developers, including myself, to solve this issue with loads of setTimeout calls, whose milliseconds parameter was inconsistent, at best: sometimes a 1 millisecond value would do it, sometimes it was 10 milliseconds, other times any other number that you could think of.

In all honesty, this felt weird and unstable from day one: so what if there was a way to get rid of setTimeouts entirely and force a redraw of the manipulated DOM element?

Turns out, it’s simpler than I thought. Here’s the snippet:

$.fn.force_redraw = function() {
    return this.hide( 0, function() {
        $( this ).show();
    } );

Simply instantly hide and show the element, and you’ll be good to go, and you’ll be able to say goodbye to at least some of your setTimeouts.

Multi-dimensional isset

When working with large array/object data, especially when the overall structure is a mix of the two types, it is often useful to check if a given property exists.

This is something particularly relevant since data structures may change over time, needing to be reshaped.

For that task, I’ve written a small function that checks if a given sub-key exists in an array/object: if it does, the function will return its value, while if it doesn’t it will return either a specified default value, or boolean false.

The function produces the following results:

$arr = array(
	'a' => array(
		'b' => 42,
		'c' => new stdClass()

$arr['a']['c']->foo = "bar";

var_dump( ev_isset( $arr, array( 'a', 'b' ) ) ); // returns "42"
var_dump( ev_isset( $arr, array( 'a', 'd' ) ) ); // returns false
var_dump( ev_isset( $arr, array( 'a', 'c', 'foo' ) ) ); // returns "bar"
var_dump( ev_isset( $arr, array( 'a', 'c', 'baz' ), 'default value' ) ); // returns "default value"


An alternative to file_get_contents

The official WordPress Theme Review guidelines are fairly strict in some cases, and for a good reason: those best practices, tips and rules ensure that the risk of having bad code pushed to the ever growing themes and plugins repository is kept to the minimum.

One of those rules dictates that direct file operations aren’t allowed, unless they’re performed through the Filesystem API. Due to this restriction, the use of an handy function such as file_get_contents is prohibited, and its occurrences in a theme are promptly signaled by the Theme Check plugin.

For local reads, though, there’s a way to access a file’s contents without invoking file_get_contents

$content = implode( ‘’, file( $path_to_file );

which essentially accesses the file, reads its lines into an array, whose elements are then joined in a single string.

Developing locally with a REST API

As you may know, during these days, at Evolve are building our own WordPress themes and plugins shop, in preparation for the launch of our very first independently sold product, Brix, a drag and drop page builder.

One of the things that we’ve implemented on top of a standard WooCoomerce install, is a purchase code validation system that relies on the well known WordPress REST API.

When developing this kind of things, it’s generally a good idea to have a local copy of both the server and the client, so that the latter can make calls, and the former can answer them.

Now, WordPress has a couple of neat little functions whose job is to make GET and POST calls to external services, namely wp_remote_get and wp_remote_post, and if you’re not using them to perform those tasks, by all means you should!

No matter how hard I try, one of the things that I keep forgetting every time I find myself in this situation, is that you’ll need to add a particular command in your code so that your local copy of the server can be called using said functions.

The command is nothing else than a specific filter that will sort of whitelist the local server address, otherwise unknown to the caller. It goes like this:

add_filter( 'http_request_host_is_external', '__return_true' );

After your development is done, remember to remove the line when going in production.

A note regarding importing serialized data in WordPress

The WordPress Importer hasn’t received much love lately.

It does work without any particular issue, it’s a tad slow, but in the end it doesn’t give you any particular headache, if not throwing a couple of warnings here and there if you have the WP_DEBUG constant turned on.

Luckily for us, a redux version is in the works, maintained by the fine folks at Human Made, that looks very promising.

The other day I was trying to import a couple of pages that had serialized data in one of their post metas and the Importer kept failing at adding those metas, while still being able to correctly create the pages.

This situation left me baffled for a while, so I started digging.

The reason for the Importer not being able to import serialized data was related to line endings contained in the array I was dealing with: in particular \r\n line endings had to be converted to \n in order for the importer not to fail.

I’ve written a recursive function you might want to pass your data through before actually saving your post meta, in case it might contain values with line endings, such as the ones generated by user input in a textarea:

function replace_endlines_deep( $data ) {
	if ( ! is_array( $data ) ) {
		return $data;

	foreach ( $data as $k => $v ) {
		if ( is_array( $v ) ) {
			$data[$k] = replace_endlines_deep( $v );
		else {
			$data[$k] = str_replace( "\r\n", "\n", $data[$k] );

	return $data;

So actually saving the data to the database would become:

// ... make sure to sanitize user input ...

$data = replace_endlines_deep( $data );

update_post_meta( $post_id, 'my_serialized_data', $data );

Customizing the “Enter title here” placeholder text

Today I’ve put a new item in my ideal category of “WordPress things I didn’t even know existed”, which is the ability to edit the “Enter title here” placeholder text when creating a new post or a new item in a Custom Post Type.

While there is no way of customizing such text at the moment of the creation of the Custom Post Type, there’s a neat filter that you can use to alter it, depending on the type of the post you’re creating.

It could go something like this:

add_filter( 'enter_title_here', function( $title, $post ) {
	if ( $post->post_type === 'your-post-type' ) {
		$title = __( 'Enter Company Name' );

	return $title;
}, 10, 2 );

Pretty easy, right? This is also a cool way of avoiding calling “Title” what in fact could be a “Company Name” or a “Testimonial Name”.