plugins
Scott Merrill
somewhat functional.
We don't have a way to describe plugins before they're loaded. We've
discussed in the past several ways to tell Habari about plugins. One
option was to call a specific function on each discovered plugin in
order to load that plugin's data into the database. Another option is
to follow the WordPress model of embedded plugin data in a PHP comment
at the top of the plugin. Yet another option is to require a text file
(XML, INI, free form, or other) that contains the plugin's details.
I don't like the idea of storing plugin details in the database, though
I can't adequately articulate why.
I generally advocate having a small info file that contains the details
of the plugin. We could use PHP's parse_ini_file() to automatically
prepare an associative array, assuming we make the plugin description
file follow an ini format. It ought not be overly taxing to load the
plugin detail files on each pageview of example.com/admin/plugins. It
is my opinion that this mechanism affords us (and our users) the most
flexibility in terms of adding and removing plugin files on the fly.
--
GPG 9CFA4B35 | ski...@skippy.net | http://skippy.net/
Chris J. Davis
Chris
Owen Winkler
>
> We don't have a way to describe plugins before they're loaded. We've
> discussed in the past several ways to tell Habari about plugins. One
> option was to call a specific function on each discovered plugin in
> order to load that plugin's data into the database. Another option is
> to follow the WordPress model of embedded plugin data in a PHP comment
> at the top of the plugin. Yet another option is to require a text file
> (XML, INI, free form, or other) that contains the plugin's details.
As I mentioned in IRC, I love the idea of being able to distribute a
plugin as a single file. It makes distribution very easy.
As you pointed out, requiring two files makes it more likely for
plugins to be distributed as archives, making it more likely that they
will be deployed on a site inside a subdirectory. This is a good
thing, as opposed to having a ton of disjointed files spread about the
plugins directory. I'm almost thinking that we should enforce this
(ie- no plugin files in the /user/plugins directory itself, and only
load plugins from /user/plugins/{somedir}/here.plugin.php).
As for the WordPress model of plugin discovery: Doing a grep from PHP
for comments inside every file in the plugin directory sucks. Let's
avoid that.
> I don't like the idea of storing plugin details in the database, though
> I can't adequately articulate why.
I'm not crazy about how we already store theme data in the database.
I can't remember why we're doing that. Does anyone remember? Is it
too late to go back?
> I generally advocate having a small info file that contains the details
> of the plugin. We could use PHP's parse_ini_file() to automatically
> prepare an associative array, assuming we make the plugin description
> file follow an ini format. It ought not be overly taxing to load the
> plugin detail files on each pageview of example.com/admin/plugins. It
> is my opinion that this mechanism affords us (and our users) the most
> flexibility in terms of adding and removing plugin files on the fly.
I like the idea of using an XML file, because it gives us the ability
to include more data for the plugin to use. For example...
We could include a few core functions that are plugin "helpers". When
the plugin is activated, it could call the plugin helper functions
that best suit its needs. One of these functions could be
Plugin::profile_to_rewrite_rule(). This function could look at the
plugin's XML profile and convert specific nodes into rewrite rules.
This would obviate the need for the plugin to call a series of
RewriteRule methods to incorporate its rewrite rules, and would expose
those rules in a common place among all plugins.
We could also store basic plugin UI information in the XML. The XML
could define the fields that appear in the admin UI for that plugin.
Instead of building a whole UI from scratch from within the plugin,
you could define the UI in a standard way from the XML, then call a
plugin helper function like Plugin::profile_to_ui() and it would
produce the required UI output (and hopefully also set up the system
to gather and store the results that are submitted).
Another great but simple use would be for storing a list of plugin
files. Sure, everything might be in one directory, but this would
allow us to do a which check of whether everything exists, and/or
delete plugin files that are no longer needed.
Primarily the reason you can't do this stuff with an ini file is that
ini files don't allow repeating subsections, like this XML:
<rules><rule>x</rule><rule>y</rule></rules>
The downside is that for some things, it may be necessary for plugin
developers to learn how to form a bit of valid XML. I think we can
compensate for this, at least partially, by providing some online
tools for the creation of these files.
Depending on how we implement it, a plugin could be practically *only*
the info file. Just a thought.
Also, regarding the UI of the plugins admin page itself I've attached
a graphic with what I was hoping to get one of our designers to take a
crack at.
Scott Merrill
> As you pointed out, requiring two files makes it more likely for
> plugins to be distributed as archives, making it more likely that they
> will be deployed on a site inside a subdirectory. This is a good
> thing, as opposed to having a ton of disjointed files spread about the
> plugins directory. I'm almost thinking that we should enforce this
> (ie- no plugin files in the /user/plugins directory itself, and only
> load plugins from /user/plugins/{somedir}/here.plugin.php).
I'm +1 for "distribute all plugins as directories".
> I'm not crazy about how we already store theme data in the database.
> I can't remember why we're doing that. Does anyone remember? Is it
> too late to go back?
Someone thought this was a good idea. I forget who. It's not
documented well, so whoever wants to own this should step forward. I'd
be willing to evaluate any better ideas that might be suggested.
> We could include a few core functions that are plugin "helpers". When
> the plugin is activated, it could call the plugin helper functions
> that best suit its needs. One of these functions could be
> Plugin::profile_to_rewrite_rule(). This function could look at the
> plugin's XML profile and convert specific nodes into rewrite rules.
> This would obviate the need for the plugin to call a series of
> RewriteRule methods to incorporate its rewrite rules, and would expose
> those rules in a common place among all plugins.
Sounds good, in theory. I think I'd need to see a more concrete example
to really understand this, though.
> We could also store basic plugin UI information in the XML. The XML
> could define the fields that appear in the admin UI for that plugin.
> Instead of building a whole UI from scratch from within the plugin,
> you could define the UI in a standard way from the XML, then call a
> plugin helper function like Plugin::profile_to_ui() and it would
> produce the required UI output (and hopefully also set up the system
> to gather and store the results that are submitted).
That would be handy.
> Another great but simple use would be for storing a list of plugin
> files. Sure, everything might be in one directory, but this would
> allow us to do a which check of whether everything exists, and/or
> delete plugin files that are no longer needed.
Filenames + md5 hashes? Self-validating plugins, for the win!
> Also, regarding the UI of the plugins admin page itself I've attached
> a graphic with what I was hoping to get one of our designers to take a
> crack at.
If one has a lot of plugins, it might be annoying to scroll down past
the list of active plugins to find the inactive plugin you want to
activate...
Could we put the inactive and active lists side-by-side? This is a
metaphor used in other applications, and I think it makes sense. We
could separate the two columns with the "plugin details" section in the
middle; though I think it might be annoying to have to click each plugin
to see it's details...
Owen Winkler
>
> > I'm not crazy about how we already store theme data in the database.
> > I can't remember why we're doing that. Does anyone remember? Is it
> > too late to go back?
>
> Someone thought this was a good idea. I forget who. It's not
> documented well, so whoever wants to own this should step forward. I'd
> be willing to evaluate any better ideas that might be suggested.
It would be nice if we used a similar system for both themes and plugins.
>
> If one has a lot of plugins, it might be annoying to scroll down past
> the list of active plugins to find the inactive plugin you want to
> activate...
>
> Could we put the inactive and active lists side-by-side? This is a
> metaphor used in other applications, and I think it makes sense. We
> could separate the two columns with the "plugin details" section in the
> middle; though I think it might be annoying to have to click each plugin
> to see it's details...
The only thing about this design that I'm really attached to is that
the UI specific to the plugin itself appears inside the plugin
management page. I don't like the idea of encouraging plugins to
extend our main menus to include a page that has a single checkbox on
it as their UI as in some other blog softwares.
After you've seen the plugin information once, I don't think it needs
to appear on the page full-time. Maybe some DHTML expanding box with
the metadata can appear when you select the plugin instead of
displaying it in a separate area entirely? I'm open to other ideas
for how that appears, but I really want to keep the idea that the UI
for the plugin itself appears somewhere inside the Plugins page in the
admin, and not on some separate page. This is something that I think
other software does wrong, and something that I've fought with a lot
when writing my own plugins.
If we can figure out a way to display the active/inactive plugin lists
side-by-side (or maybe toggle the list?) that's fine by me. I really
liked some of Khaled's initial designs for theme selection - the ones
with that had the active/selected theme showing a little arrowhead
pointing at the metadata in a column to the left. If we can come up
with some nice UI for this page, too, that would be great.
Owen
Peter Westwood
The way SK2 plugins work for configuration works very well in this way -
with options being standard or advanced as well.
westi
--
Peter Westwood
http://blog.ftwr.co.uk