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.

NBA Playoffs 2016 second round recap

The second round of the Playoffs has come to a close, and it’s been a nice mixture of surprises and things that went almost exactly as anticipated.


1. Cavs vs 4. Hawks

Despite my Cavs in six prediction, early in the series it was clear that Atlanta didn’t stand a real chance against these Cavs, that have now a full 10-men rotation in place, and that have found an exceptionally great mojo from downtown. They played four games in both of their rounds so far, which means not so much playing time and lots of rest, which will surely come in handy in the conference finals.

2. Raptors vs 3. Heat

Could I have been any more wrong about this? I don’t think so. The injuries to Valanciunas and Whiteside proved to be tough to overcome, but the series has given us plenty of highlights: Dwyane shining like its 2010, the initial struggle of Lowry that was able to recover from his slump and make huge plays in games 5, 6 and 7, and Bismack Biyombo running for Toronto’s mayor office. The Raptors reached the conference finals for the first time in their history: they won’t get much farther away than that, but boy was this a great playoff run!


1. Warriors vs 5. Trail Blazers

I predicted Portland to be able to win at least a couple in the series, but I clearly though that Curry’s injury would impact the Warriors much more severely. What Steph has done in game 4 is something, yet another thing, that you’ll likely tell your grandchildren. Golden State went through some moments though in which they didn’t look completely in control, and will have to get some things in order (Green techs, for one) before the conference finals, since…

2. Spurs vs 3. Thunder

… the Thunder pulled off the biggest surprise in these Playoffs so far, by convincingly slamming away the Spurs in six games. Westbrook wasn’t probably at his best, Durant looked great, which is something that we haven’t seen in a while, and their phisical presence was phenomenal against a San Antonio team that failed at doing what they do best than everyone else, which is executing on offense. Two names stand above the others: Steven Adams, a true presence in the paint, and Billy Donovan, a rookie coach straight from college that has made the one thing that few, me included, thought possible, which was instilling a winning mentality in his guys.

Conference finals predictions


1. Cavs vs 2. Raptors

Toronto won the season series against Cleveland, but it’s clear that these Cavs are something else. They’re playing with confidence, and if the shots are going in like they have, it’ll all be over soon. Still, the Raptors have the men to guard both the perimeter and the paint (also, how about giving James Johnson some minutes now?), and if DeRozan gets a little confidence (that’s a giant “if”), they might be able to sneak a couple of wins. Cavs in 5.


1. Warriors vs 3. Thunder

This series is much closer to call than it would seem. OKC have the confidence on their side, they lost the regular season series against Golden State, but they were the ones that looked best against the Warriors. Again, Golden State must regain some composure and some flow, they desperately need to have Green mentally in control, and they need to have Harrison Barnes back in it, since he has been a non-factor so far. Steph gonna Steph, KD gonna KD, Russ gonna Russ, and the Thunder better pound the inside, with Adams and Kanter. All I want for Christmas is this series to last seven games. Warriors in 7.

How to deploy on a production server from your local Git repository

If you’re like me and began to do what you do more than a decade ago, you’ll definitely remember how we all used to push updates to our production servers via FTP. There’s no shame in that: we’ve all been beginners.

Using FTP might even be fine today for teeny-weeny projects, but two things are for sure:

  1. it’s slow,
  2. it will almost always lead to uncertainty regarding the syncronization between your local copy of the project, and the remote one on the server (even if I hear that some people still develop directly on a server, but that’s a rant for another occasion).

Luckily for us, we have version control systems such as Git and our work is never really lost.

So how can we avoid using FTP to upload updates to our production servers?

You set up a new repository that’s hosted on the very same production server you’ll project will end up on and also push updates to that repository.

So let’s assume that you have developed a theme for WordPress and you want to keep it in sync with your local copy.

I wouldn’t want to have the theme folder on the production server to host the repository itself, so I’d opt to set it up in a folder outside public_html and then listen for push events on that repository and perform a checkout of the project to the actual theme folder.

So, since I’m lazy, I’ve created a little script to make my life easier:

rm -rf $1.git
mkdir -p $1.git
cd $1.git
git --bare init
cat <<EOF >hooks/post-receive
mkdir -p $2
export GIT_WORK_TREE=$2
git checkout -f
chmod +x hooks/post-receive

You can create a file (let’s say in the folder that will host your repositories on the server, adjust the file permissions so that it can be executed (chmod +x ./, and launch it with the following syntax:

./ repository-name path-to-actual-folder

This script does the following things in sequence:

  1. remove any pre-existing repository with the specified name,
  2. set up a new blank repository in a specific folder whose name is indicated by the first parameter (in our case repository-name),
  3. create a hook that is triggered upon receiving a push that will perform the checkout in the actual project folder (second parameter passed to the script, in our case path-to-actual-folder).

So, assuming that you have a standard WordPress installation in the root directory, you could create a repository that points to the themes folder:

./ your-theme-name /home/your-user/public_html/wp-content/themes/your-theme-name

The only remaining thing is to upload stuff to the production server, for which you’ll have to create a new remote pointing to the newly created repository through SSH and then execute a push towards said remote:


assuming that you’ve created the repository in a repos folder in your home directory, which I’d recommend.

As you can see, this is nothing too complex, but it’s a pretty nice time saver nonetheless.