[wp-hackers] 2-3 plugins (The Big Kahuna ... Richer Plug-in Management)

[Douglas Daulton]

My previous post outlined the three current plug-ins I'd most like to see in
1.6.  However, the big kahuna of enhancements would be an extended, embedded
plug-in manager in the core itself.   I've outlined how I think it
could/should work below.

1) HOW IT COULD WORK
***********************************************

A) The Plug-in "Store"
---------------------------
This would be a new tab under "Plugins" which would pull in descriptions of
available plug-ins WITHIN Wordpress.  Think of the iTunes music store.

The "store" would list aggregate and categorize all of the plug-ins found on
the various plug-in sites and provide plug-in devs a centralized way to
alert the installed community to the presence/state of their software.

To populate the "Store", plug-in devs would simply fill out a form on WP.org
, or better yet register an RSS feed with WP.org.  This feed would describe
their plug-in(s) and provide download URIs and other relevant info like
version numbers.  WP.org would, in turn, publish a master plugins RSS file
which would be read in by all WP installs and displayed on the "Store"
pages.

In addition to all of the descriptive data, each plug-in would include an
"Install" link.  For additional detail, see Item C below.

B) "Installed" Plugins
---------------------------
In the "Store", installed plug-ins would either not appear or would be
color-coded to indicate their installed status and/or if an upgrade was
available. In addition to the "Store" tab, there would be an "Installed"
tab.  

The "Installed" screen would function almost exactly like the current
"Plugin Management" screen.  The only difference would be in the "Version"
column.   The screen would check the installed plugins version number
against the "Store" RSS.  If the plug-in is current, the Version column
would indicate this with "Current".

If not, it would indicate this with an "Upgrade?" link.     For additional
detail, see Item C below.

C) Embedded Installs/Upgrades
-------------------------------
After clicking on the "Install?" or "Upgrade?" link, WP would follow the URI
provided by the devs and save the required files to the plugins directory
(if a new install) or plugins/upgrades if an upgrade.  New installs would
simply appear on the "Installed" screen for configuration and activation.

Upgrades might require a new tab called "Pending Upgrades".  Clicking on
this tab would show all captured upgrades.  Devs could write specific
upgrade scripts if DB tables are affected and create a "archive/restore"
path if needed.

D) Plug-in Rating
---------------------------
Users could centrally rate plug-ins and these ratings would appear in the
"Store".  This rating system would be a great help to users and devs (both
core and plug-in) alike.

E) Plug-in Watch List
---------------------------
Another possible tab would allow users to "subscribe" to the developer's RSS
feed for a given plug-in.  If one likes the bleeding edge, they can install
beta or nightly plug-in builds as they become available.  Or, simply follow
the development notes until the feature(s) they want become available or the
next point release goes "gold".

F) Extend to Themes
---------------------------
Once developed for plug-ins, this toolset could very simply be extended to
include theme management as well.

G) Dev Tracking Plug-In
---------------------------
Once the functionality is in place, a special module could be created and
distributed to all core and plug-in devs.  This module would provide devs a
common UI for tracking notes, publishing releases and distributing
documents.  This plug-in would then create the RSS feeds for all of the
developer's plug-ins or themes.   These feeds would then be auto-registered
with the central plug-in feed at WP.org.


2) WHY IT SHOULD BE DONE
***********************************************

A) Provides a simple, central mechanism for plug-in publishing, discovery,
"subscription", rating and install/upgrade management.

B) The upgrade functionality could, at least in theory, be extended to the
core itself.

C) The collective toolset would greatly reduce the support burden in IRC and
forums by putting the solutions to the following questions in the hands of
the end users ...

"What is the best plug-in to install to address XYZ
problem/need/functionality?"
"How do I install XYZ plug-in?"
"How do I upgrade XYZ plug-in?"
"What does plug-in XYZ do for me?"

D) By moving providing self-help tools for end-users, the need for for
forums and IRC will not be reduced, but the "signal to noise" ratio will
greatly improved.  In simpler terms, core AND plug-in devs can focus more on
next generation code rather than handholding less sophisticated, though no
less important, end users.

E) Helps devs get the word out about their plug-ins and themes.


3) POSSIBLE CHALLENGES, SOLUTIONS & BENEFITS
***********************************************

A) Core Changes Required
---------------------------
Challenge: 
This would require pretty significant changes to the existing plug-in
manager.  

Benefit:
In the long run, this change will solve more problems than it creates.  And,
the increased usability for the less technically adept end user should
significantly expand WP's user base/footprint in the "blogosphere".

B) File System Permissions
---------------------------
Challenge:
Install/Upgrade tools would require file-system permissions to write and
then execute install/upgrade scripts and/or DB back up files.  This creates
potential security holes which must be addressed and it may be confusing for
less technically sophisticated end users.

Solution:
These issues can be addressed during the initial WP install or upgrade by
stepping the end-user through permissions settings in much the same manner
as is done with wp-config.php.   Also, in the unlikely event that a
malicious dev be found to distributing malware through his RSS
install/upgrade feed, there is a central mechanism (the "Store") for killing
the feed and reporting the devs action to the entire install base.

Benefit:
Even if "How do I set permissions?" questions filter into IRC/forum support
channels, this is a "fix once" issue for the majority of end-users.  Once
the permissions are set and embedded install/upgrade is working properly,
then the user and dev community enjoy all of the benefits described above.