[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: <https://pairlist8.pair.net/pipermail/geeklog-devel/attachments/20110121/dc3bd518/attachment.html>