Tag: updates

Mailbag: How do plugins update?
From Ken the Web Mechanic comes this:

Hi! I wonder if you’d have any insight on this… I’ll mention Wordfence, though I imagine that it applies to any security plugin that compares plugin files with those in the WordPress repository… One of the most common things that Wordfence reports as a file “inconsistency” is the readme.txt of many plugins. Frequently, when using Wordfence’s compare feature, the readme of an installed and up-to-date plugin is shown as not the most current version and the repository shows the latest version – which is for the version that is installed!! If you delete the plugin and then download and install it anew from the repository, the readme is for the current, Wordfence has no complaint and all is right with the world… So I guess my question is… When a plugin is updated through WordPress, does the readme.txt file always get updated? It’s always been my understanding that during an update all of the old filed are deleted and then the new version is installed from the repository… It’s seeming like this may not be 100% of the case. It’s certainly only a minor irritation to me… but it makes me curious… Inquiring minds and all of that! 😉 Thanks!

I put the whole question in because while the crux is “How are these buggers updating?” the whole picture is interesting. I’ve talked about this once before, but it was a very long time ago. How the WordPress Upgrade Works was posted in 2011, and Why does the WordPress background auto-upgrade work? was back in 2013. So it’s about time for a revisit.

The short answer is “Actually, the readme.txt is deleted on plugin (and theme) upgrades.”

The longer answer means first we should understand what’s going on with upgrades! How plugins (and themes) update is pretty basic and you can check out /wp-admin/includes/class-wp-upgrader.php to see all this code:
1. Connect to the filesystem.
2. Download a package.
3. Unpack a compressed package file.
4. Clears the directory where this item is going to be installed into.
5. Install a package.
These are all great failsafes, making sure multiple times that we’re not about to leave a user in a bad state. We check to make sure we can download and use the file before deleting and replacing. We check to make sure WordPress can find all the folders it needs, like plugins and wp-content and so on. If it can’t connect to any of the ones it needs, it will fail. We make sure we can download and unzip the file. Even when we look at the complex fourth step, we’re all checking over and over to make sure that when we really do delete these files, we have something to replace them with.

The goal is that WordPress should never be able to leave you with a plugin deleted and not installed again, nor should it leave you with a half-deleted plugin. Obviously critical failures, like a server reboot mid-stream, will have some catastrophic effects. This is why WordPress tosses a .maintenance file down, mind you. Stops your site from looking like total poop while all this is going on.

When we look at the class Plugin_Upgrader itself (line 766 or so), we get into some nitty gritty things. The public function upgrade does some interesting things:
```
		add_filter('upgrader_pre_install', array($this, 'deactivate_plugin_before_upgrade'), 10, 2);
		add_filter('upgrader_clear_destination', array($this, 'delete_old_plugin'), 10, 4);
```
Here we are clearly deactivating and deleting safely before we upgrade. And at this point, I’m very confident that we’re deleting that readme.txt before we upgrade.

Okay! So why is WordFence being a dillweed?

I have a theory it’s related to the updates we do when WordPress core has a new version. You see, instead of updating the whole plugin, we update the readmes only to edit the “tested up to…” value. If there’s no code change, after all, why would we bother? No need to push an update! This means you no longer have a plugin that 100% matches what’s on Wordpress.org, you have a plugin where the code files match, but not the readme.txt files.

And then poor WordFence notices that the readme you have and the readme on .org’s servers is out of whack, and tosses an error.

I don’t know how WordFence would fix that, but I’m pretty sure this would hang ’em up.

WordFence folks, got any ideas?
15 January, 2016
Self-Update Your Plugins

When your plugin is hosted on WordPress.org, this isn’t a problem at all. But if you’re selling your own work, or hosting it on a non WPORG resource, there are other concerns. You see, if you host a plugin on WordPress.org, your plugin can’t have it’s own updater script. You have to use the default .org updater. This is just fine, except when you have an add on that you want to be pay-only. Then what?

Take a look at Easy Digital Downloads. You can get the main plugin from WordPress.org, and if you buy add ons from their site, they get magical updates too! How did they do that? They put an updater script in the main plugin which is then called by the paid extensions. You can even use their Software Licensing add ons to run your own updates on your server! If you want to sell on their site, they’ll help you take care of that too.

Todd Lahman also has an WooCommerce API manager, so if you’re using WooThemes, you’ve got that covered too.

Speaking of self hosting, if you’re hosting your own code on Github, then you want to use Andy’s Github Updater. While it’s not allowed on .org (sorry Andy), this will let you push updates from your GitHub or Bitbucket hosted WordPress plugins and themes.

My buddy Norcross has his own free updater for you as well.

You can also look at services like Auto Hosted or WP Updates, both of which promise to make it even easier and faster for you.

Jeremy Clarke has a automatic theme/plugin updater as well if you still want to be self hosted.

If you’re using ThemeForest, there’s the Envato WordPress Toolkit, which your users (not you) will need to install on their sites to get updates. I don’t know if there’s a way to include an updater in your packaged theme or plugin, but that toolkit needs to be all over the place for users. That it’s not brings all the issues you see with their products being out of date.

There are hundreds of other ways around this. And really, there’s no excuse to not keep your plugins and themes up to date, no matter where they live. Keep those users updated and make it easy for them to do it! What resources do you use when self-hosting a plugin or theme, to keep it on the up and up, and keep everyone updates?

17 September, 2014
So Your WordPress Upgrade Broke

I’m delving into angry-land here, so hold on to your hat.

So. You upgraded to WordPress to a major release without testing it first, and broke your site? It’s probably your own fault. Bring on the stones and when you’re done, let’s talk.

Ready to talk? Okay, you didn’t test. That’s why it’s at least partly your fault. This triples if the next words out of your mouth are “And my WordPress site is my life!” It quadruples if you say “My client sites broke!” It’s infinite if you broke your company site and you happen to be a WordPress based company.

But notice how I said probably? I can honestly say that 50% of the time my site breaks, it’s WordPress, not me, but I happen to run trunk without testing, which makes it my fault, not theirs. Seriously. I’m running trunk on a live site, which updates twice a day. I’m a little reckless. My life is WordPress, which makes me in violation of one of my own cardinal rules, but at the same time, the part of WordPress that is my life is supporting it, or breaking it and reporting it. For me, a broken WordPress install is one that needs my love to fix it, and I embrace that role.

You’re not me. And in fact, neither is my dad or my friends’ sites that I host. For them, I have a couple options: Let them upgrade themselves, upgrade them automatically, upgrade them myself. I use all of those methods, in different situations and with each of those, what happens when they break? I will say this, for everyone but me, if I have a contract to manage their updates, I test the update first. To the fellow who complained he had 200+ sites to test, I say “Well, that’s your job.” You agreed to manage them, you better do it right.

Telling people “Your site broke because you didn’t test.” isn’t an answer, though. It doesn’t explain why the site broke. The answer to that is a little more simple. “You have code that doesn’t work with the upgrade.”

And yes, it’s really that simple. You have a plugin, or a theme, or an add-on to your server, that doesn’t like the newest version of WordPress. Now, it’s a struggle to fix one’s site at the same time as placating one’s customers/clients/visitors, because you’re in a race against time. This is why you have to do that usual testing with plugins off and so on. Complain all you want, there’s no way around it. Point out you’re not a coder all you want, that’s actually why this happened to you and not me.

What do I mean? Well I am a coder, so when I install a new plugin I review it first by looking at all the code. You’re not a coder, I hear, but you can still review the plugin by looking at the updates, the author, their contributions to WordPress, the support forums, and the size of the plugin. The larger a plugin, after all, the more chances to go wrong. I also like to check /wp-admin/credits.php and look for the author. If they’re there, the odds of them not knowing that there was a change in WordPress that impacts their code is pretty negligable.

And this is how it works. It’s the addition of all things, combined to make a good, educated, guess as to the relative safety of your site. Good plugins that you’ve checked on, good themes ditto. Sure everyone can make a mistake, but good code makes fewer, good coders adapt well, and responsive coders react well. That’s the biggest thing. People will make a mistake and break your site, but if you use a theme were the developer is on the spot with patches and generally responds quickly (say, within 5 days), then you can be pretty sure that this developer knows when WordPress is releasing a new build, and that they should test Betas and RCs. That’s what you’re looking for.

This is especially important if your site breaks on a MINOR upgrade. If your site broke going from 3.8.2 to 3.8.3, and you find out it’s a theme, stop using that theme. That’s really hard, I know. But it’s really serious. A theme or plugin that breaks on the minor updates is doing something really wrong, or is taking advantage of a vulnerability which makes it dangerous to use. That’s it. That’s the reality. Either code is really bad or it’s really unsafe.

Neither of those things means the developer is a bad person. It just means they did bad code. We have all done bad code. We have all been the cause for bad and dangerous code, and we will all be so again. But again, it’s how we respond that makes us heroes or not.

Look for the heroes. They stand out. Use their code.

23 May, 2014
Don’t Fear The Auto Update

I was not surprised to see the backlash to Auto Updates. We spent a lot of time trying to figure out how to explain to people that while you can disable it, we really, really, really, really, don’t want you to, and basically ended up with a Codex page that explained how to configure it and then Nacin’s followup post that is, indeed, the definitive guide to disabling updates. But people hate it or love it, and there’s no middle ground. This was, as I implied, somewhat expected.

Reasons why people hate it have varied from “I want to control my own updates!” to “This 3.7 upgrade broke something, so clearly you’re not ready!” Oh and don’t forget “You suck, I hate this! Why would you default this to on!?”

I want to stress one really important thing here. The automatic background updates for WordPress are for minor updates only. We’re not talking about auto-upgrading people from 3.7 to 3.8, but just 3.7 to 3.7.1 – These are small, minor, updates. When someone comes to me and complains that major releases don’t always work, I have actually said, “So? We’re not talking about major releases.” And of course, “You are making good backups on these super important websites, right? Right?”

It’s really easy to get bogged down with all the variable permutations about what updates could include and forget that WordPress started out simple. Yes, it’s defaulted to “on” because after intensive testing, and careful thought, WordPress core devs are pretty darn sure that these minor updates, which are more often than not security related, will not break a site. I’ll get back to breaking sites in a second. The point is that minor updates were picked specifically because it’s known that major upgrades can often break things.

Why is it defaulted to on? This is my reasoning here… Because the people who wouldn’t turn it on are the people who need it most. If they don’t know it can be turned on, they won’t do it. And they need it. The people who don’t read all the nerdy things are the ones who are still running WordPress 3.4 (no I’m not kidding). I spend a lot of time debugging WP without ever seeing or really ever looking at their site. I know a lot of users don’t upgrade because of laziness, or fear, so I want to address this (see? told you I’d get back to breaking sites).

Don’t fear updates

I said this on Twitter: If your site breaks every time you update WordPress, it’s time for a theme and plugin audit.

So what’s an audit? How does one audit?

It’s really simple. I have a longer presentation I give on this, but let’s go over how simple and basic this is.

Who is the author?

This is really obvious. With one exception, every plugin I use that’s made by core developers is updated to fix problems right away. It’s tested on versions of WordPress in the Beta stage, or even on trunk. It’s reliable because the author is reliable. Using a plugin by Mark Jaquith? No fear!

How active is the author?

Sometimes even I have no idea who that author is, so I look them up. And I want to see how active they are in WordPress. If someone is engaging on trac and writing plugins and themes, and posting about WordPress, yes, I take the time to read up on them. Remember, I’m auditing the plugin! So I want to see that this author is active and writes or contributes in a way that I approve of. That helps me trust them. Now I’m not expecting them to code as prolifically as Nacin, or write as frequently as Chris Lema, or even scour trac like Scribu. I have realistic expectations. One of my favorite developers is ‘try-lingual’ when it comes to CMSs, so I’ll check on her to see if she’s able to keep up with all the myriad CMSs her code works on. She knows about every release coming up? No fear!

How popular is it?

The more a plugin is used, the more people are banging on it in a diverse myriad of environments in ways the author probably never imagined. This is good. This means that the odds are higher than normal that the plugin will work on a bog-standard setup. It also means if I have a common server type (shared) it will probably work. The odds also go up for a more active volunteer environment. Popular plugin, used by thousands? No fear!

How often is it updated?

This is a careful thing. I don’t particularly worry if a plugin is old (i.e. not updated in over two years) if the plugin is simple, or made by someone very reliable. Heck, I haven’t touched the code in Impostercide in years, but I do update the readme every couple of WordPress releases to avoid people thinking it’s been abandoned. That said, I do like to see if the complicated ones are at the very least updating their readmes to say “yes, compatible up to the most recent version.” That tells me not only are they testing, but they’re aware of what’s going on in WordPress. Updates are reasonable? No fear!

What does the code look like?

This is hard. This is really hard. I review plugins, and write them, and it’s just plain hard okay? If I’m lucky, I don’t actually have to do this. Examples? Okay, try StudioPress’ Genesis Theme. I don’t look at their code, unless I need to make a child theme. Even then, it’s a case of trusting them to do the best by me. I believe in their code more than mine most of the time. Another example? Anything managed by WordPress.org. But what about the rest? When it’s simple, I can read through the code, make sure it’s not doing anything nefarious and move on. When it’s not, I hire someone else to do it. You heard me. I pay people to do what I can’t because an audit of code is important. Now I don’t do this for every site. Personal/play sites? I may wing it, knowing I make good backups. But a big, company site? Oh you bet every single line of code was checked. Good code? No fear!

Really? No fear?

No. Not really. You have to keep in mind that none of these are absolutes. I don’t look at just one thing and say “Done, I have no fear.” I mean, I say ‘no fear’ in these explanations, but the truth is it’s the combination of these things that makes me fear less. WordPress is doing a good thing here and I’m not afraid of it.

And in case you’re wondering, I’m using auto-updates on all my sites.

28 October, 2013

Tag: updates

Mailbag: How do plugins update?

Self-Update Your Plugins

So Your WordPress Upgrade Broke

Don’t Fear The Auto Update

Don’t fear updates

Really? No fear?