Category: Javascript

Adding pageviews to WordPress stats on galleries

Jetpack is awesome. Among many features, by default, it runs WordPress stats. While they are not Google Analytics by any means, they do give you a nice view on how your site is doing, with a very small footprint. The event code is just added to your site’s footer and voila! it just works!

The problem is your site’s footer doesn’t know anything. Slideshows, galleries, compilations and one-page apps are good examples of cases where the content of the page changes via Javascript with a click, or perhaps a time-based approach. As far as I know, wp stats doesn’t have a solution for this issue. I, however, have a hack ready to go, that works wonders.

NOTE: This code will not work on your site as is! but it will hopefully give you the general idea on how to do it.

Let’s make 2 assumptions: one, you have jQuery available (not necessary), and two, the page we have is a picture gallery and fires an event “pageChange” every time NEXT or PREV are clicked.

The part that does the pageview of course is:

This code was added on July 24th. Notice the traffic increase after July 25th.

One of the sites I handle has a lot of ajax type slideshows. Traffic itself didn’t increase, it just wasn’t being recorded on wpstats (see chart above)!

Boom! easy! The same concept applies to one-page applications. Make sure to pass the right urls and post ids to WordPress Stats.

Run javascript that depends on multiple remote assets

Async JS is the way of the present (and future). We MUST load all of our scripts async. They are getting heavy and slow, and the browser needs help, specially on mobile devices. Why wouldn’t you want your page to load faster (see this post).

As web pages grow more and more complex, the idea of a single script that does everything is Jurassic. But what if we want to run code that depends on multiple scripts at the same time? If your app/site is complex you should look into requireJS. If you need something less daunting … I got you (with jQuery):

Neat right? … Let’s kick it up a notch. Say we need the script AND some external data file:

And now the cherry on top … we want to load myData.json or yourData.json or just nothing conditionally:


I’m sure you can do something similar on vanilla JS … but if you need something like this, chances are you are running jQuery.

How to make SYNC javascript assets work ASYNC

Speed is everything. It always is … there is no such thing as “the page loaded too fast”. To make matters worse, today we have Google Pagespeed Insights to make our lives miserable (a whole different topic). They usually recommend loading your JS asynchronous (async) or on the footer.


Javascript is render blocking, which means the browser can’t work on displaying the page while the script is running. So, consider this:

If myscript.js takes 1 minute to load, the whole page will be delayed 1 minute, no matter how simple it is. Not cool. To fix this, we just add async to the script tag. This makes the browser start the load of the asset (myscript.js) but continue parsing html. The problem now is that because the asset is still loading, and will arrive in 1 minute, the function changeText() is not available by the time the browser gets to it. Your code will not run, but the page has loaded, which is good news.



You can implement a queue or a callback*. Both ways work just as nicely, but they have different use cases. (* you can use Promises but that’s kind of a callback, just real fancy)

Queues work better if you need to do many calls to the same script in different parts of the page but all depend on the previous call one way or another. Here you go (Notice the change on the js file):

Tiny change … works like a charm … once myscript.js loads 1 minute later, it’ll execute all the functions pushed to the queue.

Potential pitfall 
Lets say instead of the script loading slow, it loads super fast. If you are working on the DOM, make sure the elements you want, are in place by the time the queue executes. In the example this is mitigated by adding to the queue after the dom element ( <div> ).

Implementing a callback is a bit easier, but works better if you only need to run code once. Notice, no changes are needed on myscript.js from the original version.

You can make a hybrid of these 2 approaches where the callback is the code to process the queue … but it feels a bit ghetto to me. I’m sure there is some good use case where this would be desirable. The same pitfall as above applies, but as long as you load the script after the dom element you’ll be ok.

As always there is a jQuery way to do this. And it is in fact quite nice, what I don’t like about it is having to load jQuery synchronous. That being said, you can probably turn all your jquery into a queue and now “we all happy“.


To $(document).ready() or not to $(document).ready() ? that is the question.


If you place your JS/jQuery below the elements, you don’t have to use $(document).ready.


Wrapping all your Javascript in a $(document).ready. All the cool kids are doing it, and it is safe to do so. However, this doesn’t come without drawbacks. Also, there multiple considerations when it comes to loading jQuery itself, but that’s a different conversation.

jQuery SHOULD be loaded on the footer of your <html>. At this point, wrapping or not doesn’t really matter. The magic lies in the fact the by the time your JS runs, the elements are already on the page (aka above the script you are running ).


But let’s say you are forced to load jQuery in the <head> AND you are also forced (or want) to place your JS on <head> as well … now you HAVE to use $(document).ready( function() {} ); because by the time the JS runs, the elements to be selected haven’t been seen by the browser yet.



Code included inside $( document ).ready() will only run once the page Document Object Model (DOM) is ready for JavaScript code to execute. Code included inside $( window ).load(function() { ... }) will run once the entire page (images or iframes), not just the DOM, is ready.

Here’s where the issue lies. When you use $(document).ready() you need to wait for the entire page to load! So, if you want to have your JS do some kind of effect, like a sticky sidebar, or transitions, or anything at all, they will not happen instantly. Sometimes, this isn’t an issue, but the more images and external script your page has, the longer it takes for your js to run. This can be unacceptable, as most of the times, this causes your effect to start working at weird times, making the site … well … act weird.

The solution: instead of wrapping in .ready(), place the <script> just below the elements you want it to work on. Again, by the time your script runs, the elements have already been “seen” by the browser, and the effects will kick in even though the page hasn’t completely loaded yet. No need to wait.


Layers on Canvas


Can’t be done natively, use this instead: layeredCanvas


HTML5 Canvas doesn’t implement a layers mechanism. In order to implement this you can do it in 2 different ways:

Multiple canvas elements approach

Think of a layer as an individual canvas and then absolute position one on top of the other. Then to lay it out just wrap on a div with position relative:

What’s crappy about this is if you want to save the image you have to do a screenshot and then cut it, or you can only save one canvas element at a time.

Single canvas element approach

Natively, there is no way of doing this, but with a little bit of abstraction, it isn’t a problem. Think of a layer as a function, now you call the functions in order and you are mostly layered:

This is still a bit crappy … lets make it slight more layer-like. We can make an array of functions and run them in sequence. This is much better because now we can remove (or change the index) an element from the array effectively replicating a layer feel:

DONE! Not too bad … using this principle I created a more elegant approach that allows you a couple more neat little things like show/hide … try it, fork it, use it: layeredCanvas

Quick and Dirty JS slider (qndslider)

We do not need more JS sliders, there is plenty of alternatives. But while looking at them, I realized they all force you into learning their small quirks. That is a total annoyance and waste of time, so I set myself to write a super simple, super easy and understandable slider: the qndslider, the Quick and Dirty Slider.

You can download and use at your leisure:

The beauty of it, is that I coded the basics of any slider to save you time, but you are in control of the interaction. I.E. you can call to move to the next slide, but have a callback on what happens after the slider changes. All the basic funcionality is in, next(), previous(), timers, start(), stop().

It is NOT a jQuery plugin, but it does use jQuery to find the elements.

The Basics
You don’t have to use Divs, it could be UL/LI or P/SPAN as long as the slides have the “slide” class and the wrapper the id you call in the JS, in this case “GreatSlider”.

No, it doesnt have NEXT or PREV arrows, that is up to you. How you place them, how you style them, etc. it is ALL up to you. That way, is a bit hard, but you understand exactly what’s going on. Same goes for current slide and stuff like that. See more detailes at Github.