[wp-hackers] WordPress plugin update bugs

[Viper007Bond]

Still playing devil's advocate here.

I don't get why hosting your own website, SVN, etc. excludes you from using
WP.org. I develop all my plugins locally and only commit to WP.org when I
have a final version (i.e. I don't use WP.org's SVN). I host my own website
that has pages for all my plugins.

However, I host all my downloads though at WP.org. This greatly boosts their
exposure, provides great statistics and ratings, and provides an update
service. Honestly, why wouldn't you host you your plugin on WP.org (besides
those fringe "omgz GPL!" / other odd situation cases) ?

It just seems like such a hassle coding in core support that relies on
external websites and having to provide support for all those plugin authors
(and debugging why their update check doesn't work) when it'd just be easier
to say "upload here and be done".

On 10/2/07, Knut-Olav Hoven <hovenko at linpro.no> wrote:
>
> 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/
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>



-- 
Viper007Bond | http://www.viper007bond.com/