Responsify WP 1.6

Since Responsify WP (RWP) was published on wordpress.org this summer, I’ve released eight updates to the plugin. Most of them was minor bugfixes and improvments, but there has been a couple of larger updates. The latest one, version 1.6, is the largest and greatest.

It started as a simple helper class that generated Picturefill markup. Now it starts to feel like a mature WordPress plugin that handles it’s job well. I guess it’s a good sign that I enjoy using it myself.
Thanks to some helpful users of RWP, the most critical bugs was discovered and I was able to fix them.
Version 1.4 was the one released at wordpress.org. 1.5 added the possibility to select the real picture element as markup pattern instead of the one using span tags.
In late september, a blog post suggesting the usage of the img element with srcset and sizes attributes instead of picture was published. The article was picked up by Chris Coyer, Brad Frost and all the others. It was seen a lot on Twitter.
I had been thinking about implementing support for srcset/sizes even before the plugin had a name, but I never did. The reason was that I simply found the concept very hard to understand. I mean, what’s the deal with w and vw?
But that article made me force myself to study the subject, once and for all. And after playing around with it for a few days, I got the #ahamoment.

1.6

A couple of weeks later, RWP 1.6 was released. img with srcset/sizes was the new default markup pattern. picture and span were still avaliable as options.
If your template looks like this:

<article>
    <h1><?php the_title();?></h1>
    <?php the_content();?>
</article>

The output might look like this without RWP:

<article>
    <h1>Hello world</h1>
    <p>Lorem ipsum dolor sit amet...</p>
    <img src="example.com/wp-content/uploads/2014/03/IMG_4540.jpg" alt="Image description">
</article>

But with the plugin installed, the image would become responsive.

<article>
    <h1>Hello world</h1>
    <p>Lorem ipsum dolor sit amet...</p>
    <img sizes="100vw" 
        srcset="example.com/wp-content/uploads/2014/03/IMG_4540-300x199.jpg 300w,
        example.com/wp-content/uploads/2014/03/IMG_4540-1024x681.jpg 1024w,
        example.com/wp-content/uploads/2014/03/IMG_4540.jpg <image-width>"
        src="example.com/wp-content/uploads/2014/03/IMG_4540-150x150.jpg" alt="Image description">
</article>

Documentation takes time

As I’ve said on Twitter a lot, it’s not the programming itself that takes time. It’ the writing of documentation.
For instance, I had to write new examples that demonstrated the new markup pattern. I had to add a whole new section to the function reference. And of course, I had to test all the examples to make sure that everything worked properly.

TDD

Speaking of testing. I really need to add unit tests to the plugin. For each update, the number of users has grown and it becomes more scary to ship the update.
1.6 was a pretty large update and I’ve promised myself that I’ll never release such an update without unit tests ensuring everything works.
This is also something I’ve wanted to add for a long time. But when I started building the plugin, I found that the learning curve for testing a WordPress plugin was to steep.
But now, when I’ve played around quite a bit with the WordPress test suite, I feel more comfortable with it.
However, a lot of refactoring will be needed to make the entire plugin testable. There are some classes that might do a bit more work than they should be doing. I also wanna try to follow the five SOLID design principles.
With that in mind, a complete rewrite of the plugin would be a good excercise in more than one way.