Managing z-index without loosing your hair

I’ve run into issues time and time again managing z-index. Sure, most of the time, z-index related issues are far from complex.

However, I’ve come to a passionate dislike of magic values and numbers. What is 58 or 3000 after all? It’s an arbitrary number. Wouldn’t it be a lot nicer to have layers in CSS, just like in Photoshop or Illustrator ?

And sure enough, a quick search revealed multiple articles around z-index management.

CSS Layers instead of Z-Index

After years of using Sass daily, I’ve switched over to Stylus (that probably deserves an article of it’s own), and sure enough – a quick search search revealed an already made Stylus mixin in a Github gist.

I’m using a slightly modified version of that.


Configure the layers.

The configuration file contains all the layers and their z-index. I’m not using dots or hashes in names, so I can avoid adding quotes as well. This makes it just a little bit tidier for my taste.


The z-index manager mixin

I’ve modified the mixin in a few ways:

  1. I’m calling it layer. Easier to type than z_index, and it makes sense to me.
  2. I’ve added unused_z_layers, which is going to help with debugging ( see below )
  3. I’ve also added adjust option to the mixin.



The adjust option comes in really handy when dealing with local changes, without having to create a new layer for absolutely everything.

For example, if you have a layer for the menu, and you want to place a second div just under the menu, instead of having to create Menu: 500, Thing_Under_Menu: 490, I just use layer(Menu, -10).

So the usage looks something like this:

The Debug

Having a lot of  layers sometimes results in unused layers that are defined. This helps me keep track of that. In case

Stylus will already throw an error if I try to use layer(Mooooo) if Moooo doesn’t exist. That’s good.

However, what about the inverse? When Moooo is defined, but is unused? That’s where the debug comes in:

That’s going to throw a console warning when an unused layer is found.

I always include this after everything else, and on each compile it’s going to check for unused layers.

That’s it.

It’s a really simple approach, but has helped me keep my sanity when managing z-index in complex layouts.


Easier way to make sure all strings are escaped in WordPress themes

We all know we should escape all the strings in a theme. WordPress theme review guidelines require it, and so does Themeforest.

After working on a theme for a longer period of time, it’s quite possible that you’ve slipped somewhere with unescaped echoes. If you’re going commando on your own – you still need to escape every little thing and be twice as careful if there are no additional set of eyes on your code.

This has happened to me time and time again, and after about a 100 rejections on Themeforest (throughout all my theme submissions), I think it’s about time to start avoiding some of the rejection reasons. One of which is validation.

Searching for echo is just not going to cut it. In my code – that’s just too many lines to go over the code. On top of that – when searching for a simple echo, it’s easy to miss a problematic echo statement among all the wp_kses and esc_attr functions I’ve used.

And as always…

Regex to the rescue

I’m searching all files and folders with this pattern in phpStorm, but I bet this works in Sublime Text and probably Atom too:


This is going to search for all echo statements, that don’t contain kses, esc_, get_, sanitize.

I think I can ignore get_ functions because I trust WordPress to have already sanitized at least that content.

An important part is the \s before get_ and sanitize because  I may have written a function that has get or sanitize in the function name, and we don’t want to ignore those, so ignore them only if the function starts with a space character so that my prefixed dastheme_get_something() functions are not going to be ignored.

Finally – this is going to include all __() and _e() functions. If you find them, make sure you’ve properly sanitized them. You should be using esc_html__() instead anyway.

Starting to write again

We finally launched our website – Colormelon.

For too long we’ve been the shoemakers with no shoes. It was very difficult to find the time to design our own site – it seems that there are always better things to do!
Even right now, there is a huge pile of things we’d rather create than our website, but after years of making web designs for others, we decided that it was finally time we got a website too, or at least start the process of building our site.

As a part of the decision to launch our website, was that we wanted to build a blog for Photographers.


Writing for Change

We’ve seen too many sites spreading either incorrect information or purely profit oriented information, for example affiliate inspired hosting reviews. The only way to change things is by sharing unbiased information. At least that’s the first step, and that’s the step I never really took seriously, until recently. So we decided that we’re going to run a blog for Photographers over at Colormelon. Soon after I realized – writing is extremely hard.

Writing isn’t hard, Writing is a skill

Today I tweeted this:

and that really made me think – what if that’s only true, because for the past 10 years I’ve been writing code more than text? Maybe if I practice writing every day it might become a bit easier ?

So here it goes – I am going to write as much as I possibly can about everything I can think of. I don’t know where this journey is going to lead me, but I hope that when it’s all said and done that I end up changing the internet, and maybe the world – for the better.



Find all unescaped i18n strings in in WordPress

It turns out, that from now on, it’s a best practice to escape with esc_html__() instead of simply doing __() in your plugins and themes.

Replacing everything with esc_html() is a solution, but what about the __() in your code that already contain some minor code ( like a few wrapping spans here and there ) ?

Here is what I did:

1. Search and replace every __() with esc_html__() and _e() with esc_html_e()

2. Then find all the esc_html functions that have HTML in them

That’s going to show you all the esc_html__() and esc_html_e() that contains a “<” or “>” somewhere within. I use phpStorm to perform the search, and the above Regex works just fine for me.

3. Adjust your code so that the string no longer requires inline HTML

That’s it. You’re no longer a robot that has to manually go over each internationalized string.

Download a complete single page with wget

A simple way to download a complete page

Very much inspired by Guy Rutenberg,
I only modified the snippet slightly with -N, which validates timestamps and doesn’t download duplicated ( but does overwrite local files with the new changes ) and robots=off, so I wouldn’t download the robots.txt

An easier way to keep your JavaScript libraries up to date

When I first heard of Bower, I really, really wanted to love it. In theory Bower sounds like the real deal:

Bower works by fetching and installing packages from all over, taking care of hunting, finding, downloading, and saving the stuff you’re looking for. Bower keeps track of these packages in a manifest file, bower.json. How you use packages is up to you. Bower provides hooks to facilitate using packages in your tools and workflows.

Bower is optimized for the front-end. Bower uses a flat dependency tree, requiring only one version for each package, reducing page load to a minimum.

Unfortunately – it’s not how it works in practice. Sure, bower finds packages for me, but that’s about it. After I’ve downloaded the packages, I have no idea where the files might end up in, what are they going to be called, how to include them, so after the package is downloaded – you’re on your own, bower just calls in quits. Even tools like gulp-bower or grunt-bower don’t help all that much. No standardized way to get an unminified version or a file. Sometimes you can guess, other times you can’t.

But the worst part, for me – bower doesn’t update the scripts properly. At first, I was very confused about how updating works in Bower, and it looks like I’m not the only one. Looks like nowadays you can update the scripts, but major version updates are still a pain in Bower, and the argument for it, in my opinion is very weak.

I’m not going to go into how the updating in bower actually works, and to be perfectly honest, I don’t care about that all that much anymore. What I’m looking for is speed and ease of use.

Workflow incompatibility

I know, there is an ocean of people who love bower. But I never managed to fit Bower in my workflow. I don’t really need to think about dependency tree in a standard way. Wordpress dictates the version of jQuery and underscore.js that I’m supposed to use.

All of JavaScript libraries that I’ve used in my life, with a few exceptions ( I’m looking at you desandro ), have every little thing built right in. In many cases, even a jQuery shim.

Sure – that’s a lot of overhead, and it’s not ideal.
An ideal tool would be like Bower that people would trust, and everyone could depend on each others snippets, shims, plugins etc., but at the moment, it looks like a very, very distant utopia. Everyone has their own workflow, standards, preferences.  We’re still debating on spaces vs tabs after all.


A simple solution for simple folks

I’m a simple man, looking for a plain simple solution.
I don’t need “built-in” security that prevents automatic major version upgrades. If a problem comes up because of a library update – I want to address it ASAP. I just want the latest version of the libraries I’m using.

So I came up with a simple workaround with Gulp.js.

Gulp.js to the rescue


In external_libs add your libraries and the URL to pull them down from and that’s it! If you prefer – you can keep it in a .json file, but this works perfectly fine for me.

Run gulp getlibs in your terminal and get the latest version of all your libs! Add version management ( like Git ) to your project, and you’ll always be aware of all changes in the libraries you use. Dead simple.


A simple one-liner to convert all JavaScript to CoffeeScript

A simple one-liner to convert all JavaScript in a folder to CoffeeScript

First, make sure you have installed “js2coffee” ( and is real cool for single files too ):

And then just paste this:

-it options modifies the spaces to tabs, remove it if you prefer spaces.


Picking values from an Array in WordPress

_.pick is great

Underscore.js has a lot of great stuff packed in it. One of the functions I love is pick, which lets you input some keys and get a new array from an Array.

Can’t pick in PHP

So today I wanted to find an alternative to Underscore’s _.pick for PHP, and I didn’t. It’s not a function that would be difficult to write, but that’s where WordPress comes in.

Can pick in WordPress

People at WordPress thought that it would be a nice helper for them too, so in WordPress 3.1 they added wp_array_slice_assoc.

The naming is a bit long, but the function is awesome anyway and the naming explains the purpose alright. Slice an array associativley ( that’s a big word ).

Here is how it works.

Imagine we have a some array like this one.

In this case the array is a mess, your array should never be a mess, but it might happen. In this case, I know I want only John and Jane in my array, so I can do this:

Tara. Now I have a new array “$persons” which has only john and jane.

How is this useful ?

Well, there are times where you would write something like this:

Which I think of an overkill, especially if you need like 10 variables. Of course you could extract from all of them

But what if the array has like 20 items. What happens when they clash? What if someone else modifies your code? I just don’t feel that blindly using extract is the best development pattern.

Along comes wp_array_slice_assoc()

Or a slightly more readable (based on preference) variant

That’s it.

Final Note

Please, please be careful extracting variables. And when you do, please document them, even if the documentation comes in the form of $keys_to_extract. Recently I had a very difficult time figuring out what is what because the author of a plugin pulled some weird variables out of nowhere and I had to run around var_dump’ing all over the place until I figured out what is what.

Facing Failure

My Theme Was Rejected

Before it was approved.

In fact, we’ve had 2 themes rejected on Themeforest for various reasons and only now will I admit that I was angry. I was mad! Mad at the reviewers, counting clicks they’ve made reviewing my themes. Mad at myself for developing something that isn’t approved. Mad at the universe for putting me in this position ( I could just have found a case full of money instead of all this… ). How much did that help? Zero. It only led to

Burning Out

Self pity. Anger. Frustration. Fear.
I experienced it all, and it seems that the more I felt any of these emotions, the more I got similar ones. I thought I am never going to get out of it.

For good reason.

I quit my job in January with very limited funds in my pocket. Having done that, I had a motivator that basically says “either you’ll learn how to swim or you’ll sink” was pretty motivating, until I had to face rejection. Once it was introduced, it was like having someone at the shore shouting: “Give up! You can’t swim, just let go and drown already”. Not motivating at all. Which caused the (what seemed to be the) endless misery.

Just do it.

I have no idea what did it for me. It may be that I was already expecting that. I wanted to say prepared, but you just can’t be prepared for that sort of thing, and you’re not even going to get what you we’re expecting as well.

So after all the rejection, and having our Acid theme also rejected, I just decided that nothing is going to stop me. I will work on the Acid theme until it is approved.

As it turns out. It’s all that was necessary. I could write a book where I could describe all the advice I’ve accumulated from all the literature I’ve read on the subject, but it all really boils down to the decision not to fail.

By that I mean – If you think you fail, you failed. If you decide not to fail at all, you won’t. Or as Thomas Edison puts it:

I haven’t failed. I’ve just discovered 10’000 ways that won’t work.

It’s a really simple lesson. At least it sounds simple. But there is no way you’ll learn it but through experience.

Snippet: Get the correct page in WordPress

Here is another really quick snippet.
If you have a page where you’re using Query Posts you’re going to have trouble with Pagination.
Wordpress for some reason likes to use page and paged randomly.

If you assign your page as the “front page”, you’re going to have to get_query_var(‘page’), and if you’re going to assign it elsewhere, it’s going to be paged. This is all fine and dandy, at least when you’re in control, but as soon as someone else starts using your theme, you need something more trustworthy, and that’s what this is.
Continue reading Snippet: Get the correct page in WordPress