Author: Ipstenu (Mika Epstein)

Trust the Changelog
Recently there were a couple WordPress plugins with fairly major security fixes. But you wouldn’t know it by looking at their changelogs.

The changelog is a section of a product’s readme that describes what changed. For most people, it’s a list of items like this:
- Added feature X
- Corrected typo
- Security fix
The problem many people have is that last one is often left rather vague. I’m guilty of this myself. In a recent fix, I simply said “Security fix: Sanitizing _POST calls to prevent evil.” and “Security Fix: Implementing nonces.”

The primary reason we keep change logs a bit vague is because we don’t want to open the door to alert hackers as to vulnerabilities. People don’t update their code right away, so every time we publicize a security issue, the people who haven’t updated immediately are at greater risk of being hurt.

But if we don’t tell people how important it is to update, how do they know how important it is to update?

There’s the real issue. There’s not yet a proper balance between “You should upgrade as soon as possible” and “You need to upgrade now, or you’re doomed.” My security issue was only accessible by people with admin access. It would be possible to trick an admin, with a cleverly crafted page, but … The effort it took me to apply a nonce check and sanitize things is minimal. From my end, it’s very minor of a fix. From a user’s end, it’s an exceptionally rare hack and unlikely to occur.

The right answer here is “Always upgrade to the latest version of code as soon as possible.” The problem is “as soon as you can” gets bumped out if it’s not mission critical. A patch that adds in a filter? Not a big deal. A patch that secures my site? Should be a big deal. I would argue that any time anyone says “This is a security fix” then you shouldn’t have to concern yourself about how likely the hack is to impact. Instead, security is a watchword to tell you to update the software “immediately.”

Which brings us to two agreements we need to start making with people. The agreement of developers to do things ‘easier’ for users and the agreement of the users to trust developers. If we want people to upgrade, they have to trust us. And if they’re going to trust us, we have to be reliable and consistent.

As developers, we promise not to flag something as a critical security fix that isn’t just security fix. If there’s a major issue with our code, we will push a patch as soon as possible that only deals with that issue. There will be no feature changes, no little fixes, no minor tweaks. A security release will only be a security release.

Furthermore, to enable people to update properly, we will properly use semantic versioning. This will allow us to update minor releases as far back as logical, because you can know that version 1.2.8 is the latest version of the (old) 1.2 branch, and 1.5.3 is the latest of the (current) 1.5 branch. The next time we add in new features, we will properly version our code as 1.6 so that you know what branch is current.

As users, we promise to trust your security-only releases and upgrade our copies of your code when a minor release that is a security issue is released. If you release a version 1.5.4 and not a version 1.4.4, we will trust that either the 1.4 branch is not subject to this security issue, or the fix could not be back-ported. If you inform us that we must upgrade to the 1.5 branch because there’s no way to secure 1.4, we will expedite our upgrade.

In order to enable ease of upgrade, we will not edit our code to make it impossible to change. We will properly use functions and actions and filters and hooks. We will make regular backups as well as immediate ones before upgrading.

Of course… That’s a perfect world. But I’m going to do my part as a developer and start versioning better. If I do that, and if I as a user hold up my other end, then we can get to a place where all disclosures of security issues happen in tandem with a release, as we know that everyone will upgrade immediately.

A place of trust.
24 June, 2015
Heartbeat API
For the longest time I didn’t really get the heartbeat API. I get the very basics of it, but it took me a while to understand what it was really doing.

We’re used to interacting with our websites in a very one-directional way. I click a link, I go to a page. Heartbeat API is a bi-directional communication, which can best be translated as ‘shit happens without you having to click.’ The browser and the server are happily chatting to each other all the time, without me having to do anything.

If you’ve ever used Google Docs or MS Word or Apple Pages and noticed you don’t have to press ‘save’ all the time, that’s the idea of a Heartbeat API. It does the background things for you. That thing you should do (save often). In WordPress, the most obvious thing that Heartbeat does is it saves your posts as revisions.

That doesn’t stop neurotics like me from pressing ‘save’ all the time.

Of course, this can get a little expensive, checking all the time, so the Heartbeat API is smart. It only checks every 15 seconds by default (you can change this), and it only checks when you’re on a page doing something. If you just leave a page open, it slows down and, after an hour, turns off.

But besides saving, the Heartbeat API can share information between the systems. For example, it can ping out to Jetpack and check if it’s up and everything’s working, or if you have to reconnect your LinkedIn settings. And since it’s javascript based, it doesn’t reload the page.

You can use it to alert logged in users to new content. Imagine a post that suddenly had an overlay of ‘This post has been updated…’ Doing that requires two parts:
1. Hook into the send call and add your data
2. Hook into the receive call and show the data
Pippin has a great heartbeat API example but he also warns people:

I’ve managed to bring down server servers by using the Heartbeat API on the frontend.

If you trigger things to be called too often, you can totally crash a server.

The Heartbeat API is a step towards making our sites really responsive and modular. Instead of statically checking via PHP if someone’s logged in and changing display based on that, Heartbeat can dynamically change on the fly. This would allow caching systems like Varnish or static-file caches like WP Super Cache, to save the cache and speed up your site while still being dynamic. It lessens the weight on wp_ajax_ and makes things work with caches, rather than bypass them.

And that will make our sites beat faster for everyone.
22 June, 2015
Mailbag: Would You Review…

From ‘anon’ in Orange County:

Why did you review plugins at WCOC but you said no when I asked you to review mine?

That’s not actually exactly what he said. I’ve cleaned up the English.

At WordCamp Orange Country, I was given the rare opportunity to put value judgements on plugins. I never get to do this. I review plugins on WordPress.org every day (pretty much). I test them and evaluate them and send back comments. I look for bugs and security and guideline issues.

What I never get to do is tell people how I feel about their plugins. So when WCOC asked me to judge the Plugin-a-palooza contest ala American Idol, I replied “Oh I’m Simon Cowell. I’m in.” And when Ryan Seacrest — I mean Chris Lema asked me why I agreed to do it, I said it was because I never got to be myself when I reviewed plugins. I never got to just review and tell people how I felt.

They should have known. Right?

The plugin that won was not the one I liked the best. The one I liked the best was small, it was simple (if a little complex with the code). It did one thing and it did it very well. It wasn’t perfect by any means, but it worked. That plugin came in second.

The plugin that won, I wanted to like. In fact, I said that. I said “I really wanted to like this plugin.” And everyone went ‘oooooh’ (or possibly ‘boooo’). Chris jumped to my defense and pointed out I had warned them. So I detailed out why I didn’t like the plugin, from the UX perspective, and from the functionality. Some of why I didn’t like it weren’t it’s fault at all. It was trying to fix an imperfect system in a sensible way.

And I was asked, in the session, if it mattered to me if the flaws in the plugin were the fault of core, the APIs, or the plugin.

No.

Look. When you make a plugin, you’ve made it knowing the world around you and knowing what’s already broken (or non-optimal). So when you’ve made decisions on how you handle things, I firmly feel that you should be graceful and reliable and fail intelligently. And I don’t think they did. I think they solved the main problem, but in doing so created a host of others.

When someone asks me to review their code (theme or plugin) it’s like being asked if the pants make their butt look big. They want to hear “This is great.” I believe coding is as much art as math (and yes, I see the beauty in math), so it’s also a very critical and personal thing to be told that I don’t like this thing you’ve created. It hurts!

But for the folks in plugin-a-palooza, they knew what they were getting into. Maybe they didn’t know it was with me, but they knew. They knew they’d be judged on merits and flaws. Most people who email me asking for those reviews don’t know that. They think maybe they’ll get a security review or a comment about how things could be better.

What they’re going to get is how I feel about their work. Did the art speak to me? Did I get confused when I used it? Did I enjoy it? Do I think it did what it set out to do? Do I think it fixes the issues it claims to address?

Most people really aren’t ready for the real answers. And as much as it’s nice to be able to be me for a while, I’m still always chained by the reality that my reviews come from someone who’s involved in the WordPress community. Just imagine my ‘testimonials.’

So in the interests of not starting fights, not giving myself headaches, and not making everyone grumpy, I will decline to review your code today.

19 June, 2015
CloudFlare Code Muncher
CloudFlare’s email protection butchered my code examples.

Just putting that out there.

What Happened?

I went, perhaps ironically, to a post about changing your git repo URLs after activating CloudFlare, and was confused. See, I knew the code was something like me@mydomain.com:/path/to/repo but when I visited the page, it was all gibberish like this:
```
/* <![CDATA[ */!function(){try{var t="currentScript"in document?document.currentScript:function(){for(var t=document.getElementsByTagName("script"),e=t.length;e--;)if(t[e].getAttribute("cf-hash"))return t[e]}();if(t&&t.previousSibling){var e,r,n,i,c=t.previousSibling,a=c.getAttribute("data-cfemail");if(a){for(e="",r=parseInt(a.substr(0,2),16),n=2;a.length-n;n+=2)i=parseInt(a.substr(n,2),16)^r,e+=String.fromCharCode(i);e=document.createTextNode(e),c.parentNode.replaceChild(e,c)}}}catch(u){}}();/* ]]> */
```
I quickly edited the post and saw the content there was just fine. The only content that was getting munged was code output. It was very confusing so I googled and found a surprising answer.

What Was Wrong?

Turns out it was “Email Address Obfuscation” — a feature in CloudFlare that munges your email address to protect it from being scraped. In and of itself, that is ultra cool.

I could wrap everything like this:
```



```
Or I could filter all the shortcodes… Or I could turn off “Email Address Obfuscation”

I went with turning off the setting because it was faster, and it’s not like people cant deduce my email address. But if I was going to set it up, the fastest would actually be to filter all shortcodes, and that proved problematic.

Why All?

One of the problems is that I use Syntax Highlighter Evolved to handle my code chunks, and one of the things that plugin does is let me use a shortcode based on the programing language. That means the most efficient way would be to say “If this is a shortcode, wrap it in the email-off tags to tell it to shut up.”

Can You Code It?

This is theoretical and not fully tested. Use at your own risk.

With embeds, you can do things like this:
```
add_filter('embed_oembed_html', 'halfelf_embed_oembed_html', 99, 4);
function halfelf_embed_oembed_html($html, $url, $attr, $post_id) {
  return '' . $html . '';
}
```
But sadly there isn’t a wrap around like that for shortcodes, which means we have to do some serious filtering. There’s a global array called $shortcode_tags that lists all shortcodes (as you register them, so shall they be added), so I’m going to take that and replace their callback functions with my own. Then in my callback, I’ll keep their callback but at the same time I’ll wrap around it:
```
function cloudflare_email_off_for_shortcodes() {
    global $shortcode_tags;

    $shortcode_tags[ $tag ] = 'cloudflare_email_off_html';
}
add_action( 'init', 'cloudflare_email_off_for_shortcodes', 99 );

function cloudflare_email_off_html( $attr, $content = null, $tag ) {
    global $shortcode_tags;

    return '' . call_user_func( $shortcode_tags[ $tag ], $attr, $content, $tag ) . '';
}
```
But that struck me as a little expensive when I considered how rarely I put email addresses in things in the first place.
17 June, 2015
Bower To The Master

I recently mastered using Grunt to handle automation.

And then I was handed some Bower code by Carrie Dils. I’m up for a challenge, I muttered under my breath. I already have Node and NPM and Git, so this shouldn’t be too terrible.

Turns out I didn’t need to change a damn thing!

First off, Carrie and I are on the same wavelength, having named our files nearly the same and separated them the same. Second, I had been incredibly brilliant and put all of my code in separate files (my.css, my-config.php, etc etc). Third, I had documented everything that I had changed in all of my files in a my-readme.txt file.

But if I’m using Grunt, what am I going to get out of Bower?

Bower is a ‘front end’ package manager.

To install packages, I make a folder for my work and I go there in a command line, I type this:

$ bower install jquery

That would install bower into my folder. It’s dependency aware as well, so if I install Bourbon, it will include Neat. This is much the same as Grunt, which can install its plugins and dependencies, but where Grunt is for installing Node modules, Bower is for js and CSS and html as well.

Grunt is for running tasks. Bower is for managing components. They’re friends.

Bower lets me set up all the required components for my site (jquery for example). Grunt lets me compress, join, minify, and automate the deployment of those components.

I tell Bower to get the files and what versions they could be. I tell Grunt to combine all my mini-js files into one, combine them, compress them, and put them in another location. That means I tell Bower to bring in jquery, but it puts it in a development folder. Grunt takes that and copies it to the js folder.

Personally I take it a step further and, when I use Git to push my code, I tell it to delete the development folder off the server. I also do as Chase Adams does, and I don’t version control my dev packages. I may define jquery’s version, but I dont worry about capturing that in my repositories.

You don’t have to use Grunt. You could use Gulp. I had a sticker for Grunt on my laptop from a friend, so I tried it first and found I liked it.

Taking all this a step further, there are tools like Yeoman that will let you kickstart a project by saying ‘yo’ and telling it what kind of project you want to make. Yes, there’s a WordPress project called YeoPress.

The point of all this is that automation is the queen of development. Don’t do manually what you can safely, reliably, and responsibly automate. Like the Queen on the chessboard, strike out in all directions and control the board. Use the tools to repeat the hard work, to keep dependencies up to date, and to automate the annoying work.

15 June, 2015
Mailbag: Static Bars and z-index
Lindsey asks:

I found this post on your site (https://halfelf.org/2013/genesis-static-nav-bar/) and had a follow up question about it. My nav bar is now static and fixed to the top of my site, but for some reason a couple of things go over the top of it when I scroll, namely two AdSense ads and a related posts plugin’s images at the end of posts on single post pages. I would love any advice you may have on fixing this. I’m sure it must be something simple, but I can’t figure it out. Thanks!

It’s the z-index. If you’ve used Photoshop, you know about layers. Well, z-index is similar for webpages. It defines the ‘stack’ order, or what’s ‘on top’ of everything else.

Logically you want a video ‘on top’ of the CSS etc of the page, so most of the time this isn’t a problem. At the same time when we’re using CSS to position a menu, it gets … weird.

The basic idea of z-index is that any element with greater stack order is always on top of an element with a lower stack order.

Here’s the CSS I used for my floating menu:
```
.nav-primary {
    position:fixed;
    z-index:99;
    top: 0;
    width: 100%
}
```
The z-index on the WP toolbar (that black bar on the top of your site) is z-index: 99999; so you can change your CSS from 99 to 99998 and that should take care of it. We do want that toolbar to always win, after all.
12 June, 2015