Category: How It Is

Making philosophy about the why behind technical things.

Network Rules

I love Multisite. I don’t think people use it ‘right’ but I love it. So I’ve started to make my own rules about Multisite and how to use it properly.

Only One SuperAdmin

There should be only one SuperAdmin, and you should never use that account to post. This will limit what you can do on any given day, and you’ll need a second account to mess with network settings, but this is a good thing. While WordPress lacks a sudo feature (yes, I know there are plugins), having only one SuperAdmin and locking that account tight and keeping the keys to yourself limits people’s ability to be mean to you and brute force. Extra points if you name the account something random.

Restrict Access

Only give people access to what they need. This means you limit their plugins to what they have to have, ditto themes, and you don’t let them argue they need the unicorn.

You knew I’d pull that one out, right?

Be mean and say no. Don’t let someone be an admin of a hundred sites if they only need to be admin of one. Don’t let them be members of sites they don’t need to write on. Remember, Multisite makes you a pseudo-subscriber so a user will be able to read and comment on all sites on your network. They only need to be a legit member if there’s a real reason, like it’s a locked site.

Don’t Network Activate Things

Perhaps this is better said as follows: Only network activate things that must be network activated.

Is it ‘easier’ to network activate W3TC and configure it for your network? Sure! Should you? Probably. But what about Jetpack? Does everyone need it? Do they all need the tool for GUI comments when not all the sites even use comments? Be judicious and cautious when you network activate plugins.

Test All The Things

Vet your plugins and themes before you install them. Test your upgrades on a non-production site. I cannot stress this enough. Test, test, test, test! Test! Just … test okay?

What are your rules?

I asked on Twitter and Tim Moore said he turns off the plugin menus for subsites. You can do this very easily by going to Network Admin -> Settings -> Network Settings and uncheck the plugins box for “Enable administration menus.” I do sort of wish we had more things there, like disable themes and so on, but seeing as you can more granularly control themes anyway it doesn’t matter that much.

5 September, 2014
Mailbag: Translations
The second hardest thing about translations is trusting the translator.

I sometimes joke that I barely speak English, so when someone said he translated my entire ebook about Multisite into French, I was delighted and scared. While I do kind of understand French, I’m not qualified to translate it, so having someone else do it would be a fantastic offering. But since I can’t translate it, I have no way of knowing how to gauge if they understood my meaning, which is hard enough to figure out in English.

After a while, I decided to tell him that I’d like to see them, but I wasn’t sure if I’d want to put them up online to sell or give away. Of course he was welcome to give them away all he wanted!

The problem isn’t that I trust him, or not, but that I don’t have a failsafe. With coding, I have coworkers who can spot check me. With blog posts I could use an editor, and it’s the same with books. If this was a contracted book, I’d be able to let my publisher find someone we all agree fits the bill. When you’re on your own, it’s a lot harder.

The same goes with my plugins. I don’t actually package anything in my plugins by way of translations. The closest I have is my Varnish Plugin, which has a folder on github for people to store translations. Since they don’t have to be included in core, it’s easy enough for me to say “Use at your own risk.”

With code, there’s a lot more you have to do in order to make your code translatable though. With my books, I just write. With my code, I have to remember to escape properly. Which I nearly never get correct the first time out. With code, you have to remember from the start to write your words in a way that can be translated, and you have to worry every time you change things that it will be broken for everyone on the next update.

It’s chaining, really, to realize I can’t just ‘write’ in my plugin like I do on my blog.

So what’s the question and the answer? Should you translate your work? Maybe. You should always make it translatable, but whether or not you should manage the translations is a really strange question without a perfect answer. Unless you’re fluent in two languages.

I keep the following links bookmarked, just to keep me on track when I start editing any plugin, and I try to work backwards to fix all my old ones, but it’s really slippery.
15 August, 2014
Getting Good Advice

She was running a webstore on shared hosting without caching, and was upset it was slow. She was using only free products, no HTTPS, and was annoyed people said they couldn’t buy from her and that she could only use PayPal. She was angry that we couldn’t magically fix it.

I sped up her site, improved PHP, and cleaned up some duplicate plugins. And then I asked “Have you considered a VPS?” She ranted that it was our job to make shared hosting better, even if it cost us more, because she certainly wasn’t going to invest in her business. So I complained, on Twitter, that people who use free/ultra-low-budget services for a business and are unhappy with performance get what they deserve.

Then my buddy joked that Danica Patrick said it worked for $0.99! I joked back that he was taking web hosting advice from someone who’s selling skill is “I drive real fast!” As we tweeted, we elaborated it to how silly it was to take hosting advice from someone whose job it was to look pretty, drive fast, and only turn to the left.

It’s funny to us because we know better. If I was going to ask Danica Patrick for advice, I would ask her how she managed to sell her image so effectively. I might ask her if I could learn to drive a race car from her. But asking her what the best setup was for running an ecommerce store? Hell to the no! It’s outside her expertise and I’d be a fool for asking her in the first place!

Which brings me to my point. The advice you get is only as good as the people you get it from.

That’s painfully obvious, right? To go old school on you, you shouldn’t ask the fish guy for advice about pork, you don’t ask the vegetarian for advice about lamb, and for goodness sake, you don’t use the marketing sales pitch as your only measure for what kind of host you need.

Sorry, marketing guys.

Way back in the beyond days of websites, when we all used pure HTML and loved it, I was starting up a fansite. I had an idea that it might be moderately popular, so I reached out and asked some people who ran similar sites. I told them what I wanted to do, and asked who their webhost was, what ‘tier’ of hosting did they use, and were they happy? A wonderful woman named MadDog (I miss her so) was insanely helpful and sent me a breakdown of how much traffic she got, what her spikes were (our actresses were on the same TV show, this was helpful), how crazy the fans got, and then handed me a coupon for her host. “Use it or don’t use it. I get about $50 if you do.” (Spoiler alert: I did.)

When I was looking at getting DSL back in 1999, I asked other people in my building who they used, why, and were they happy. Surprisingly a lot of people hated their ISP except one guy, Quinn, who told me what he used it for, why he paid as much as he did, and how it was worth his money. And he too said if I used his code, he’d get $50. Actually I think he got $150 and took me and my wife out to dinner.

The point is this. I sought out people with a similar experience as I was expecting to have, such as living in the same building. I asked them how they used it, so I could see if their issues would be the same as mine. I asked them if they were happy, because I knew I’d been calling support at least once, and it would be nice to know how painful it would be. I did my research, myself, because it mattered to me.

Your site matters to you. It behooves you to sit down, take stock in your goals, and research the options out there. We can’t always know where we’ll end up or how we’ll get there, but we can make the effort to find people who match our perceived direction and ask them a simple question. We can search for our peers and read articles they’ve written. We can ask them for recommendations. And in the moment those people take time to sit and answer your questions, you need to listen to them. You should thank them. You may even want to go out of your way to compensate them. Because they just gave you some amazing value.

Would I host a business on low-end shared hosting? Sure. To start with. But as my business grew, I learned that I had to invest in order to reach my goals.

And yes. I did.

11 August, 2014
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