[geeklog-devel] Plugin Version Control and Dependencies (featurerequest #0001154)
Rouslan Placella
rouslan at placella.com
Sat Jan 22 09:09:47 EST 2011
I started a bit of work on this and, yeah, I get it. And I also see that
there is no need for that API call either. The plugins that use the new
install, return install parameters through
plugin_autoinstall_myplugin(). And they could just add the dependency
information to the array that they normally return. Then it would be
geeklog's responsibility to resolve those dependencies.
Rouslan
On Fri, 2011-01-21 at 22:36 -0700, Vincent Furia wrote:
> 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
>
>
>
> _______________________________________________
> geeklog-devel mailing list
> geeklog-devel at lists.geeklog.net
> http://eight.pairlist.net/mailman/listinfo/geeklog-devel
More information about the geeklog-devel
mailing list