[geeklog-devel] Plugin Version Control and Dependencies (featurerequest #0001154)
vfuria at gmail.com
Sat Jan 22 00:36:30 EST 2011
I'm with Randy. I think a single new API call should be sufficient.
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
> So below I wrote down some things that I think I'll have to do for this.
> Feedback? Suggestions? Opinions? Tips?
> 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:
> // 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the geeklog-devel