|
page; making it actually useful.
2010-11-20: Luke Shumaker <lukeshu@sbcglobal.net>
Load data for all plugins, not just loaded ones, on the plugin management page; making it actually useful.
* include.php: file to include to make creation of entry points easy (taken from index.php)
* index.php: move most of this file into include.php (and include it)
* plugindata.php: a separate entry point using include.php; load ALL plugins found, and write data gathered to plugindata.out.php
* .gitignore: add plugindata.out.php
* actions/pluginsadminpanel.php:
o use plugindata.out.php's common_plugindata() instead of StatusNet::getPlugins()
o give a button linking to plugindata.php, to refresh plugin data
o rename showDefaultPlugins() to showPlugins()
* lib/pluginlist.php:
o use plugindata.out.php's common_plugindata() instead of thowing the 'PluginVersion' event to currently enabled plugins
o for the enable/disable forms: (pseudo diff)
- if (!$disabled)
+ if ($enabled && (!$disabled))
o fix metaInfo(): "@fixme pull structured data from plugin source": we can do that now
I feel that adding a separate entry point is a fairly controversial change, and that it requires justification.
First, let me note that even if you do not agree with adding another entry point, moving much of index.php intp include.php to make creation of entry points easy is a good idea because this makes debugging _way_ easier.
As Ian Zenhack put it, "I'm not sure I like the idea of introducing a second entry point, especially for a smallish feature enhancement such as this." I initially agreed with this, however, after experimenting with several different options, I decided that creating the separate entry point was the best option. The biggest requirement for my efforts was
1. don't require revamping of the entire plugin system
which is what Brion Vibber seems to think is necessary on the StatusNet wiki (http://status.net/wiki/Plugin_installation_interface). There are simply too many valuable plugins already, breaking compatibility would be a Bad Thing. Since the plugin data is gathered from a usually non-static function of the plugin object, and instantiating the object loads the plugin, this essentially gives us the requirement
2. get the output of a non-static function without instantiating the object
The obvious solution would be to load the object in a sandbox environment, and save the output somewhere. This is what the separate entry point is, a sandbox.
A cool perk of my method is that it allows us to process the data in an orderly way, such as "keying" the array that the data is in, allowing for orderly plugin lookup. There are a lot of possiblities that this gives us, I have limited myself to using this to address the @fixme in lib/pluginlist.php, in order to keep diff size small, and changes obvious. A neat feature that we can add is a collapsible tree in the plugin management page, based on class hierarchy. I have done this, but it is glitzy, and more of a proof of concept.
To address security and server load concerns, I have implemented security around plugindata.php (the separate entry point that refreshes plugin data). In order to run the file, you must either run it from the command line as a script, or be logged in as a user with rights to configure the site. This prevents lusers from spamming this entry point.
|
