[wp-hackers] WordPress plugin update bugs

[Knut-Olav Hoven]

On Tuesday 02 October 2007 12:30:35 Viper007Bond wrote:
> No one's stopping you from providing update notifications for your plugin,
> as you've already done (and as have I for one of my plugins from back in
> the day). Infact, there's even a hook (after_plugin_row) you can use to
> display an identical message to the existing update notification.

Reinventing the wheel?

>
> However, I don't think something like this (checking for updates for
> non-WP.org plugins) should be in the core.  Promoting the usage of one, big
> database is best for the users in my opinion (we already did it previously
> via the Codex). It doesn't rely on some random guy's site being online. It
> doesn't require them to setup and host a script that has to be updated when
> a new version is out. It doesn't... well, you get the point.

I don't agree with you, not at all. I think a distributed solution would be 
better. I believe many developers who work on their own (small) projects 
(like a WordPress plugin is) likes to have their plugins in their own 
repository and on their own website. I know I do (and then probably others do 
too).

Update notifications should be available from the core because this is a 
feature that multiple plugins can use. Why should all the plugins (non wp.org 
plugins) have to have their own implementation, which WILL at some point fail 
(and when you fix it, you still have other plugins that have the same 
failure)...


What I would like is an API (being hooks and/or functions) to make it easy to 
extend plugins to check for new versions.


An example that could be placed in the core API, for both wp.org plugins and 
other plugins:

$check_plugins = apply_filters('plugin_version_check', array());


Then plugins could hook on it with a function like this:

function filter_version_check($plugins) {
	$my_plugin = array(
		'id => "some-id-or-name-of-the-plugin",
		'http' => 'http://wp.example.com/my_plugin/newest_version.txt',
	);
	$plugins[] = $my_plugin;
	return $plugins;
}


The value of the "http" key could be a script that looks up a subversion 
repository or something like that. The "id" could probably be __FILE__ or 
something that combines the plugin with one from the list on the webpage.

No parameters needs to be sent, completely anonymous (except regular HTTP 
headers and "stuff").

>
> Plus, no one is stopping anyone from coding an API plugin that adds this
> support in. It'd be _very_ easy to do.
>
> But as I said, I think this is plugin territory and not core.
>
> On 10/2/07, Omry Yadan <omry at yadan.net> wrote:
> > Ozh wrote:
> > > Also, I think that would be an extra motivation for plugin devs to get
> > > their plugin hosted on wp.org if it's clearly shown that their plugin
> > > is not pinged, rather than this "could be up to date" lack of notice.
> >
> > So you think it's okay to discriminate plugins that are not hosted in
> > wp.org to "motivate authors".
> >
> > Here are a few reasons why I wont host FireStats on wp.org:
> > 1. Current license is CC-NC, and I though long before I chose it over
> > GPL. if I chose to switch to a GPL compatibly license, it will certainly
> > NOT be because someone forced my hand to do it.
> > 2. FireStats supports a wide range of other systems, and it does not
> > make any sense to host it in wp.org.
> > 3. I already have my own infrastructure that I am happy with (SVN, Trac,
> > Wiki, Demo etc). I am not going to throw all this.
> >
> > and finally - I already have my own version check mechanism, so I am not
> > too worried about users not being aware of new versions.
> >
> > I can make just the WordPress plugin file be GPL; host it on wp,org, and
> > require that users will install FireStats separately (and in fact I
> > already support this installation mode - it's called Satellite
> > installation), but this makes installation harder for users, so it's not
> > a real option.
> >
> >
> > I think it's appropriate to allow creating Plugin pages without hosting
> > the plugins.
> > Ideally it will also be possibly to update the information via some
> > protocol (XMLRPC?), to allow easy integration with other repositories.
> >
> >     Omry.
> > _______________________________________________
> > wp-hackers mailing list
> > wp-hackers at lists.automattic.com
> > http://lists.automattic.com/mailman/listinfo/wp-hackers



-- 
Knut-Olav Hoven
Systemutvikler               mob: +47 986 71 700
Linpro AS                    http://www.linpro.no/