Category: How It Is

Making philosophy about the why behind technical things.

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
If You Know What To Do

I tweeted this a few days ago.

If you keep letting people make bad choices, they will KEEP MAKING BAD CHOICES!!!
Developers, please stop letting your clients do things that you know are wrong! Change the web with your power!

A few people joked about Nokia phones. I joked about sliders and auto-play videos.

But the real issue, the crux of this, was marked when the following reply hit my stream:

this is tougher when there’s a buffer of account execs, project managers, c-levels, stakeholders in the way 🙁

Yes. It is. So what was I really talking about and what does this mean?

If You Know What To Do…

You’re an expert. You’re an expert designer, developer, programmer, writer, whatever it is you know you’re great at. You are. Let’s put the imposter syndrome issue on the shelf and accept our greatness for what it is.

You know what’s right and what’s wrong. You know that keyword stuffing is bad. You know that not putting in alt/title tags for your images is bad. You know that auto-playing music will make us all want to kill you. You know that no one actually enjoys sliders. You know that mobile-first is the future. You know that CAPTCHA is inaccessible to many people. You know that China blocks WordPress.com.

You know a lot of things. You’re an expert. And you’ve been hired to be that expert.

… And You Don’t Do It …

We’ve all been there when someone on your project team says that ‘sliders improve conversation rates.’ And most of us have replied with a link to http://shouldiuseacarousel.com/. We’ve told them how they suck. We’ve pointed out the security issues with them. We’ve shouted about how putting an ad in the middle stops people from clicking to the end. We’ve brought up mobile issues and lamented their speed issues.

And then there are the times you don’t. There are times, more often than not, where you just go along with the flow. You hear “We need a slider.” and you do it. You just do it. It’s okay. We all did.

While there are reasons to go along with your committee, there are reasons not to. Is a slider worth getting into a fight with people about? Probably not. But what about keyword stuffing? What about the slider that you know has security issues? What about those things you know will kill SEO? Do you say no? Do you stand up and say “This is bad and here’s why.”?

… There You Bloody Well Are, Aren’t You?

Those things you hate on the web? They’re our fault. Nor yours, ours. We don’t fight back when we know things are bad ideas. When we don’t stand up and say “This is not safe” then we are breaking the web. We have no one to blame but ourselves.

It’s hard. It’s very hard to do this. You will fight tooth and nail over stupid small things. You will struggle with people telling you that you don’t know anything. And you will feel that nagging doubt of imposter syndrome.

You’ll also lose sometimes. And that’s okay. The point is not to win all the time, the point is to educate. The point is to stand up and work to make the web better and not fall to the status quo of what you know is wrong. If you do that, if you keep teaching them and educating and explaining, you will chip away at the wrong and make it right.

But if you’re not willing to do any of that, then you’re making everything worse.

What was I actually talking about?

I was complaining about a theme that didn’t allow you to edit the footer. You had to make a child theme to edit the footer, which is fine in and of itself, but it’s not very friendly. It’s a theme with a bazillion bells and whistles to add CSS and change colors, and yet it failed on the most basic of all things. You cannot edit the footer unless you understand the nature of child themes.

There is a developer out there who’s trying to make a plugin that does all this for the user. His code is a nightmare not because he is a bad coder but because he’s working with a piece of shit theme that throws errors with WP_DEBUG and I haven’t even tried Theme Check on it. I’m afraid to.

But he’s out there, trying to make things better for people and I think he needs to stop. He’s working with a theme that isn’t worth it. He’s trying so damn hard to make the web better, but he’s failing because he’s starting from a place where everything is broken to begin with.

Simply put, he’s working to try and shine shit.

Don’t help people use things that are broken. Fix them the right way. Fix the theme or, if they won’t fix it, stop using it and stop recommending it. It’s not worth your effort if they know what’s right and they won’t do it.

There they bloody well are. Aren’t they?

8 June, 2015
How Hackers Find You

I made a bold statement that pissed someone off. I told him that hackers don’t use Google to find vulnerable sites and attack them.

They don’t, you know. Sure, they can do that, and I’m certain some of them run scripts to collect a list of people to hit up, but that’s incredibly inefficient. The only kinds of people who do that, who get lists of websites to touch, are people who for good reasons need to do that. Like maybe running a script to ping all your domains and trigger a WordPress automatic update by kicking off cron. And sure, a hacker could use a tool like WPScan to collect all the awesome information. But they don’t.

But like I said, doing that is inefficient. The longer it takes a hacker to find you, attack you, and break you, the more likely it is that you’ll be upgraded. With WordPress in specific, the moment that hacker hits your site, your WP install has probably already begun the upgrade to make you more secure. Assuming that, what a hacker wants, what they need, is to hit you once, hit you right, and hit you hard.

What a hacker really does is use that annoying BotNet to distribute an attack on as many websites as possible in one blast.

Do All Hackers Do This?

I should clarify something. When I say ‘hackers’ I don’t mean a specific person who is out to get you, in particular, and wants to destroy your site. Those attacks take as much tech smarts as they do social engineering. When I talk about hackers who are taking down sites, I mean the ones who know about a plugin or theme or core exploit to your site and are going to en masse blast the hell out of the internet to take ’em all down or leave their backdoors for whatever they do with these sites. Perhaps I should call them script kiddies, since many are.

Why Do Hackers Do This?

I have no idea.

It used to be we hacked sites to prove we could. Then we hacked them to get in and get information we wanted. Then … somewhere along the line we started to hack to deface and leave viagra links. I don’t know what ‘good’ the hackers get out of the end result. It doesn’t make sense to me, but then again, I don’t understand why people buy most ‘as seen on TV’ things.

How Do Hackers Find Your Site?

One (kind of cool) thing they can do is, once they find one site, using a tool like SameIP to collect a list of everyone else on the server. That’s great for attacking people who are on shared hosts because they all have the same IP. And once they have your domain on their own list, they keep it and will hit you forever.

But what if they just want a list of all 23% of the internet running WordPress? It’s not that hard. BuiltWith, for example, has a list of many of the WordPress sites.

Certainly it’s not that hard to do. There used to be a site called Hacker Target that had a list of all WP sites: https://hackertarget.com/100k-top-wordpress-powered-sites/ The URL doesn’t work anymore but the idea is there. One could take such a list and just attack it.

Similarly, if you happen to be on an insecure server, one could hack the server and from there collect a list of all domains (since the server has to know it’s domains) and, in the case of a very insecure server, get all the domains on the network, and attack all of those. The shell commands aren’t all that terrible.

The point is, both of those methods are far, far, faster than just grabbing a google for ‘this plugin’ or even ‘this error.’

How Do Hackers Find Out What You’re Running?

This is where people step in and say “WordPress shouldn’t announce it’s version to the masses!” It should, because of what I say the next section (see “Do Hackers Care What You’re Running?”), but the short is that your site content tells them. They can run scrapers to pull your site data, the layout, the way files are stored, and they can tell. It’s like figuring out what car you’re driving.

In fact… Think about that for a second. What kind of car are you driving? Does having the car logo on the car make it more or less secure? It may, if there’s a specific ‘hack’ for your car, but the trained professionals will still know, even if you pull off the logos, so in the end, you’re not really protecting yourself.

Do Hackers Care What You’re Running?

No, they don’t. Sorry. They don’t. Once a hacker has a list of websites, they don’t care if you run WordPress or Drupal or Joomla or Ghost. They’re going to attack with what they know is vulnerable and keep at it until they have a success. Then they take that success and leverage it to get to the next site. And on and on.

So when you get hit by 100 bot-net computers, being tagged for timthumb when you don’t even have it installed, that’s what’s going on. They do not care what you’re running.

How can you protect yourself?

Use a good host who cares about security. Use up to date versions of all web tools and their extensions. Follow those tools and get updates regularly as to any security issues with them.

WordPress is not “Set it an forget it.” You have to keep paying attention.

3 June, 2015
Mailbag: Network Shared Media
Doug asks:

On the WP Forums (at https://wordpress.org/support/topic/multisite-with-one-media-library) you posted this comment:

Ipstenu (Mika Epstein) Half-Elf Support Rogue, Volunteer Forum Mod & Plugin Referee Posted 1 year ago # http://wordpress.org/plugins/network-shared-media/ Keep in mind, this is generally something that kills your site’s performance.

Unfortunately, the thread is closed so I can’t ask you to elaborate through the forum. So can you elaborate via email reply on exactly where or how the “performance is killed” as a result of installing & activating the `Network Shared Media` plug-in? Thank you, -Doug

The problem is that WordPress Multisite was built to be multiple separate sites. You used one install of WordPress, one install of all your themes and plugins, and one ‘user base,’ but outside of that, the sites are all separate. Which plugin is active is different, which theme is used is different, and most importantly your data is segregated.

Your data includes your media.

The concept of ‘sharing media’ is a great one. If you have a network, you would want to have a way to share all common media in a way that every site can call it and insert it. But the way most plugins (including the one mentioned above) go about it is by doing sql queries:
```
$blogs = $wpdb->get_results( $wpdb->prepare("SELECT blog_id, domain, path FROM $wpdb->blogs WHERE site_id = %d AND public = '1' AND archived = '0' AND spam = '0' AND deleted = '0' ORDER BY registered DESC", $wpdb->siteid), ARRAY_A );
```
The code, in and of itself, isn’t bad, but that’s just to get a list of sites on the network. Then you have to check if each user has access to upload files to the site. Then you have to use switch_to_blog to go to each site and load the images.

What happens if you have a lot of sites and a lot of images?

Your site is slow.

We’ve made a lot of improvements on that end, but extensive DB queries when you have to cross paths like that can be ‘expensive’ on a computational level. Not to mention those large DB queries can cause headaches if you use database caching. All that data has to be generated and cached on every load. That too will slow your server down.

Now this won’t always make your site slow, but if you use it and you end up with a slow site, I’m not surprised.

The next logical question, of course, is do I have suggestions or alternatives? I don’t. I actually do suggest people use that plugin if they need shared media. Or I suggest they don’t use Multisite.
29 May, 2015
Multiple Languages, Multiple Approaches

I was contemplating WordPress and how it handles multiple languages recently. There are really two main aspects of multilingual sites. There’s multiple languages for the reader (the visitor) and there’s multiple languages for the admin. The two may not be in sync.

For the Admin

This has always been a little tricky. Assuming all projects have the same number of available language packs, you get two primary methods of translating the admin section.

First is the site is set for a language. That means the owner of the website decides “This site will be English, have a nice day.”

The other option is to have the setting be per user, so a user goes to their settings page and says “I speak French.” Obviously the main site setting (see above) will be where they start from, and this can be a little weird to find on some apps.

The per-user setting is the most common, though it gets rather complex when you consider things like a WordPress multisite network. What if I want to make a site for the French and edit it in English? In MediaWiki too, this is an issue. I can only edit French WikiPedia in French. Initially. I can go in and change it per site, but there’s no global ‘default my account to English.’ Which is right? In the case of WikiPedia, it would be sensible to default me to the language on the site where I first make my account. If I sign up via fr.wikipedia.org, I should default to French.

For the Front End

If you only need one language, this is pretty easy. Pick the language for the site, write in it, and you’re done. For most Americans, this is ‘standard.’ But what happens when you need multiple languages on the front end? For the most part, things have to be either intended from the start or something you add in later. And both have drawbacks.

WikiPedia, for example, has two methods. First they have a site for each language that cross links back to other languages:

They do this via Interlanguage Links, but also via an extension called Translate which allows groups of people to translate.

ZenPhoto uses serialized data. When you edit your content, you can add in the descriptions for it in each language. This has pros and cons. Weird things happen if the CMS ever forgets what language you’re using (an issue I actually did have for a while).

When we look at WordPress, it tends to use plugins. Currently I’ve been recommending Bogo for translations. The other options are to make a Multisite and have each language be a site, but without the Interlanguage Links features of MediaWiki, cross-linking people back and forth based on language can be complicated.

Another options?

I’m not as versed in translations as I should be. Are you? I’d love to hear how you (and your projects) handle multiple languages for both admins and visitors.

27 May, 2015