[wp-hackers] WordPress plugin update bugs

[Travis Snoozy]

On Tue, 02 Oct 2007 05:55:14 -0700, Matt Mullenweg <m at mullenweg.com>
wrote:

<snip>
> I'm not going to get into that here, but agree Omry's situation is an 
> edge case, and not worth adding a lot of complexity for.

This is where QA starts whining ;). Just because it's an edge case
doesn't mean it can be ignored[1]. Additionally, I don't think that "a
lot of complexity" is required to get the job done in a way that can
work for all plugins.

* We need to point out which plugins aren't getting updated -anyway-.
3rd party non-update notification comes for free with that.

* I find it hard to believe that allowing non-hosted 3rd parties to
register the name and latest version would be anything but a relatively
minor extension to the current system. The work is non-zero, but the
-vast- majority of code for scanning the repo would just be re-used,
either on a second repo, or some section of the current repo that
wordpress.org won't "advertise" at /extend/plugins/. The biggest hurdle
would be providing a web-to-SVN interface and infrastructure for
keeping the stub info up-to-date.


The biggest problem is that so much of the system is closed up in a
black-box on the server that effectively nobody can make patches to the
thing on their own. If you (or whomever else has access to such things)
don't want to do it, it doesn't matter how much anyone else wants it
done -- it won't get done. And yes, I'd be willing to put my code where
my fingers are and write a proof-of-concept. I'm convinced it would be a
piece of cake, and even more convinced that it's important to all users.
Just show me the code before Oct. 12 or so. ;)


And before I hear mutterings of "make a plugin," that's simply
unreasonable. Somebody *did* make a plugin[2] + infrastructure, and
update issues aside, core has effectively obsoleted it within *months*.
What happens if core decides to integrate 3rd party down the road? All
the work _I_ did on infrastructure and back-end would be obsolete in the
blink of an eye. Would _you_ have built the WordPress plugin repository
if someone else could come along and blow it away at will?

As for "build it into the plugin" -- why should every non-hosted
maintainer have to write the same code again and again and again, when
the problem can be solved in one place, once, forever? Update is in
core, and logically that means everyone should try and re-use that
common functionality, instead of reinventing the wheel.

> I would estimate that 99% or more of widely used WordPress plugins
> are in the repository. From the front page:

Having 1k hosted plugins is a pretty useless datapoint without context
-- you have to know the total number of plugins, as well as popularity
statistics for both hosted and non-hosted plugins, to make any kind of
numerically-sound analysis. You'd need to start doing stats on hosted
plugin hit/miss numbers on update requests to convince me of that
number[3], and even then it'd be a hard sell to leave the remainder in
the cold.

> Once we start doing one-click upgrades and installs of plugins I
> think a central repository becomes even more important, as you have 
> accountability for every line of code in the system.

You check every line of code in the repository? j/k ;)

I assume you mean that, if some wildfire starts to spread via one-click
updates, you have a convenient killswitch to stop it. With a 3rd party
registration database, you can maintain that killswitch while still
letting everybody play.

I'm not arguing against a centralized strategy at all, but rather,
I'm trying to say that the centralized strategy now has to expand to be
more inclusive because a critical system feature now depends on it.


-- 
Travis 

In Series maintainer
Random coder & quality guy
<http://remstate.com/>

[1] A cost-benefit analysis indicating that individual failures have
extremely low costs is conducive to making the argument to ignore much
more convincing. However, not indicating when a plugin isn't updating
could potentially have some pretty nasty costs associated with it.

[2] http://www.wp-plugins-db.org/wp-plugins-tracker

[3] Understandably, those stats aren't being collected yet.