Author: Ipstenu (Mika Epstein)

The Perception of Security

This post is dedicated to Frederick Townes, who donated to help me get to WCSF. I use his rock ’em sock ’em W3TC plugin on this site, as it happens.

The TSA is a funny thing. They make us go through all these hoops and ladders to make it look like we’re safer. They check us for weapons, they check us for bombs in our shoes, and essentially they check for everything they know about. And we call it ‘Security Theater’ because it actually doesn’t make us one inch safer.(If you’re really interested, go read Bruce Schenier‘s books. The security methods in place pre-9/11 are the ones that have caught the bad guys. None of the new stuff has.)

At work, I have a product from a vendor that has pretty insecure passwords. I can’t make them expire, I can’t make them require special characters. In fact, you can pick a blank password if you want. There’s no security and most people use the same password (123456) because of it. It was up to me to invent something more secure, and I sat and studied the login form for the app. This was a locked down product, so hooks and actions, like we use in web apps, were unknown. But there was a hidden option, down in the bowels of an ini file, that was for ‘advanced username options.’

Unlocking that option gave me rules for usernames, just like you’d think. But how is that going to make things safer? We already used login ids of our initials plus a number, so if I could leverage that somehow, maybe I could do something. My idea was that if the login name was always pre-filled, and uneditable, with the same ID you logged into the computer with, then in order to ‘hack’ into someone’s account, they would either need their LDAP password, or the person would leave their PC unlocked. I thought it was genius, and after some fiddling around, found how to extend the settings to allow that.

Months later, the Auditors come around and say it’s not secure enough. We need to change the passwords more often. Even though the desktop password is the most secure of all passwords we use, and even though leaving your PC unlocked is a fireable offense, they said that since someone could gain access to your PC, the bad password was a problem. I remarked that they had a lot more to worry about in that case, and pointed out the vendor didn’t have a fix. They’re still arguing that one.

The problem is the auditors want to be able to feel safer. They know and understand LDAP security, ergo all things must comply. It is a benchmark of safety which, in many cases, isn’t going to make things safer. If you got my LDAP password, you now have access to everything I log into at work. That isn’t safe at all, is it? It’s a single point of failure.

Recently, someone asked why WordPress doesn’t let you move the wp-admin folder around, and that doing so would be safer. Actually they accused WordPress of being egotistic for not letting you move the folder, and for putting meta info in the source code. But let’s not get into where they’re wrong on that end. Why doesn’t WordPress let you move wp-admin? Certainly they could put the effort into decoupling the various places where it’s hard coded, put in a define you could override, just like we do for wp-content. Then you could move it where ever and you’d be happy. I cannot speak for the developers, but looking at the code (not insurmountable, just annoying), I see it as security theater.

Moving the wp-admin folder simply cannot make your site safer. It just can’t. Look at it logically, you still have to be able to get the folder, ergo people will still be able to figure it out. The rule of the web has always been ‘If it’s on the web, people will take it.’ Normally this applies to pictures and text, but when we extrapolate it to include source code, like for open source code, which is there for the taking, we reach a point where anyone can look at WordPress’s code and determine how to quickly figure out where the admin folder has been moved to. We have now put in extra work for a very teeny tiny benefit, that can easily be circumvented.

But isn’t that benefit worth it? Not when you look at the costs. Computers do what we tell them to, every time, every day, repeatably. When we go in and complicate our code, we introduce more human errors. The more possibility for errors, the more likelihood that we’ve missed something. So by adding in a way to move wp-admin, we run the risk of screwing it up and making things less secure. Would you rather have the brains staring down WordPress and trying to make things actually more secure, like by preventing XSS vulnerabilities, or locking down nonces and cookies, or would you like them to make you feel better?

Furthermore, there are the themes and plugins to consider. Now we have to update all our themes and plugins that are doing_it_wrong() in the first place, and get them to join the new world order of right. Yes, they should have done things right in the first place, but some don’t because the old way still works. What happens when they don’t update? We’ll have to leave some deprecated code in there so the old wp-admin still works and … oh. Well that didn’t do you any good, now, did it?(NB. I’m certain there is a way to do this. I just don’t care enough to verify it, as you’ll see in a moment.)

This has everything to do with the fact that open source software is open source, and ‘hiding’ anything means it’s always going to be easily reverse un-hidden. Moving wp-admin is called ‘Security by Obscurity’ and it’s a waste of time. It’s just not effectual in the long run, it doesn’t protect anything, and the only time someone knowing my WP version or where it was installed would worry me is if I didn’t upgrade and there was a known hack on the older versions. Even then, Hackers will just try the same attack even if I’m protected (which I know from the TimThumb debacle, where my server was scanned for the file exploit – I don’t use timthumb, but they scanned me all the same).

When you make me draw the line between where I’d want ‘my’ developers spending time, and the options are ‘feel good security’ and ‘make the damn product actually more secure’ … I think you know where I stand.

What about you? What aspects of ‘security’ do you feel are just window dressing?

26 July, 2012
Forever Alone No More
A lot of us work on projects by ourselves. We’re the ones who build a website, alone. We write a plugin, again alone. When we do colaborate with others in the making of our site and codes, it’s often a cumbersome, kludgy, thing at best. The advent of code management systems like SVN and GIT make the actually coding process easier. Now multiple people can make changes, branch and fork, merge and combine to fix all sorts of problems.

But web-development, for your personal site, is still in the dark ages.

Here’s my workfolow:
- Review changes
- Open Coda2
- Edit file
- Preview changes
- Push file
Now that’s a huge improvement since the old days, when I would edit, FTP, and so on. I still use Transmit to run a sync/backup every day before I start editing any files, but that just goes back to my paranoia. It gets harder when you use something like WordPress, because the old days of being able to easily preview your site and how it looks doesn’t exist anymore. That’s part of why the totally incredible Theme Customizer is totally incredible.

It’s also a little problematic if you share a site. Let’s face it, maintaining a website with other people is a pain. When my fellow site-folk want a small change, they can make it, but I have no way to easily roll that back without comparing my personal backup with the new one, and go make a diff. Sure I can do it, but it takes time, and it’s a hassle. A lot of the time, too, my fellow admins aren’t as good at certain things (like CSS, or tables, or PHP) as I am, and I have to bail them out. In and of itself, that’s okay. It’s why they keep me around and fee me brownies, after all.

Have you ever had someone else make a change while you’re on vacation and call you in a panic, even though you’re on Bora Bora and have no internet, because this ‘one small tweak’ to the sidebar caused the site to go white, and they closed their file-editor, so they can’t control-z?

A lot of us cowboy code. I sure do. I’m often banging away on my sites in vi when I want to make a fast CSS change. Clearly sustainable for a professional environment, this is not.

But… What if? What if you had a way to update the code on your site, like your personal mu-plugins or the theme, and make the changes ‘live’ but still have a way to roll back when you accidentally blow it all up?

And what if I told you that a WP dedicated host has an answer. Yeah, WP Engine figured it out.

Upfront disclosure: I don’t use WP Engine. I have a lot of non-WP sites on my servers, and many of my sites aren’t using just WP. I have a VPS and I’m very happy with it. But if you want a good host to run your WordPress site that’s the step between your own VPS and WordPress.com, I strongly recommend them. Yes, it’s more expensive than many other hosts, but I am a firm believer in ‘You get what you pay for.’ With WP Engine you get hosting, upgrades, backups, and support for $30 a month. And now you also get Git. They’ve come up with a Git-push-to-deploy method for their hosting platform.

Did that sound like gobbledygook? Hang on. This actually isn’t something ‘new,’ as the technology’s been around for a while, but this is something new for webhosting and WordPress hosting. WP Engine’s applied it to their servers, making version control possible. It’s like how we’ve always combined version control and staging to make a ‘development platform’ and now you get that in WP.

Okay, if you’re like me, and a total raw rookie at Git, you sat here and went ‘What the hell is this ‘push to deploy’ stuff?’

At it’s heart, push-to-deploy and push-to-live is really a fancy, buzz-wordy way of saying this: I have a git branch that is the dedicated to my site version of my code. If I edit that branch by pushing my changes to it, I have created a version-controlled update of my site, which is beneficial in case you need to roll back a change, or pin-point a specific change.

Okay, maybe that’s still unclear. You’re going to have to take a look at git.wpengine.com to really see how they’re applying the technology. Git, like SVN, is one of those things that makes a lot more sense once you sit down and use it a few times.

Really, my biggest hurdle is always wrapping my head around git’s application of branches and merging and a decentralized database. It’s complex and powerful. Vincent Driessen wrote a brilliant explanation of a successful Git branching model, complete with diagrams, that explains all this way better than I could. His examples will show you exactly what’s going on, and that a ‘push to deploy’ is really just another sneaky way of using git to manage your changes in a controlled way.

Don’t get the wrong idea. There’s nothing wrong with being sneaky to control all this, when you get down to it! It’s the perfect-world a lot of teams have been looking for, for many years. Having this built into your webhost, so you don’t have to come up with your own solution, is going to be amazing for small companies that will, over time, have a slew of developers. Someone new comes along? Hand them your primer on naming conventions and merge rules, let them fetch the repository, and off they go. Everything is right there, as safe as your backups.

I can’t say if this will revolutionize things, but it’s a harbinger of change which web dev has sorely needed.

Check out WP Engine’s Git FAQ (where they explain all the nitty gritty about handling version control, so if you’re a nutjob like me and want to run aortic, you can), or just read their getting started guide. The directions are clear enough for a Git newbie like me to understand.

Unlike Capistrano or RAMP, this hasn’t been released outside of WP Engine, but that makes sense as it’s all homegrown and built to their servers. This should be interesting to watch how other WP (and non WP) managed hosts handle the next wave of support.

Related:
- WP Engine: Announcement
- WPCandy: WP Engine launches seamless integration with git
24 July, 2012
No Children Necessary
This post is dedicated to Michael Fields, who donated to help me get to WCSF. I envy him his Portland.

Not all of my sites use child themes. In fact, most of them don’t. I work on about 20 WordPress sites and of them I have five child themes, one of which is an unedited child from the theme dev. Even when I have custom-post-types, I rarely need to mess with a child theme, unless it’s needing a special template or page design. That means that most of my child themes are a style sheet, a functions file, and one or two new pages. When I do have to make a child theme, I do my best to make it reusable as much as possible. I have the same child theme on two sites, but they look nothing alike.

But generally, when someone tells me they need to edit a theme, I tell them how to make a child theme, which I fully endorse, but also to step back. Do you really need a child theme? See most people make a child theme to customize their site, and since that’s pretty much what they were invented for, it shouldn’t be a bad thing. But sometimes people are using a child theme for the wrong thing and they ignore all the built-in ways to customize a theme.

The only reason you need to use a child theme is when you have to add a new template, or replace one that cannot be hooked into.

That’s it.

Before we get into this, I’m going to point out that if you are using a Theme Framework, this is not for you. A theme framework is something designed for you to build a child theme off of. This post is for people who use TwentyEleven and want to make it a little special, or even a lot special, because most of what you want to do is something in CSS anyway. Yes, I did just say most of what you’re doing with a child theme can be done with CSS. The rest of it can usually be done with widgets, and after that there are some plugins to help you out.

Ready to customize your theme without a child theme? Here we go.

Themes Have Options

It’s 2012, and the majority of themes have options. Some have too many, but pretty much every theme has some options. The default theme has some basic options. People may call them simple, but these options are huge to make your site just a little different. A single column, no sidebar, TwentyEleven is automatically a different feel than the generic sidebar site. It puts the concentration on your content, which is king, and pulls it back to the importance of it. If you’re running a documentation or essay site, that’s what you want. Most themes also have header options, to pick your text, color, and image, as well as background images and colors. The new theme customizer lets you actually do almost all of that in one go, making it even easier.

Remember. All cars have wheels, windows, and doors: it’s how they’re arranged and styled that attract most people.

I know I said I wasn’t going to mention Theme Frameworks, but themes like Genesis, and even ones like Hybrid, often build their themes with powerful options that let you use them without having to make your own functions files. More on how you don’t need that later.

It’s just CSS

Most of what people want to change is CSS. I said it before, I’ll say it again. If you want to change the color of your site, and it’s not included in the theme options, you want to end your CSS. But how, I hear you ask, without a child theme? WordPress.com Custom CSS (aka Safe CSS) will let you edit your site’s CSS without making a child theme. You can’t use all CSS, there are some moz-radius things that don’t seem to work, but other than that, you can totally change up your site.

CSS is more than just colors. CSS can format your text, move your divs, and completely customize your layout, all with just a few lines. Change the one column from a skinny one to a fat one, indent your paragraphs, and add whitespace to your header without any text. Everything can be moved.

Neglect not your menus

Customize your menus. You can add images and styles to your menus, and you should to make them look like anything you want. Yes, this goes back to CSS, but you’d be amazing how many people just leave them alone. First, remember to customize your menu to look like anything except that list of pages. Change it up right away, and then add in design and style to stand out. The menu is supposed to catch your reader’s attention and direct them where you want to go. Don’t slack off.

Widgets, Widgets, Widgets, Widgets, Widgets, Widgets, yeah!

Do not ignore the power of your widgets. Your widgets control your sidebars in most sites, but also your footers. People think of them as just a way to toss in twitter and search. You can use the amazing, incredible Widget Logic to control when and where a widget shows, to make different pages show different information. An alternative, if you’re really good at php, is the impressive PHP Code Widget, which will let you put any PHP in widget and customize it on it’s own.

The most powerful widget in your arsenal, however, is the text widget. Text drives your site in so many ways, a simple text widget can hold any information, from contact information to a haiku. You can put anything in a text widget, HTML, inline CSS, your special code. Text is insanely powerful and you shouldn’t forget it.

Want to use shortcodes in your widgets? We can do that too with two lines of code:
```
add_filter( 'widget_text', 'shortcode_unautop');
add_filter( 'widget_text', 'do_shortcode', 11);
```
Normally this would go in your functions.php in your theme, but hang on, we’ll get to where to put that in a minute.

Conjunction Junction, Don’t Use Functions

Here’s where a lot of people demand they have to use a child theme. They need to add in functions, like the overriding filters and actions in their parent theme. I very, very, rarely use a functions.php file in any child theme, because I hate having to replace them if I ever switch themes. Instead, I make use of mu-plugins.

Generally I end up with three files:
customposttypes.php functions.php themename.php

Obviously, the first one is for my Custom Post Types. They all live there happily. The second is for anything and everything I’d put in that theme function file. It’s important for me to keep the general functions separate from the theme specific ones, however. In fact, while I originally said I made a ‘subchild’ theme for Genesis’ Balance theme, I’m now using the CSS (mentioned above, SafeCSS), and two MU plugins: ipstenu-functions.php and ipstenu-balance.php. That’s right, all my tweaks, everything I did, are there. I’ve done the same for this domain, and all other sites except for photos. Why? Photos has a CPT that needs a custom template.

On subsites of a network, I wrap my mu-plugin with if ( $blog_id == 2 ) { ... } to ensure it only gets called on that subsite. For the theme, $theme_name = get_current_theme(); and if ( $theme_name == 'Origin' ) { ... } within. Be careful, the theme name is the name, not the slug, so ‘Balance Child Theme’ and not ‘balance’ is what you want. Even straight up theme related actions like add_action('genesis_before_footer', 'ipstenu_before_footer'); work without a hitch. That leaves me with (at most) three ‘plugins’ for each site, and usually not even one. If I wanted to be really lazy with Genesis, I could do most of it internal with a plugin to do it on the dashboard instead.

You can do it all without children

Really the point is that of all the children theme possibilities on this network, the only one that exists is the one that needed it’s own special template. I certainly wouldn’t do this for all sites, but once you pull all the theme specific data out of your functions file, there’s often very little left. When you can do this, you retain a little extra flexibility in that your changes are easy to swap out between themes.

At the end of the day, it doesn’t make things easier or harder, just different.

Put all your non-theme-specific changes into a mu-plugin. Put your CPTs into another. See what’s left. You may be surprised.
19 July, 2012
The Dangers of Being Uneducated

This post is dedicated to Rachel Baker, who donated to help me get to WCSF. In lieu of Coke (and a sincere promise of no heckling), thank you, Rachel.

Like many of these posts, it started with a tweet.

Just six months ago, a WordPress plugin named RePress, hosted by all4xs, came on the scene. This is hosted at WordPress.org, see WordPress Plugin – RePress, and at the time it showed up, I was seriously worried about it.

The plugin itself is made of awesome. It’s a proxy service, so if you happen to live in a place where freedom of speech is an unknown quality, you can use your site to serve up pages from other domains and read them, even if they’re blocked. Essentially, instead of going directly to wikipedia.org, you go to yourdomain.com/wikipedia.org, and the content from Wikipedia is requested by your server, not your local IP, so if your ISP is blocking the content, you can still see it. If you’re visual, it’s like this:

This relies on two important pieces to work, however. First, whereever your site is hosted has to have access to where you’re trying to get (that is, if my webhost blocked Wikipedia, this won’t work). Second, you need to know what you’re doing.

It’s that second point that worries me to no end.

Look, I firmly believe in freedom of information. Once something has been invented, people are going to figure it out, so giving it to the world to improve upon it is sensible. Patents are just a weird concept to me. To say ‘I invented a thing, and no one else can invent the same thing, and you can only use the thing as I’ve made it!’ just blows my mind. We need to crowdsource our intelligence, share, and improve. It’s the only way to evolve.

But that’s besides the point. The point is I worry like you don’t know about people being uneducated as to what this plugin does. Regardless of if it’s a good idea or not, it’s a dangerous thing because it has a great deal of power.

I have a slightly selfish reason for worrying about it. I work for a company where using a proxy to get to websites they’ve blocked is grounds for being fired. I’m not the only person who has this concern. The worst part about this is if I went to a site that used a proxy, without telling me, I could get ‘caught’ and fired. Oh sure, I could argue ‘I didn’t know!’ but the fact remains that my job is in jeopardy. This is part of why I hate short-links I can’t trace back. A proxy being ‘right’ or ‘wrong’ doesn’t matter, what matters is the contract I signed that says I will not circumvent the office firewall knowingly. Now I have to be even more careful with every link I click, but the uneducated who don’t know anything about this are at a huge risk.

As Otto would say, we worry about the evil people, the ones who use this proxy to send you to virus infected sites, or places they could hack you. I really don’t worry about them very much. Evil is evil, and people are always going to be malicious. They know what these plugins do and how to use them, so again, my fear is for the uneducated who don’t understand. The people who still open those attachments from usps.com are the people who will be hurt by this. The rest of us will just deal with ‘You work on computers? Mine’s acting funny, can you look at it?’

My main fear is for the people who don’t really understand how the plugin is dangerous to have on their own site. RePress, in order to prove that their plugin worked, hosted a proxy to The Pirate Bay, a popular torrent site. Near the end of June, BREIN told them to remove the proxy to The Pirate Bay. BREIN, to those of you who are wondering who they are, is the RIAA of the Netherlands. Essentially they’re a Dutch anti-piracy group, and they think that the proxy service to Pirate Bay is breaking the law. It may be. Greenhost, the hosting company behind RePress, and their webhost, is in the Netherlands, and it does fall under that law.(It’s nearly impossible to keep up with all this, but Wikipedia has a nice list of everyone who’s blocking The Pirate Bay, and their status. That’s a real Wikipedia link. In the US, so far only Facebook and Microsoft will edit your links to The Pirate Bay, and only on their services.) As of July 9th, all4xs/Greenhost lost the argument. A court order came in and now there is no more hosting on their site.

It’s important to understand this Court order only impacts the proxies at Greenhost. There is no action against the plugin itself, and none at any other website using it.

So why does it worry me?

I do a lot of forum support, and I can easily envision people getting cease-and-desist orders from the Courts, telling them to remove their proxies. I can see webhosts shutting down sites because they don’t want to deal with the hassle, or because their servers happen to be located in a country where the site being proxied is blocked. And without any effort at all, I can see the users, who don’t understand the risk they’re getting into by running this proxy, screaming their heads off and blaming WordPress because they are uneducated. They’re not stupid, and they’re not evil, they just don’t see the big picture.

It’s like when I had little sympathy for Blogetery, when it was shut down in June of 2010. They were running an open, unchecked, Multisite, and allowed anyone in the world to make a site, and didn’t monitor their users. Thus, after multiple copyvio issues, and now a terrorism claim, Blogetery’s webhost decided enough was enough and shut them down, impacting around 14,000 people (give or take, I wasn’t able to get the number of splogs on that site sorted out). The point there is that Blogetery screwed up by not taking care of their site. It’s your responsibility to do that, and the less people know about what they’re doing, the more likely they are to screw up.

I’d be a lot happier if RePress’s plugin page explained the risks. Until they do, I give you my own:

RePress will let your server to act as a proxy to any website you chose, allowing visitors who would be otherwise blocked by their country or ISP to visit those sites. Please investigate the laws of your country, as well as those of your webhosting company, to ensure you are not violating them. Also remember to review the terms of use for your webhost, and do not provide proxy service to any site (or type of site) that you aren’t permitted to host yourself. If your hosting company doesn’t permit porn, don’t proxy a porn site. While this plugin makes every effort to prevent cross-site scripting, you are expected to monitor the sites you proxy and be aware of their intention. Remember: If you put it on your server, you are responsible for what it does.

(If RePress wants to copy that and use it as is, or edit it, they have my permission to do so. And they don’t even need to credit me if they don’t want to.)

17 July, 2012
Scorched Earth Security
This post is dedicated to Matthew Freeman, who donated to help me get to WCSF. I have not forgotten coffee.

Napoleon’s invasion of Russia
There’s been a lot of kerfluffle about hacked systems again, especially that the ‘auto upgrade’ isn’t safe. I want to point out that your automatic upgrade of WP and its plugins is prefectly safe, if your system hasn’t been infected. Once you’ve been infected, however, it’s a whole different ball game. I subscribe to the salt-the-earth philosophy of cleanup, but more on that in a moment.

Odd as this may sound, I tend not to spend any time determining where the hack was. My feeling is that the longer a hack sits on my live server, the worse off I’ll be. If it starts to happen repeatedly, I may look into it more. But generally speaking, a hacked site boils down to some pretty obvious avenues of attack:
1. Insecure password on your server
2. Insecure behaviors
3. Bad plugins/themes/extensions
4. An insecure webserver
You notice that I’m leaving the apps themselves off the list? For the most part, a hugely explioted hack isn’t an app vulnerability. Most well used apps, like Drupal and WordPress, are remarkably well tested when it comes to that, and the developers are quite attentive. The weakest point in the security tripod is going to be the user. When I was exploited, you bet your ass it was 100% on my head, and no one else’s.

So when I see a web-app get hacked, my first thought is not ‘debug from whence it came’ but ‘get the file off the server — now.’ If you leave the hacked files on the server, the odds of your site going down again and again increases, so the very first thing I do is download everything. Every single file, the database, and everything that sits on that server. I back it all up on a computer, preferably one with a good security/virus scan tool, and then I get started on the real work. I’m going to come back to those files and review them, but that’s later. Right now I need to get what I have clean.

Make a list of everything on your server. Separate your ‘personal’ files from the application files. For example, in WordPress I would list my themes and plugins as the ‘application’ files, because I can easily download them from the repository. My ‘personal’ files would be the images in /wp-content/uploads and /wp-content/blogs.dir, the .htaccess file and my wp-config.php file.

Now here’s the scary bit. Every file gets deleted off the server. Yes. Every file. When it’s WordPress, I kill it all with fire except those personal files.

Then I download fresh copies from WordPress.org (and only WordPress.org) but I don’t copy them up. No, instead I change my server password, and my SQL password. If I’m having an extra neurotic day, I may make a new SQL id and use that instead. Regardless, it’s Password Changing Day. If I used that password anywhere else, it gets changed there too.

Still with my site down, I look over my .htaccess and config files with a fine toothed comb. I know what’s supposed to be there, and I know what’s not. I’ll also scan my personal files (all those image folders) for any .php or .htaccess files in there. See, nothing but files I uploaded are supposed to be in there, so if anything is, it’s bad.(If you use caching plugins, you may have other files in there, but you should already know that. Still, it’s best to turn off any caching you have while you rebuild. Change the cache constant in wp-config to off, and remove the cache folders from wp-content.) If I find anything, I delete it (though I will make a note of the time/date that file was updated, and since I have my backup, I can look at it in depth later). I’m also going to make sure permissions are right. I want things to be secure.

Finally I upload every new file back up from my fresh copies, and then make sure my site still works. It should.

It used to be that people told me I was silly for doing this. It was overkill, surely I could just change passwords and remove the infected file. Sure, that might work. The problem is these guys are getting smart. Denis uncovered a pretty cool (if evil) hack, where your updates are compromised, and basically from now on, you’re getting hacked code. With my method, you’d be ‘safe’ from that continuing.

Of course, you’re not safe from it happening again, as you could be hacked again, and this is where we have to start digging into logs and sorting out what the hack was and how it happened. And that is a different post all together.

If all of that is too much for you, and it can be, I recommend hiring Sucuri. For $90 a year, they’ll monitor your site for you. If that sounds like a lot, that’s $7.50 a month. You can spare the latte.
12 July, 2012
Art History of Plugins

This post is dedicated to Lisa Sabin Wilson, who donated to help me get to WCSF. Lisa is to documentation what I am to the forums, and encourages me to write better (though she probably didn’t know that).

Quite often people suggest that we ‘weigh’ the usefulness of plugins and themes in the WordPress repository differently. Some want to use star ratings, other popularity, and others compatibility of WordPress Versions.

Invariably, if I get roped into these discussions, I say ‘None of it maters more than the rest.’ And people always argue that their chosen method is the best. No one has ever succeeded in convincing me they’re right and, I’m pretty sure, no one ever will.

The reason I’m so sure about that is the same reason we don’t just buy cars based on the tire size, or a house based on a bathroom. It’s the reason we research and compare, study and inspect, and ask our friends. It’s because we know to look at the big picture.

Let’s look at A Sunday Afternoon on the Island of La Grande Jatte. From afar, it’s simple. A painting of people on the island. But if you walk up to the painting (it lives in Chicago, I love visiting it) you’ll see Seurat painted entirely by dots! As you step in and out, the painting changes and your perspective and understanding of the work as a whole changes. You cannot simply say ‘There is blue paint.’ and make your final decision that this painting will look nice against a blue wall. You have to consider how it will look up close, far away, and will it be better to blend or contrast. Seurat liked the contrast, which is why it has a brown border and a white frame.

The small moments, those dots, make up the whole of the piece and you have to consider everything that went into it, if you want to understand the painting. Anyone can look at if from afar and say ‘Yeah, nice.’ But when you start looking at the work, and the layers of meaning, you see things differently. With art, that’s the point. Sometimes a painting is just a painting, and sometimes a story is just a story, but more often than not, the ‘deeper meaning’ your teachers were after you to get from a story is simple: Look at the whole story. Look at how each character’s actions become a part of the whole.

This relates, directly, to understanding plugins. At heart the question people are asking is simple: How do I know which plugin is the best to use for this situation?

You can’t just take one and say ‘This is compatible with 3.4, therefore it is superior!’ I wish you could, my life would be easier. Instead, you must learn how to review plugins critically. Don’t throw your hands in the air, you don’t need to know code to do this. You do need to know what you want, and you need to read and pay attention, but at this point, if you’re still reading this blog post, you know how to do those.

The secret magic, which I talk about in WordPress Multisite 110 (Chapter 6: Security, Plugins, pg 36), is to review all components of a plugin’s information. You have to look at how all the little dots make up the whole picture — that’s why we talked about Seurat — and use those to understand how likely a plugin is to be safe to use.

Who wrote it? If I see a plugin written by someone I’m familiar with, I’m more inclined to trust their work. I already know how to get in touch with the developer if something goes wrong, and we have a rapport. Second to that is if they work on WordPress core. If they have commit access, I trust them (even Otto, who’s broken the site before). If they’re a regular contributor, it’s much the same. However this is not ‘common’ information. It’s easy to find, but it’s not something everyone knows off the top of their head. You can quickly search trac for their user name. I find it easier to limit the search by changesets, so here’s a search for wpmuguru’s credits in changesets. Yeah, looks like a trustworthy fellow!

What does their website look like? In cases where the developer doesn’t have any core contribs, move on to look at their website. Is it the generic version of WordPress with barely any content? Is it a Geocities flashback? You know crappy websites when you see them, and a crappy website for a developer warns me that they don’t use WordPress the way I do. Little to no content implies they’re not writing posts, and if they aren’t writing posts, how do they keep up with the look and feel dynamic of WordPress?

Is it well documented? Documentation is king. A plugin that is poorly documented, with poor spelling and grammar (regardless of language), and no screenshots makes me Spock the eyebrow. Not every plugin needs a screenshot, but a plugin should have the basic information included on that page. I’ve started copying my readme content into the contextual help in my plugins, for extra documentation levels. The point is, if the documentation is sparse, either the plugin is really simple, or you’re going to have a bad time of it when you have a problem. Developers, document. It will save you a lot of time.

How often is it updated? This is where we start to get weird. The simpler a plugin, the less it needs to be updated. Impostercide has barely changed since WP 2.5. I do update it about once a year, to change the versions, or add internationalization/help screens, etc. The bones of the code have not changed since 2005, and the original version still works just fine. Not every plugin should be updated every month. Now a more complicated plugin, I’d actually like to see it updated more often, with smaller changes. Don’t change it all at once, after all. Review the Changelog (if they don’t have one, it’s not well documented). See what’s being changed.

What problems have people had? Recently the Andy/Otto team made it easier to see the forum posts associated with a plugin, which means it’s easier for you to see how active a developer is with support, and how problematic the plugin is. Many of these issues are user-based (i.e. they’re not sure how to use a plugin), but sometimes they’re actually bugs. Check how many problems have people had, and if they are resolved. This example is a great sign:

What’s in the Compatibility Matrix? This is a very complicated thing, but it’s also very telling. Knowing how many people have reported a plugin works or doesn’t work, and getting an average, can help you. Sometimes you have to go back and forth, checking various plugin versions to WordPress releases, to get the whole picture, though, so it can time time to understand what’s going on.

What Else? Only now do I take a look at things like downloads, what the author says it’s compatible to, when it was last updated, and what the stars are. Why? Because unless an author has written ‘This plugin will not work on WordPress 3.4!’ in the readme, there’s a darn good chance it’s just fine and they didn’t bother to update. And that pisses off a lot of people.

Look. There’s no feasible way to force the developers to update their plugin documentation right now, and even if we did, there’s no way to assure they got it right! People make mistakes, which is why we have to learn to use our brains and think about what we want to do before we act. Yes, it’s work. As I’ve said many times, running a website is work. It’s always going to be, so at least try to work smarter.

I didn’t touch on code reviews at all, but what tips and tricks do you use when you’re collecting all the dots and evaluating a plugin for use?

9 July, 2012

Author: Ipstenu (Mika Epstein)

The Perception of Security

Forever Alone No More

No Children Necessary

The Dangers of Being Uneducated

Scorched Earth Security

Art History of Plugins