| Age | Commit message (Collapse) | Author |
|---|
|
reject.
* actions/pluginsadminpanel.php:
o replace a `;' with a `.'; accidentally rejected change
o change the text 'Default plugins' to 'Available plugins'; didn't get applied
* lib/pliginlist.php
o un-delete line from metaInfo(); ?
o apply changes to getPluginVersion()
|
|
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)
|
|
|
|
has been updated to combine them with util.js source when building util.min.js
Revert "combine our standard scripts into one big script"
This reverts parts of commit 0c5ca46ba3a070803d993b0244fcc69d33875ebd.
|
|
|
|
finished processing on the success page in this case; otherwise continue to show the 'will take a few minutes' message.
|
|
stuff like that on SVG images! Todo: replace the extension check in this case with better content-based checks.
|
|
This reverts commit 3e82000d578cf5f5935d972a26c84fe31768460a.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
* avoid PHP notice from using wrong variable
* show a visible error instead of blank screen if no file submitted with restore form
* avoid PHP strict warning from using calling "non-static" DOMDocument::loadXML statically
* suppress PHP warning from XML parse errors
|
|
|
|
|
|
http://translatewiki.net/wiki/StatusNet:Cb5746be52330331844dea750bf452c0618aecb3-All_Rights_Reserved/pt-br
|
|
http://translatewiki.net/wiki/StatusNet:08b929b29496be84ff75d266b5e60b426cff449f-Hey,_1$s._Someone_just_entered/ca
|
|
|
|
Conflicts:
plugins/OStatus/classes/FeedSub.php
|
|
the debug code :D
|
|
temp file if feedsub/debug is on in config.
|
|
err msg to help tell what broke
|
|
err msg to help tell what broke
|
|
|
|
Add 6 new events to make it easier to override the type of an activity object.
|
|
Conflicts:
classes/Memcached_DataObject.php
|
|
|
|
|
|
group_member_profile_id_created_idx to group_member table, streamlines sorting of your group memberships in the sidebar
|
|
|
|
profile_role_role_created_profile_id_idx index on profile_role
|
|
notice_conversation_created_id_idx index on notice, replacing more limited notice_conversation_idx
|
|
see: http://groups.google.com/group/twitter-api-announce/msg/34b013f4d092737f
|
|
|
|
|
|
|
|
ideally indexed yet.
|
|
indexed, but will use updated sorting method.
|
|
notice_repeat_of_created_id_idx index to replace notice_repeatof_idx
|
|
that's not there. use the limit var which is there instead
|
|
group_inbox_group_id_created_notice_id_idx index to group_inbox table
|
|
reply_profile_id_modified_notice_id_idx index to reply table
|
|
notice_tag_tag_created_notice_id_idx index added to notice_tag
|
|
|
|
|
|
optimization as no other attributes are necessary.
Thanks to drslump reported at http://status.net/open-source/issues/2955
|
