| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
2010-11-20: Luke Shumaker <lukeshu@sbcglobal.net>
Add a more robust (but backward compatible) plugin config system
* lib/util.php: add common_config_section($main), as a companion to common_config($main,$sub)
* lib/statusnet.php:
Functions for other Places:
- add public static pluginFiles($name) which returns a list of all possible filenames a plugin with $name could be defined in.
- addPlugin(...): use self::pluginFiles(...) instead of a hard-coded list.
Actual Functionality:
- add public static getPlugins() which returns
array_merge(
common_config('plugins','default'),
common_config_section('plugin-list')
)
- use self::getPlugins() instead of common_config('plugins','default')
Robustness:
- handle plugins that have a type other than "array" or "null" for parameters without bugging out
* actions/pluginenable.php: (in order of in the file):
- use StatusNet::getPlugins() instead of common_config('plugins','default')
- check if a plugin exists, not whether it is loaded (uses newly added StatusNet::pluginFiles(...))
- Also save to 'plugin-list' (the new plugin system), in addition to 'plugins' (the old plugin system)
|
|
|
|
stuff like that on SVG images! Todo: replace the extension check in this case with better content-based checks.
|
|
This reverts commit 3e82000d578cf5f5935d972a26c84fe31768460a.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Add 6 new events to make it easier to override the type of an activity object.
|
|
Conflicts:
classes/Memcached_DataObject.php
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Conflicts:
plugins/CacheLog/locale/nb/LC_MESSAGES/CacheLog.po
|
|
mode in and out
|
|
|
|
Moved most of the heavy-lifting for account restoration out of
restoreuser.php and into its own class, with the hope that we'll do
the work from the Web eventually.
|
|
|
|
|
|
Tweaked ApiStatusesShow and ApiTimelineUser to still claim read-only when hit with a HEAD request (usually link checkers or a precursor to a GET, and should be semantically equivalent to a GET without actually transferring data)
|
|
Router entry for AtomPubService was slightly off, generating an incorrect link in the RSD data.
|
|
The new DeleteaccountAction lets a user delete their own account
(subject to global rights set by the admin). It presents a form to
delete the account, with an "I am sure." text entry box.
It then schedules the account for deletion and logs the user out.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Conflicts:
lib/router.php
|
|
to be used in router setup.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Conflicts:
README
actions/hostmeta.php
classes/File_redirection.php
lib/common.php
lib/designsettings.php
lib/router.php
lib/util.php
lib/xmppmanager.php
plugins/OStatus/OStatusPlugin.php
|
|
|
|
|
