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.

Small changes that make the difference

In these days, I’m trying to test the new Gutenberg editor on my personal website, and as part of the Gutenberg Challenge, I’m forcing myself to write something about it, at least once a week. I’ve always thought that the variety of controls that you have at your disposal would eventually become a problem, since there’s only so much space for displaying them. Splitting stuff in tabs, and displaying quick shortcuts before even clicking the “+” button is exactly the type of countermove to balance the aforementioned abundancy. The general feeling that I have with this editor is quite frankly great, and for the first time in years I don’t feel the urge to go back writing the post in an editor that’s more comfortable to me, such as Sublime Text or Byword. The only thing I don’t really see the necessity of is the Drop Cap setting, which is, in my opinion, cosmetic enough to be enforced as an option by the theme that’s currently active, rather than the editor itself.

Yay, Gutenberg!

This is the first post that I'm writing using the new shiny Gutenberg editor that someday will land in WordPress core. I'm not sure I'll be able to keep up with the #GuntenbergChallenge, that would be trying to write and publish at least one post per week using Gutenberg, but what I can tell right now is that this editor feels like a breathe of fresh air, and a much needed step in the right direction. We'll probably never be able to bridge the gap between what happens in the backend and the visual representation you have on the frontend, but the ability to have a more visual approach to things is always appreciated, especially with something as fundamental as a post/page content. If you want to know more, or perhaps getting involved in the project, follow its development on GitHub.

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.

So I switched to Android

First things first: this post is not a rant.

It isn’t one of those fan boy posts you may stumble upon from time to time either.

I want this to be a quick and honest tale about what it’s like to leave a well known environment (the iPhone and its operative system iOS) for something of which I knew little (Android and the numerous devices it powers), and the reasons that drove me to consider and then make the switch in the first place.

My experience with the iPhone

Let me begin by saying that my experience with the iPhone is not the reason of the switch. I’ve been a happy iPhone user for the past seven years, and I still think those are the best mobile devices out there.

In that time, I’ve had an iPhone 3GS and an iPhone 5S, and I must say that the operative system they run is intuitive, fast and problem-solving oriented.

Sure, as a developer I would have liked a little more control here and there, but overall I can’t really complain.

The reasons that drove me to consider alternatives to that safe harbor are essentially three:

  1. I wanted a bigger screen. The iPhone 5S was the last of the “small ones”, and thanks to great services such as Pocket, my reading time on the iPhone has spiked up in the past couple of years, mostly when commuting to/from my workplace, and reading on a bigger screen is a completely different story.
  2. I needed more space. 16GBs might have been good 7 years ago, when photo cameras on phones weren’t this appealing, and generally produced smaller file sizes.
    Finding myself in the position of having to backup and delete most of them before, say, making a trip, because otherwise I wouldn’t be able to download offline maps has become annoyingly frequent recently.

I know what you’re thinking: “you could’ve used iCloud”. I’ve never been much of an iCloud person, to be honest, and its limits are still pretty stringent.
3. The price. Again, let me clarify on this point: iPhones are well worth what they cost, and the same applies to almost all of other Apple devices (after all I’m writing this post on a six years-old MacBook Pro, and my main browsing device back at home is an iPad Air 2).

At a certain point, though, mostly because the prices in the country where I live are significantly higher than the US for example, they simply become too high for such an expense to be made once every two/three years.

If I were to choose between finding the money for an iPhone 7 plus, or spending a few more days out on holiday, I’d pick the holiday any day.

The switch

One of the main driving reasons for this change is that my partner at work has made the switch from iOS a couple of years ago and didn’t regret it, so I started to actively look for alternatives.

I chose Android. Most of the apps I used on the iPhone have their Android counterpart that works exactly the same, and the Android release cycle feels (and probably is) much more stable that the one of Windows mobile OS, so I think this was kind of a no brainer.

At a certain point in my digital life, I’ve realized that the way I use the Web is much more Google-centric than it is Apple-centric.

My email is on Gmail, I take notes with Google Keep, Google Maps beats Apple Maps 3-0, and we use Google Drive at work, as well as Google Calendar for both personal and work events.

So, yeah, Google, you got me. Generally, this situation is one I wouldn’t recommend – being completely hooked to a highly connected set of services, because if one fails bad, chances are the others will follow along.

Google is pretty trustworthy on this aspect, though. So for now, I’m keeping this thought in the back of my head.

The device

Apple makes it awfully simple for people to buy one of their product, and rightfully so. You want to buy an iPhone? Ok, you have a basic/advanced models combo. It’s an easy choice, very little cognitive overload, higher conversion rate.

When you’re approaching the Android world, things change drastically.

Although there is an official device, promoted from Google themselves, any mobile devices manufacturer can virtually create one or more product running the OS, and, in fact, that’s exactly what they’re doing.

So if you want to buy an Android device, the quantity of available choices that you have is quite intimidating.

Apple offers not only great devices, but also the trustworthiness of a huge company, and finding one that does the same for Android isn’t necessarily that straightforward.

I’d like to paint three scenarios:

  1. You can go for the big fish, Samsung or Google, only to find that its devices are priced just as much as an iPhone. For that price, I think the iPhone is a better choice.
  2. You can opt for a not-so-big, yet still reliable company, such as LG, HTC, or even Huawei, for which the price range is usually significantly wider.
  3. You can be a little adventurous and pick a less known company that tries to stay afloat and swim steadily in this ocean, usually also being aggressive on the price.

I firmly think that decisions made on money are wrong. If you’re finding something (anything, really) that suits you better, and it’s also cheaper, then great, lucky you. But if you’re making a decision (again, about anything) based purely on money, I think you might (will) end up regretting it.

Despite willing to spend less money, I’m not really inclined to compromise on quality. For my experience, quality compromises lead to frustration, and frustration isn’t something I like to deal with, for personal stuff, as well as for work-related problems.

Long story short, I went for option #3 and chose to purchase a OnePlus 3.

OnePlus is a young company, and they know this is a truth they can’t deny. There’s nothing to be ashamed about being new on the market, by the way – it’s just a fact.

When you unbox the OnePlus 3, you can read a quick note right from the CEO that tells you that, although they’re young, they’re also doing their best to learn from their mistakes and get better at doing stuff.

Creating a product is hard.

We know that all too well. When we’ve created our page builder for WordPress, Brix, we knew it wasn’t only a matter of how good the product might intrinsically be.

It’s a matter of how it’s perceived by potential buyers, how’s going to be supported over time, how can it respond to the market, and how many blows it can get without falling down.

At $399 OnePlus has created a wonderful device, that’s modern, solid, and eye-catching – a rare combination of factors.

You look at it, and you perceive an idea behind it. Some would say that such idea is simply “Ok, let’s port the iPhone to Android”, but I think there’s more than that.

What I miss

Being so accustomed to iOS, it’s difficult not to notice small differences.

I’d like to make a list of things that I miss, coming from the iPhone, but keep in mind that only some of these items are software-related, while the rest is likely due to the different hardware being used.

  1. The adaptive brightness of the screen works erratically. The display is very bright, perhaps the brightest display I’ve ever seen on a mobile device, yet sometimes fails at setting the correct brightness depending on the ambient light. Not a biggie, happened at times on the iPhone as well.
  2. Android could use some love on the focus state of textual inputs. The blinking cursor is there even if the field has no focus yet, leaving me perplexed. I’ll probably get used to it, but I think this issue should be tackled somehow.
  3. Android has an option for everything. On one side, this is a plus: you can make your device behave exactly the way you want. On the other side, options are not always consistent in how they’re laid out, and they can be a bit hard to find.
  4. There’s no a built-in way to block annoying incoming calls in the OS, and to do that you need to install third-party apps, which must then be configured to make them work and not drain your battery.

What I like having now

  1. I like having all the apps that I used on the iPhone. This is a big plus and probably the single biggest factor that led me to change OS: the experience on Facebook, Twitter, Pocket,, just to name a few, is nearly identical across operative systems.
  2. I won’t be using it anytime soon, but I like the idea of being able to turn on electronic payments on the phone.
  3. The touch sensor on the OnePlus 3 is unbelievably fast. I used to prefer inputting the usual four-digit number to unlock the phone, but I rarely do it anymore.
  4. The OS feels more fresh. UI inconsistencies aside, I have the feeling that the folks at Google like to experiment more with their OS: the result may vary, but generally I see this as an opportunity to create something better and better, rather than a risk for failure.
  5. Fast charging. The OnePlus 3 is a beast, in this regard. They’ve implemented (and patented, if I’m not mistaken) a system to fast charge the phone using a special power connector that overheats itself, instead of doing it to the phone’s battery. The result is that a one-hour charge gets you to 100%: pretty impressive. Also, battery itself is not bad either: I usually get 4 days during the week, and 5 over the weekend, and recently I also tested it while at WordCamp Milano, where I”ve been able to get 2 full days of really intense usage (I was on Slack+WIFI all the time, basically).
  6. I love being able to know if I have notifications pending to be read by looking at a simple led light in the upper left corner of my phone, and I also like the fact that you can know which apps generated those notifications by looking at the led light color.
  7. Lots of other small things: power management analysis, data traffic analysis, the ability to clear background processes and their respective caches with ease, memory available (6GB RAM coupled with 64GB), etc.


There actually isn’t a conclusion to this post. This is just a report of my first month with an Android device, and I’m looking forward to testing it even more in the coming months.

At this point, I’d consider it useless to make a suggestion as to whether switch or not: phones are very personal devices, and you have to pick one according to your feelings and needs, both in terms of functionality and aestethics.

The one thing I can say, though, is that switching is possible and that it’s less painful than what it may seem.

So, any comments? Let me know!

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"


Your code is not the end of the story

This is a quick post to remind me of something important, something that maybe is not only relevant to WordPress, but surely is magnified in that context.

Before starting my own gig, I worked for a software company. Sure, we could pick up data from external sources, but, apart from these sporadic integrations, the whole show started and ended with things that we built, things that, supposedly, we knew 100%.

When working, developing, designing with WordPress your code is never the end of the story. Whether it’s a plugin or a theme, your code will always run alongside other codes, written by other people, with various skills degrees; people you will most likely not know.

If you’re like me, you might reject this idea, even for a little while: running other people’s code can expose yours to issues, and generally impact the end product you’ve so carefully created, possibly making look bad, without you having done nothing really wrong.

Recently, we’ve fixed a couple of compatibility issues with a product we’re publishing. One of those issues, specifically, got me thinking: it was something that I never thought could be a possibility, yet it took only a couple of minutes to adapt what we wrote to that unforeseen scenario.

I’m not saying that we must expect the unexpected, rather than you need to embrace this heterogeneity as a fact, and work for it, not against it.

As with all diversities, it’ll maybe take some time to accept it, but the reward, not necessarily for you, but for the people that are going to use your product, is too big to be missed.

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.