| 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)
|
|
|
|
finished processing on the success page in this case; otherwise continue to show the 'will take a few minutes' message.
|
|
|
|
|
|
* 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
|
|
|
|
Conflicts:
classes/Memcached_DataObject.php
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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)
|
|
(wrong parameter meant we got the main page instead of the message's URL)
|
|
checking on Atom input
|
|
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.
|
|
|
|
|
|
|
|
|
|
Feed for group memberships, in activity streams format.
Shows a feed; has proper pagination; accepts activitystreams "join"
activities to start a new membership.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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
|
|
in non-web channels
common_shorten_links() can only access the web session's logged-in user, so never properly took user options into effect for posting via XMPP, API, mail, etc.
Adds an optional $user parameter on common_shorten_links(), and a $user->shortenLinks() as a clearer interface for that.
Tweaked some lower-level functions so $user gets passed down -- making the $notice_id param previously there for saving URLs at notice save time generalized a little.
Note also ticket #2919: there's a lot of duplicate code calling the shortening, checking the length, and reporting near-identical error messages. These should be consolidated to aid in code and translation maintenance.
|
|
* i18n/L10n updates
* translator documentation updated
|
|
the 'I want to post by email' checkbox with the controls for adding or removing a post-by-email alias.
Now, when you first come up the checkbox will most likely be off and the button to create an address is grayed out.
Checking the box enables use of the 'new' button to generate an email address -- it's left disabled until you check the box, so you can't accidentally trip it.
Actually adding the address now enables the post-by-mail option, as well, thus ensuring that it's saved. WARNING: OTHER CHANGES ON THE FORM WILL STILL BE LOST.
Removing the address now disables the post-by-mail option, so it's not sitting around confusingly enabled but useless.
You can still disable the checkbox manually without removing the address, in case you want to keep it for later.
It's also still possible to actually save it in the state where the option is enabled, but there's no configured address, but that shouldn't happen too often. Possibly that should be prevented outright though.
|
|
|
|
email *output* prefs up into the box for the address to post to, so they're next to each other.
|
|
have been destroyed by NetBeans and will be rewritten shortly. Sigh.
|
|
|
|
|
|
Moved the Webfinger user XRD action from the OStatus plugin to core.
Added hooks to add OStatus-specific stuff, but kept general stuff in
the core.
|
|
add event for setting up hostmeta, and use them in the OStatus plugin
|
|
|
|
max_id is not yet implemented, as it'll need support added to the search backends. (since_id we get 'for free' by just cropping off the list, it'll do for now)
|
