[wp-hackers] WP Plug-in Manager

[Alex]

This would require wordpress to be completely opened up to the plugin
interface. It might be a good idea to have user intervention (in
addition to auth w/xml-rpc) between the plugin repository and
wordpress installation. The user could browse information and plugins
in the repository but would require authentication before installing
the plugin. This authentication would actually be user intervention
for the wordpress script itself (not just the repository server). This
would prevent belligerent scripts from auto-downloading something
nasty or auto-installing something nasty. User intervention may also
mitigate any exploits (cross site scripting, insecure plugins, etc)
that might try and override the functionality of the plugin system to
do something bad.

I like the concept though.



On Thu, 24 Jun 2004 23:44:46 -0700, Doug Daulton
<ddaulton at ursastudios.com> wrote:
> 
> A couple of thoughts ...
> 
> 1. This is a great idea.  It will greatly expand the usability of WP for
> the non-technical masses.
> 
> 2.  To the concern that the XML-RPC interface makes this spyware, the
> solution is very simple ... communication.  Making it very clear that if
> the Plugin Manager is enabled, it will sort through the DB to see which
> plugins you have and which could use an update.  Then, make it really
> simple to disable the Plugin Manger.  Then, the functionality exists and
> those that have privacy concerns can turn it off all together.
> 
> 3. Central tracking of plugin installs and regular usage is a good
> idea.  It gives hard metrics to the devs so they can make decisions
> about tuning the WP core to work well with the most popular plugins
> and/or pulling said plugins into the Core as a default or optional
> feature.  These metrics take the guess work out of the process.
> 
> 4. There is no need for central storage of the plugins.
> Plugin devs can maintain their distros on their own sites and provide
> the centralized DB a link to the source.  Then, the central plugin
> directory can pullover the code to the central server without the dev
> having to maintain the distro elsewhere.  The only thing required might
> be a common RDF document which is held in the devs downloads dir and
> describes each download and any pertinent data.  When registering a
> plugin with the central plugin DB, devs would provide a link to the RDF
> on their site.  The central plugin DB would parse the RDF and figure out
> what it needed.
> 
> Basically, what is being described is something similar to Windows
> Update or ROM/apt-get/emerge in the Linux/BSD world.  Obviously,
> everyone would have to agree on what that RDF should look like but
> common sense elements would include:
> 
> a. Plugin Name
> b. Version
> c. Author(s)
> d. Release Date
> e. Download URI
> f. Docs URI
> 
> I have some other, general thought on development practices, but I'll
> make that a separate post so as not to confuse the issue.
> 
> Doug
> 
> Stephen O'Connor wrote:
> 
> >Just to clarify, here's how I see the idea right now:
> >  1) A database of plugins that either contains the plugins themselves or
> >links to the plugins (as well as a wealth of other info such as
> >instructions, comments, etc).
> >  2) A new type of plugin who manages and downloads plugins.
> >  3) A feed from the database so the previously mentioned plugin could
> >search for and autodiscover new plugins directly from the admin interface.
> >
> >The problem with the wiki is that some people don't enjoy using them and can
> >quickly become horribly organized.
> >
> >I say it sounds like a great feature.
> >
> >- Stephen
> >
> 
> _______________________________________________
> hackers mailing list
> hackers at wordpress.org
> http://wordpress.org/mailman/listinfo/hackers_wordpress.org
>