Referencing plugins externally?

[Tys]

I want to package up my music plugin for others (http://tvg.ca/). However it requires that the plugin's php file be references directly (ie for iTunesBlogger, xmlrpc calls). What is the best way of going about this? Can I just call "plugins/serendipity_plugin_name/serendipity_plugin_name.php" directly?

I am also using a bunch of external libraries (one for grabbing information from Amazon.com, and JPSPAN for xmlrpc calls). How should I package them to be included, or just point people to download the packages themselves?

[garvinhicking]

Plugins should be called with the /plugin/PLUGINNAME mechanism, which interfaces with an event hook.

Please have a look at the blogpdf, freetag, custom_permalink, livesearch and/or spamblock plugin. They all use the 'external_plugin' hook to allow calling direct plugin content.

The external libraries should be bundled within your plugin subdirectory.

I would like to offer you a CVS account to maintain your plugin on our additional_plugins CVS repository, if you like. However there we can only bundle files which are alright being GPL at least (BSD preferred) - so you'd have to check your plugins about that. If the library wouldn't allow bundling, we could still put your plugin into CVS and tell the users that they need to install the dependant library on their own.

If a library you use gets used by other plugins as well, we might want to create a 'bundled-libs' directory for those plugins as well. But this has not really happened so far.

Regards,
Garvin

[Tys]

Thanks Garvin, exactly what I was looking for.

As for a bundled libs, I would recommend JPSPAN, it is a very complete XMLHttpRequest, javascript <-> php object translation library, licensed under the PHP library (not sure what that entails however). It is a great way to update parts of the the site without doing a whole page refresh (think gmail).

I'm also trying to implement sidebar plugin hiding support. (See http://tvg.ca and click on the little minus signs in the sidebar titles). Was this already in the works for a future version, or should I keep plugging away at it? (seems to me it needs more changes then a plugin can provide).

[garvinhicking]

I have looked at JPSpan, but find it quite heavyweight. So I think for most of Serendipitys work a simple lightweight solution like the livesarch uses should be sufficient...

Your sidebar hiding plugin really looks cool! As I see it you needed to modify the sidebar.tpl smarty template, right? You are right then, this can only be solved within a template and not with plugins right now.

However, you could create a sophisticated javascript which cycles through the DOM Nodes and adds the Icons to the sidebar headers dynamically. That would be a cool thing to have, and could then be deployed within a single plugin. Would be so great to have that!

Regards,
Garvin

[Tys]

Never thought of itterating through the dom nodes with javascript, neat idea. Only down side I see is the ability to preset a plugin to be visible or not. Currently the only way I see this is another column in the database. Maybe there is an easier solution. Any ideas?

I also had to edit the plugin_api.inc.php, function generate_plugins. Added the plugin's unique name to the pluginData array. Makes it easy to identify a unique sidebar item (plus the ability to have per-plugin styles). The above could be accomplished with your dom nodes idea too (the uniquely identifying at least).

[Tys]

I have looked at JPSpan, but find it quite heavyweight. So I think for most of Serendipitys work a simple lightweight solution like the livesarch uses should be sufficient...

Ever thought of taking the xmlHttpRequest stuff from the livesearch plugin and abstracting/generalizing it a bit?

I agree that JPSpan is heavy weight, but if it save me a couple of page refreshes then I think it is worth it. Plus the transparent translation between php and javascript objects and arrays is freaking cool.

[Tys]

Plugins should be called with the /plugin/PLUGINNAME mechanism, which interfaces with an event hook.

Even if it is a sidebar plugin? Can sidebar's even implement event_hooks? I see no reason why they shouldn't be able too, but from looking at plugin_api.inc.php it seems like they aren't.

Why not use the is-subclass function to determine if a plugin implements events or not instead of relying on the database/file names? IMHO reflection is much more elegant solution.

http://ca.php.net/manual/en/function.is-subclass-of.php

[Tys]

Here are some changes to plugin_api.inc.php that will allow sidebar plugin's to implement event hook's if they extend serendipity_event instead of serendipity_plugin. Doesn't seem to break anything on my install.

plugin_api.inc.php

in
function &get_event_plugins($getInstance = false, $refresh = false)

around line 480 change

Code: Select all

$plugins = serendipity_plugin_api::enum_plugins('event');

to

Code: Select all

$plugins = serendipity_plugin_api::enum_plugins();

around line 490 change

Code: Select all

if ($event_plugins[$plugin_data['name']]['p'] = &serendipity_plugin_api::load_plugin($plugin_data['name'], $plugin_data['authorid'], $plugin_data['path'])) {

to

Code: Select all

			if ( $temp_plugin = &serendipity_plugin_api::load_plugin($plugin_data['name'], $plugin_data['authorid'], $plugin_data['path']) && is_subclass_of($temp_plugin,"serendipity_event")) {
				$event_plugins[$plugin_data['name']]['p'] = $temp_plugin;

[garvinhicking]

The problem of your patch is that this would mean that ALL plugins would be pregenerated on each page load and introspected. This is a quite costy performance, especially if 99% of the sidebar plugins do not use the event hooks.

So I really do not like that idea at all, and would rather keep the clean separation. We do not use is_subclass of, because that would mean we have to instantiate the class to get is parent. But we'd rather not do that costy operation and get the type by filename to cycle it easier.

You could use a generic event plugin which wraps the output of a sidebar plugin easier, IMHO.

The other issue about using JPSpan: As long as it's not needed, I'd really like to refrain from it, because of its size. And I'd like to keep Serendipity as compatible as possible, and JPSpan is quite experimental coming to terms of compatibility with all Browsers. AFAIK Opera and Konqueror do not support the methods at all, which is why we should use xmlHTTPRequest as seldom as possible.

Last but not least: To define the default visibility of plugins, you could create an event plugin which maintains there state. The plugin could list all existing sidebar plugins in a matrix-style list and allow to check/uncheck buttons. The state is then saved in an own database table plugin_sidebar_visibility or so, and can be read by your DOM-cycling plugin. This way we do not need to modify our core plugin configuration tool and do not need to modify existing tables. Creating per-plugin tables is done in the shoutbox-plugin for example.

HTH,
Garvin

[Tys]

I do agree that my patch is flawed in that every plugin is loaded, then discarded again. However sidebar plugins by their nature have to instanciated to be displayed, or am I missing something. Can't some refactoring be done such that when the sidebar plugins are loaded there is an is_subclass check and those classes somehow get passed to the get_event_plugins method? The sidebar's would already be in memory so there wouldn't even be disk io.

The wrapping of a plugin in a plugin just seems like a dirty hack to me when I feel there is a better solution available. Yes it is quick and easy, but slightly confusing for the user. Sorry for all the fuss, just think having events in sidebar's would be a nice feature.

I understand about JPSpan, you raised some good points. For plugins that want to refresh just part of the page, should I go the hidden iframes route instead?

Great idea on the plug visibility. Only problem I see is when a sidebar plug is added, removed or changes location then wouldn't the saved layout be outdated? I guess this just might have to be a draw back as most people won't be adding/removing plugins frequently.