[geeklog-devel] Plugin Version Control and Dependencies (featurerequest #0001154)

[Vincent Furia]

I'm with Randy. I think a single new API call should be sufficient.

-Vinny

On Fri, Jan 21, 2011 at 11:13, Randy Kolenko <Randy.Kolenko at nextide.ca>wrote:


>  Just out of curiosity – why store anything in a table?

>

>

>

> The information required to install a plugin is easily pulled back by the

> plugin admin page by querying each plugin, and populated on the screen.  If

> a plugin is missing a dependency, don’t allow it to be installed and simply

> show the dependency information below the plugin and the associated status

> of each dependency (installed, disabled, missing etc).

>

>

>

> Like I noted before, we’ve done all this with Nexpro – the plugin page is

> all that really needs to be updated to support hiding the install button and

> showing the dependencies.  For Nexpro, each config file for each plugin has

> its own dependency list.  We do a version_compare and determine if the

> required plugin is there or not in the autoinstall.php file.

>

>

>

>

>

> *From:* Rouslan Placella [mailto:rouslan at placella.com]

> *Sent:* Friday, January 21, 2011 11:41 AM

> *To:* Geeklog Development

> *Subject:* [geeklog-devel] Plugin Version Control and Dependencies

> (featurerequest #0001154)

>

>

>

> I'd like to implement the dependency checks for geeklog plugins (bug

> #0001154).

> So below I wrote down some things that I think I'll have to do for this.

> Feedback? Suggestions? Opinions? Tips?

>

> Thanks,

> Rouslan.

>

> THINGS TO DO (or to keep in mind):

> * Create two database tables:

> Store each plugin's dependencies in one table

> and each plugin's log from the latest install attempt in the other table

>

> TABLE plugin_dependencies

>   pi_name      varchar(30) // Name of the plugin to which an entry belongs

>   type         varchar(20) // 'geeklog', 'plugin', etc...

>       require      varchar(30) // name of the required plugin (leave empty

> if $type is 'geeklog')

>   version      varchar(20) // version of the required plugin

>   operator     varchar(10) // type of comparison, e.g: ">=" or ">"

>

> TABLE plugin_install_log   // here we save custom messages that are

> generated when a plugin's install function is called

>   pi_name      varchar(30)

>   type         varchar(20) // 'notice', 'info', 'warning', 'error', etc...

>   title        TEXT        // a title

>   msg          TEXT        // a message

>

>

> * Create a new plugin API call: plugin_dependencies_pluginname()

>     The plugin can return a two-dimentional array containing its dependency

> information and it's install log.

> Sample usage in the plugin would be:

> <?php

> // plugins/foo/autoinstall.php:

> ...

> function plugin_dependencies_foo()

> {

> ...

> return array(

> // This array says that the plugin 'foo' requires Geeklog version greater

> than or equal to 1.8.0

> array( 'geeklog' => 'core', '1.8.0' => '>=' ),

>

> // This array says that the plugin 'foo' requires the calendar plugin with

> version greater than 1.0.0

> array( 'plugin' => 'calendar', '1.0.0' => '>' ),

>

> // There can be multiple dependencies

> array( 'plugin' => 'socnet', '1.0.0' => '>=' ),

>

> // A message from the plugin regarding custom dependency checks

> // $type can be 'notice', 'info', 'warning', 'error', etc...

> array( 'message' => 'error', 'a title' => 'a message' ),

>

> // There can be multiple messages

> array( 'message' => 'info', 'another title' => 'another message' )

>

> /*  The settings will be saved to 'plugins_dependencies' table and

>                     the messages to 'plugins_install_log'  */

> );

> }

> ...

> ?>

>

> * Introduce a function to update and resolve dependencies, as well as

> ensuring that the plugins are loaded in the correct order.

>     Call this function:

> * when enabling/disabling a plugin

> * when installing/uninstalling a plugin

> * when changing plugin load order

> * when loading plugins?

>

> * Add the "plugin editor" to uninstalled plugins.

> * If there was an install attempt and it failed, show the entries from the

> "plugin_install_log" table there.

> * When warning about unresolved dependencies. Offer the options to: "try to

> resolve", "proceed anyway" and "cancel operation".

> * Add a clear_install_log($plugin) function and use it before each install

> so that there is only one log entry per plugin.

> * In the plugin admin, make it obvious when there is a message that was

> saved during the install and it can be viewed.

>

> * Show dependency information in the plugin editor for enabled plugins

>

> * Show the install log in the plugin editor for enabled plugins

>     It'll probably say: "Installation was successful." only, most the time,

> but it could be useful to add custom information messages.

>

> * Keep backwards compatibility with all older plugins

>

> * Should be easy to extend to dependencies for databases (maybe even themes

> and blocks, too?).

>

> * Add a plugin_dependencies_* functions to the bundled plugins

>

> * Document everything better than this

>

> _______________________________________________

> geeklog-devel mailing list

> geeklog-devel at lists.geeklog.net

> http://eight.pairlist.net/mailman/listinfo/geeklog-devel

>

>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://eight.pairlist.net/pipermail/geeklog-devel/attachments/20110121/dc3bd518/attachment.html>