Plugin Updates and WordPress 2.3
Arg! So, I’ve figured out why plugin updates don’t work for In Series in WordPress 2.3: “In Series” contains a space. I have filed a bug; hopefully it will get fixed soonish it’s been fixed.
[Updated x2]
WordPress 2.3 uses a web service — set up at api.wordpress.org — to determine when plugin updates are available. How this web service works is a bit of a black box; all we can really tell is what gets passed in, and what gets returned. The information that is sent by a normal WordPress 2.3 installation is:
- Blog character set
- Blog base URL
- “Plugin information”
The first two pieces of data don’t really have any effect on providing the service — it’s that “plugin information” that appears interesting. That data is a serialized version of the data returned by WordPress’ get_plugins() function. This information is stripped out of the plugin’s metadata header.
So, let’s look at the other side of things: how a regular human being would know whether or not there’s an update for a plugin. First off, we’d have to know the name of the plugin we’re interested in looking for an update for. Then, we’d probably go hit google, or the plugin’s home page, or the plugin repository at WordPress. That last option is very handy, since it’s a centralized set of plugins.
The WordPress update API appears to check the last route — this makes sense, since all the data is stored by WordPress, and presented in a consistent and centralized way. However, it has to make the connection between the plugins you have installed, and the plugins that are present in the database. The data that is sent to the server includes everything about the plugin (name, plugin URI, description, version, author, and author URI). This is all that the server has in order to match the plugins you have installed to the plugins it has version information for.
It appears that the server uses only the plugin name to determine if the plugin is hosted with WordPress. The logic for the web service does not appear to be open (I haven’t found the source), but the algorithm appears to be “take the plugin’s name, and see if we have that directory in our source control repository.” If this is false, then the plugin is skipped.
This algorithm has a few consequences. For example, if you have a plugin that’s not hosted with WordPress, but has the same name as a plugin that is hosted at WordPress, you could be nagged to upgrade to a completely different plugin than the one you actually have installed (bug #5116). Furthermore, if you install a plugin whose display name is different from the path name in the repository, updates won’t appear for that plugin because the WordPress API will think that the plugin is not hosted with WordPress (bug #5115). Finally, there is no indication for non-hosted plugins that updates are not actually being checked for them, which could lead to a false sense of up-to-datedness (bug #5117).
The source code repository that WordPress provides normalizes all spaces in project names to be ASCII dash-minuses (”-”) instead. Thus my plugin “In Series”, is mapped to the directory “in-series” in the database. But the WordPress update API does not perform this mapping — it looks for the “In Series” directory, and finding none, assumes that the plugin is not hosted with WordPress.
Update:
Turns out that what’s happening is that the update is comparing the value of the client’s plugin name (from the PHP header) with the title in the first line of the readme in the source control system. These two values were mismatched for my plugin. I’ve fixed this mismatch with my plugin.
4 Responses to “Plugin Updates and WordPress 2.3”
Posted: Oct 1st, 2007 at 03:10
While you’re checking this out you might want to take a look at the set-up for the plugin in brand-new installations. I had a very (VERY) old version of the plugin and updated to the newest one. After this all my posts had this error:
WordPress database error: [Table ‘eduo_wp.wp_in_series_3_0_6_entries’ doesn’t exist]
SELECT series_id FROM wp_in_series_3_0_6_entries WHERE post_id=’382′
(eduo is my baseprefix)
When trying to check the config page I also got an error (that I didn’t copy) if I tried to save the page without anything selected, checked or written.
The way to fix both is to actually use the plug-in so the tables are created.
So, I think it’d be a good idea to do two things:
1.-The “foreach” in (I think) line 27 of the config.php page for the plugin shouldn’t give an error if all fields are blank (or should have default values). Saving it with all fields blank gives an error (as the foreach assumes there’s at least one thing to check).
2.-The plugin should check if the table exists and create it if not (I think I fixed mine creating a new post and assigning it to a category, although it did pick up my older ones. Now posts don’t show the error)
Probably as part of the “first run” checks.
Posted: Oct 1st, 2007 at 09:28
@Eduo,
You have to go through standard upgrade procedure: disable the old version of In Series, install the new version, then enable the new version. This is how the tables get created, and how the “first run checks” get triggered.
Posted: Oct 1st, 2007 at 23:52
Ah. I didn’t know this. I must’ve missed it from the docs.
I admit I was lazy and overwrote the old plugin with the new (I was actually too surprised seeing I had missed almost 5 versions which, in hindsight should’ve been even more reason to go through standard procedure :)
The plugin works beautifully. The new (to me) box fixes everything I didn’t like about the older version. Fantastic.
Posted: Oct 2nd, 2007 at 07:39
@Eduo,
Well, you aren’t the only person to have had this problem. I’m really pedantic about triggering the update code only on plugin activation, because it’s a relatively expensive chunk of code within my plugin. The 2.x series didn’t have its own tables, so it was even expensive to verify that everything was up-to-date (I had to do a scan of the postmeta table).
In the 3.x world, a single check to see if the table exists is fairly cheap. However, the frequency with which that check would be done (once every page load) still worries me. I’d really like to have In Series do the Right Thing so that nobody ever has this kind of problem, but I also don’t want to contribute to excessive database loading. :/
In any case, I’m glad you like the new UI. :)