Tag: essay

Don’t You Give That Girl a Gun

His WordPress site was hacked.

He’d reported it as a ‘slow site’ and the techs had done an amazing job helping him clean it up, but when it landed in my lap, I took one look at saw backdoors, permissions issues, and vulnerabilities galore. So I did the reasonable, responsible, fair thing. I reinstalled the files, I cleaned up the plugins, and then I saw his theme was behind a paywall, old, and, worse, no longer supported. So I removed the theme from his website (putting it where he could get it back) and switched him to Twenty Fourteen. Then I explained in a rather long email about how his site was hacked, how I determined it, and what he needed to do to get the theme back (basically download it again from the vendor).

He was mad.

He argued that I had broken his site and it no longer looked right. This was true. He complained that my service was deplorable because his site looked wrong. This is debatable. He groused that I had to put the theme back. This was not going to happen.

It’s the service conundrum. If you know something’s wrong, do you leave it alone or do you fix it? When I see people post their passwords in public places, I delete them and use bold and italics to chastise them. When I see people doing dangerous things like editing core, I do the same. I try really hard to educate and warn people, so they can be protected from shooting their own foot off. So when I have a rabid customer telling me I need to let them do it … I don’t.

My job is really to help people fix their sites, and that tends to mean my job is to debug and educate and provide options. But when someone has an abjectly wrong bit of code, like the bevy of people who had their old themes and plugins break when we upgraded them from PHP 5.2 to 5.4, I will regularly go that extra mile and fix the code. That doesn’t mean I don’t educate them, they usually get a quick lecture about why we upgrade promptly, but when someone’s that far off normal that their code won’t work on PHP 5.3, I assume they just don’t know anything.

The worst part about it, though, is when they argue. They’ve asked you for help and advice, you provide it, they demand you fix it, and at a certain point… they’re just asking the wrong person. Your webhost is not your consultant. While many times we can and will fix the site, when it gets down to code that isn’t working, we can’t be expected to re-write all the code.

Sometimes we’re going to be the bearers of bad news. Your theme is hacked. Your plugin is vulnerable. Your code won’t work on this server because of reasons. We’re never making an excuse, but we are trying to explain to you why things happen.

Now I know I’m a little weird, because I think that everyone should be educated in how their site works. Not that I think they need to learn to code, but to understand what’s going on, in broad terms, means you’ll be able to help us help you fix your site. And with that, I expect people to actually listen to what the support techs say. We won’t always be right, especially not with WordPress which has infinite combinations of plugins and themes (it’s a mathematical impossibility to be able to be familiar with everything) but for the most part, we are all trying to learn to be better and faster at debugging.

But. What do you do when the person you’re trying to help insists on hurting themselves? Like the person with the hacked theme, maybe you’re lucky and your company has a policy that once you know something is malware, you’re legally not permitted to reinstall it. But what if they decide to use a plugin that has a maybe backdoor, like an older version of TimThumb? How big a deal is that? Is it better or worse than helping someone do something that will absolutely kill their SEO?

For me, it’s pretty simple. My company does have a no-malware policy, and I can fall back on that. When I volunteer, I often tell people “I will not assist you in doing something I don’t feel is right.” and I walk away. Because I feel strongly that I should educate you, but also that I should never enable you to hurt your site.

6 August, 2014
How Many Plugins Is Too Many?

Have you ever played “Name That Tune”? They used to have this show where they’d play music and you had to name that tune. One of the mini-games in the show was called “Bid-A-Note” where the host read a clue and the contestants would alternate bidding. “I can name that tune in X notes..” where X was a whole number, and the bids ended when one of the contestants challenged the other to “Name That Tune” (or if someone bid one or zero notes).

Well. I can crash a WordPress site with one plugin.

When people ask why their site is slow, sometimes my coworkers will say “It’s the plugins, right? He has 40 plugins!” and I’ll say “Maybe.” Then I look at what the plugins are, because it’s never the number of plugins, but their quality. Take a look at Jetpack, which is 33 plugins in one. Is that going to cause more or less overhead than if you had 33 separate plugins installed?

WordPress is wonderful and beautiful because you can use plugins to do absolutely anything. At the same time, that beauty is it’s downfall, because you can use plugins to do anything. There are over 32,000 active plugins in the WordPress plugin repository. There are probably 4000 or so that are delisted or disabled. There are around 3000 more plugins on just one popular WordPress theme and plugin site. We haven’t even started listing themes.

It’s a mathematical impossibility to test every possible plugin combination with every theme on every server on every host with every extra (like mod_pagespeed or CloudFlare) added on. It’s impractical to expect every combination to play nicely together, not because of any defectiveness in the code of the plugin or WordPress, but because of the reality that all of those things vary from place to place. We build out things to be flexible, after all.

I love the flexibility. I think it’s awesome. But at the same time, I worry about it when people complain their site is slow. There’s, very rarely, one perfect answer. Not even “Oh, he was hacked” is the answer to why a site is slow, though it can be. The answer is invariably in the combinations and permutations of what someone has done with their site, what the visitors do with it, and how they interact. A site that posts once a week is different than one that posts four times a day. A site with no comments is different than one with 30 per post. And the more of those little differences you factor in, the harder it gets to determine how many plugins is too much.

Maybe it’s your memory. One plugin may need more memory than another, but the combination of two may need more than either would individually! Sadly, it’s not something you’re going to know until you start studying your own site. There are cool tools like P3 Profiler which do a great job of giving you an idea as to what’s going on, but it’s not the whole picture. It can’t be. Just look at all the tools we list for performance testing and consider how many and varied the results are.

How many plugins are too many? However many it takes to kill your site.

Oh, the one plugin I can run to crash a site? It was BuddyPress and I was using PHP CGI. Once I changed it to a different flavor of PHP, the issue went away.

1 August, 2014
Just Push Publish

“Real artists ship.” — Steve Jobs, 1983

I don’t write good all the time. I’m a little lazy and spell poorly, I don’t proofread enough, and if I had a genie to grant me a wish, one would be for an editor who I wasn’t related or married to. When I post a new article, I often see typos and while I do go back and fix them, I still push publish (or schedule), knowing things aren’t perfect.

This is a major departure from the “traditional” way of writing, when you write, have it reviewed, edit, re-write, re-edit, and so on. To many people, this is seen as ‘lazy’ writing, where we toss out things that are ‘good enough’ and call it a day, but the reality is that publishing promptly, be it writing or code, is what keeps up with the fast changing pace of news, information, and needs. But when it comes to writing, it falls a little bit under the aegis of “If you build it, they will come.” Or rather, if you don’t build it, they won’t come at all.

Publish or Perish

Well known to academia is the concept that if you don’t constantly publish works to sustain your career, you won’t have a career. The added pressure is that you have to publish fast so your information isn’t out of date before it hits the ground. The idea is that if you’re not publishing something then you’re not producing something, and you’re thereby sitting on your laurels. In software and blogging, this is actually important too! If you’re not producing code, or writing about it, you’re not demonstrating what you’ve learned. If you release code or write on your blog once a year, people will forget about you.

Release and Iterate

Also known as “Release early, release often,” this model of development makes important the concept of early and frequent releases. This necessitates people test, though, and developers respond quickly to issues reported by users. WordPress works by this model. Reid Hoffman, the founder of LinkedIn, said “If you are not embarrassed by the first version of your product, you’ve launched too late.” And if you look at many of the recent technological innovations (including the iPhone), version one was okay, but not great, and had a lot of bugs and annoyances.

Fear, Uncertainty, Doubt

The biggest hold up to most of us pushing that publish button is FUD. What if we’re wrong? What if we’re saying things no one cares about? What if… We don’t want to be horribly embarrassed by that typo where we get their/they’re/there wrong, or worse, where we get all that technical information wrong. And it’s that place of fear, that home of uncertainty, that realm of doubt, that we stop. We don’t share what we know, we don’t explain what we think, and we turtle up.

Democratizing Publishing

The mission of the WordPress open source project is to democratize publishing through Open Source, GPL, software. By letting any of us write what we want, we’re able to publish at will. That anyone can upload a book to Kindle or Apple and sell their works has changed the world. In many ways, it’s lowered the bar so anyone can sell anything which causes a dearth of quality. And yet, the stamp of quality products has never rested solely in the hands of ‘official’ publishers. Some of the best music we heard was from underground tapes made in basements. Some of the best stories we read were mimeographed in purple ink and handed out on the QT at fan conventions. All we’ve done here is take the barriers away and given you the freedom to say what’s on your mind.

Write the Change You Want to See

It takes bravery to post your thoughts, technical or personal, out there. You should only put out work you can stand behind, you should put the best work you can do out there, but you should be willing to post. You should be willing to release that code. You won’t grow, you can’t grow, if you don’t step up and put yourself out there.

Don’t worry. We know you’ll fix it.

30 July, 2014
La Vitesse 2: Cruise Control

Now you know all about caching and how it works. But what about speeding up the server itself?

Near the end of the previous post, I mentioned that all the caching in the world didn’t really speed up the server. This is somewhat of a lie, since if, say, you’re using Varnish to cache your site, then your visitors won’t be hitting your WordPress install, speeding it up for you to do work. But it’s not the full picture.

WordPress is big and it’s getting bigger and more complex and more impressive. So is Drupal and … well pretty much everything else. In order to make your site do more, like all that super fancy layout transformations, we have to upgrade and innovate. But then you start getting into extending these apps, like using custom fields and extra meta values to store more information so you can change search results in more impressive ways! Your site scrolls and changes backgrounds! Your site dynamically changes what products are available based on check boxes, without reloading!

What did that have to do with caching? Well … how do you cache things that aren’t static?

My coworker, Mike, likes to talk about things that should be cached and things that should never be cached. Things that have to be dynamic and run without a page refresh, like ajax and javascript, can be cached to an extent, since those plugins and Varnish will just keep the code in-line, which means it’ll still run. But when you start looking at dynamic things like shopping carts, we hit a new world and a new wall. But I’m not even talking about that level of caching. I’m talking about going back a layer into the part where WordPress (or any app) has PHP query the database. If we speed that up, caching safe content, can’t we speed things up? You bet we can!

A few years ago I talked about APC and how I was using it to speed up PHP by having it cache things. Then less than a year later, I switched to Zend and memcached. I did those things because I decided that it would be better to have my server, a workhorse, do the hard work instead of asking WordPress to do it. And this was, in general, a pretty good idea.

Memcached is an add-on for your server, and acts as “an in-memory key-value store for small chunks of arbitrary data (strings, objects) from results of database calls, API calls, or page rendering.” In English? It remembers what you did and can retrieve results faster because of it. Of course, you have to tell your apps to play well with it, but once you do, the backend of your site starts to speed up because, hey, caching! The Illustrated Memcache’d story is kind of an awesome explanation (the images on the archive page are broken, but the links work). And yes, I do use memcached and ZendOptomizer+ on my server, because it really does make things faster, even when two of the ten domains are having a 10k pageviews in a day.

I keep telling everyone my server isn’t overkill….

The point of that, though is the other end of speed is totally separate from your application code. When you install WordPress, you know it runs SQL and PHP, so if you can make those faster, WordPress will be faster. The same applies to speeding up Apache, maybe by putting Nginx in front of it, or maybe by tuning the hard to understand settings in httpd.conf to make sure that it elegantly handles the 300 people who come running to your site at once.

But unlike plugins, this aspect of server speed is the hard stuff. When you look at WP Super Cache, you think it’s complicated until you see W3 Total Cache. Both are amazing and awesome, but they’re giving you a ton of options and asking you to make decisions. The same is true of the servers, but now you have even more options. The world is your oyster, and we haven’t even looked at hardware.

For me, it boils down to how can I make my server do it’s job fast and efficiently. If that means I hire someone to install software to cache better, or I pay for more memory, then that’s what I do. I also trim the fat and get ride of everything I’m not using and don’t need, so my server doesn’t have to do more than it needs to. And one day, one day, I’ll be looking at nginx for everything.

23 July, 2014
La Vitesse

A little bit ago I talked about Varnish, how to install and configure it, and why I’m not using it at the moment. The actual goal of all this stuff is to speed up a website. Site speed is an insanely fickle beast, and measuring it without going insane is nigh impossible.

When we talk about site speed we don’t just mean how fast the site loads. We mean how well it performs on the front and back. Does it load everything it needs to be a page in a non-jumpy way? Does it load and then magically change to another format because you’re on an iPad? Does it hang and then load? We mean all those aspects that go into a site and make it zippy.

Which brings us to caching. The goal of caching is blindingly simple: Don’t put extra load on the server while serving up webpages and make it faster. The how of caching is crazy.

When I talked about Multisite Caching, I brought up the different types and why and where I saw each one being used. But I didn’t really explain why very well. In order to understand it, you need to understand why we need to cache.

If your website was all plain, static, HTML files, it would be really fast. The web was (initially) built for that stuff and it was all basic. “I want this page.” And the server would reply “Okay, here it is and some images.” When we start adding in stuff like dynamic PHP (WordPress), we put more load on the server because for every time someone visits your site, it has to ask WordPress “Do you have this page?” and WordPress has to check, see if it does, generate the output, and then it loads. The more complex the site is, the more big images and javascript fancy stuff, the slower the site gets.

Logical stuff, right? You’re also going to be limited by how fast your server is and how much of it you can use. If you’re on a dedicated server, the limit is your hardware and bandwidth pipe. If you’re on shared, though, the limit is lower, and really varied and complicated. While I mention a ‘bandwidth pipe’ and we techs always joke about the sturdy internet tubes, it’s not a fully accurate analogy, and even with all the bandwidth available in the world, the speed of your server is going to limit you far more.

There’s a phenomena called the “noisy neighbor” which impacts people on shared hosts a lot and is a lot of why people get confused about the bandwidth thing. You see, if you’re on shared servers, you share services. If one of your neighbors uses a lot of memory, there’s less available for you. This makes perfect sense, and hosts combat this by limiting how much you can do. I know a lot of companies say that you have ‘unlimited’ space and bandwidth, and while that’s true, it doesn’t mean you get to use all the power available to the server. Basically on shared servers, when you see ‘unlimited’ you should read it as ‘unlimited until you start making other people’s sites run worse.’

What does this have to do with caching? It’s the reason why we cache! WordPress does not make static HTML pages at all. If you look on your server for a file named ‘about’ you won’t find one. Instead, WordPress uses the .htaccess file to magically run your request for example.com/about/ through the index.php file, which then checks the database and pulls the content for that page. It’s entirely dynamic, and every single page request is run through the database. And yeah, that gets slow over time. The dynamism is fantastic though, and that’s why things like comments magically update the rendered page right away.

Thus, in order to make our super dynamic websites run by WordPress run faster, we turn to methods to generate static file caches. Converting a WordPress page from the PHP queries to a static file is complicated, and in essence every single tool has to generate that dynamic page, copy the output, and save it to a location where it can be pulled from directly. At the same time, it has to alter the server in some way to say “If I have a static file, use that instead.” When you use a plugin, generally it does this via your .htaccess file.

The obvious problem with this is that while the page may be faster for visitors, you’re still putting load on your server by having it generate these html files and serve them. And you, the logged in user, won’t get the cached page, generally, not even with something as cool as Varnish, so we have to still consider the rest of the server.

Speaking of Varnish … the simplest explanation I can give you about it is this: Instead of having WordPress use a plugin to generate the page, Varnish lets WordPress load, takes a snapshot of the resulting page, and saves it somewhere else. That means that in-between your visitor and the WordPress install is the Varnish cached page, which means the load is off your server more! No more loading the html page, Varnish is going to do it and make it a little faster. You’ll still want a plugin to allow WordPress to tell Varnish to delete pages, but it can significantly run faster.

But … what about the server speed itself? Is there a way to cache that and speed it up to? There is! But that’s a longer post, all it’s own.

21 July, 2014
When Sites Go Down

My webhost had a bad day. They ran a regular, normal, upgrade to some switches and a switch failed. It decided it would be fun to reboot over and over. Since running on one switch is rather dangerous, they decided to roll back so we could have two and everything would be okay. It didn’t work. In fact, nothing worked. It was one of those days where you put out a fire only to have an earthquake, and as soon as you got the place cleaned up there was a flood. And then the sprinklers thought they should go off.

We have, every last one of is, had a day like that. A day where absolutely everything went wrong when it was possible to do so. It was clearly one of those days.

I can certainly complain that my host wasn’t really the best when it came to explaining things, too. They would send us emails, which was fine, except my emails were on my server which was inaccessible to me. So many people went to their live-chat that it was impossible to get a rep. Tweets? Unanswerable due to volume. They actually replied by (heh) email. And when I went to their management panel on their website, it just said that it would be updated in ‘an hour.’

I resorted to opening a ticket. And I hated doing it, since I knew better than many exactly how shitty their say was. So I asked “Status Update?” and explained that I was unable to check my email but what was the status? I got the form replies, which I expected, and I pushed back for one detail. Just one:

“It is our aim to have this completed within the next hour by proceeding with this fix immediately.”

Hour from when?

Suggestion for your website: Can you timestamp things so we know when to kind of expect things?

By the end of that day, they had a static.html page with the information, and times(!), on it. They’re not ‘great’ at keeping it updated, but I know how annoying that aspect is, and I don’t fault them one bit. Once the work was done and everything was back to normal, I inquired as to the offered credit, which actually I’d forgotten about but they had mentioned to me in the support ticket! I think it works out to being about $4, clearly not very much, and honestly I don’t care about it very much.

A thought that never crossed my mind? Leaving them.

It’s not because my server’s been there for over a decade, and it’s not because I like the more and more ‘grown up’ corporate tone of their communications. It’s certainly not that I agree with everything they do. But what I do agree with is that I pay them for a service and, for the most part, I get it. When I don’t, after the dust settles, they’re as responsive as every other host.

I’m not paying them just for server space, after all. I pay for backups, some cloud services, and most of all, I’m paying them for help when I screw up. Not to be my consultants, certainly, but I do pay them for technical support and advice like “Can you tell me how to install Ruby on my server?” because there’s no KB article … yet. Also when I needed help tuning httpd.conf they helped out. They don’t do the work for me, they do their limit, and they’re generally friendly about it.

So how bad does an incident have to be to make me leave it?

I’ve only ever left a host when they didn’t offer the services I needed (SQL, PHP 5, so on and so forth). If I was paying less for a bare-bones host, I’d have to pay someone to help me with server stuff anyway, so for me the all-in-one matters.

As for outages, I’m pretty relaxed about it, At an hour of downtime, I pay attention. I had a total of about 4 hours over the course of a day, which is annoying, and bad, but not horrible because no content was lost, just traffic. It’s not that my website isn’t my life, it’s that I’m realistic about situations. If the host explains what happened and are working on fix it as fast as is reasonably possible, I’ll suffer up to 6 straight hours before getting really upset. I’ve never had an outage of more than 75 minutes in a row, though, and before this one, I never had one more than 45. So yes, this was the worst outage I’ve ever had with them (that wasn’t my fault).

Other incidents that may make me leave would be a deletion of my server without warning. That, hands down, is time to go. Any service promise that isn’t regularly met is grounds for a chat about expectations. I don’t count ‘support response time’ as a service promise, mind you, since when shit gets bad, that’s always going to drop. I mean things like backups or uptime. I’ve never been one to care about 99% uptime, but if the server’s always crashing no matter what I do, and they’re not willing to help me, then I have a problem. In general, I feel that if my site in particular is having issues, it’s probably me and my snowflake more than them. If all sites have the same problem, then it’s probably our needs don’t match the host services.

The funny thing is I don’t know of many hosts that fits that bill. Sometimes a host has to tell you no, they can’t offer a service, and sometimes they tell you that you’ll have to pay more to do something. But in general, most hosts want to keep you, they want to help you, and they sometimes have to be the bearer of bad news. I’ve actually met hosts who have told me “We won’t be able to provide you the quality of uptime you need due to the way your site is being accessed.” That was a fancy way to say “You get too much traffic for our small node to handle.” And then they handed me a discount for another host. Another Host. This small host was bought out years ago, but I will always remember Greg for that moment. He was awesome.

My point is that it’s not my host’s job to manage my website, so if I let the spam on my site go wild and it causes my server to crash, well that was my fault. Not theirs. Don’t like the way my plugins make my site work? That’s on me. And if they tell me “You’re getting hit by Reddit, we need to increase your CPU/memory to handle it, and that will cost you more money” I know they’re not just upselling me.

There are some hosts, sure, out to make a buck, but in general I find that if they know that I understand our relationship, things go well.

This isn’t meant to be a love song to any one host. None of them are perfect, and they all have weird quirks. This is a love song about remembering my relationship with my host, respecting that, and holding up my end of the deal. I’m not naming any host names (even though it would take you about 2 seconds to sort out who mine is, and who I work for, and yes, I’m ecstatic about both), because it doesn’t matter. I’ve had an experience like this with hosts that are maligned and vilified. My choice not to use them is not based on quality of service but on my morals and ethics. I chose not to fund people I am diametrically opposed to, for my own peace of mind.

But I find, for the most part, that when I make it clear I know how our relationship works, and better yet, I know how their job works, I get both the support I want and the results I expect. It’s funny how that goes. They keep my faith and I keep trusting them.

9 July, 2014