Revision as of 09:54, 12 February 2009

Introduction

Geeklog 1.6 brings two important changes regarding installation of plugins:

• Plugins can be installed by uploading their tarball (from Geeklog's Plugins Admin panel)
• Plugins can be bundled / unbundled by simply adding / removing their respective directories to / from the Geeklog tarball

In both of these scenarios, Geeklog needs a way to automatically run the install procedure for such a plugin.

The problem with the plugin install scripts used until now are that they were mainly aimed at being run by a human and that they also check permissions that simply may not be set when the install is done (e.g. when running Geeklog's install script).

The solution proposed here is the inclusion of a new file, autoinstall.php into every plugin that implements up to 4 new API functions (3 of which are optional).

autoinstall.php

The file autoinstall.php is to be located in the plugin's main directory, i.e. in the same directory as its functions.inc file:

/path/to/geeklog/plugins/
                         foo/
                             functions.inc
                             autoinstall.php
                         staticpages/
                             functions.inc
                             autoinstall.php
                         ...

Plugins that ship with an autoinstall.php file won't need to provide the "traditional" install script (admin/plugins/foo/install.php) unless they want to be backward-compatible with Geeklog releases prior to 1.6.

plugin_autoinstall_

This is the most important and mandatory API function to implement in autoinstall.php:

function plugin_autoinstall_foo($pi_name)
{
    $pi_name         = 'foo';
    $pi_display_name = 'Foo';
    $pi_admin        = $pi_display_name . ' Admin';

    $info = array(
        'pi_name'         => $pi_name,
        'pi_display_name' => $pi_display_name,
        'pi_version'      => '1.0.0',
        'pi_gl_version'   => '1.6.0',
        'pi_homepage'     => 'http://www.example.com/'
    );

    $groups = array(
        $pi_admin => 'Has full access to ' . $pi_display_name . ' features'
    );

    $features = array(
        $pi_name . '.edit'      => 'Access to ' . $pi_display_name . ' editor'
    );

    $mappings = array(
        $pi_name . '.edit'      => array($pi_admin)
    );

    $tables = array(
        'foo'
    );

    $inst_parms = array(
        'info'      => $info,
        'groups'    => $groups,
        'features'  => $features,
        'mappings'  => $mappings,
        'tables'    => $tables
    );

    return $inst_parms;
}

If you've written a Geeklog plugin before, the data provided by this function should look familiar.

The $info array provides the information that goes into the plugin's entry in the gl_plugins table. The only addition here is the $pi_display_name entry, so that we can use a nicely formatted name to present to the user instead of having to refer to the plugin by its internal and possibly abbreviated name ($pi_name).

$groups and $features simply list all the groups and features (permissions) that the plugin would like to introduce. Geeklog will create those automatically for the plugin, using the $mappings. $mappings defines which permissions to assign to which of the new groups.

The $tables array obviously lists all the table names used by the plugin (note that the names are given without the $_DB_table_prefix). Geeklog will add these tables names (with the proper prefix) to the global $_TABLES array during the install. The plugin will still have to make sure they are known after the install, e.g. by defining them in its functions.inc file.

Finally, all these arrays are wrapped into another array and returned from the autoinstall function.

With the exception of the $info array, all of these arrays are optional. Plugins that don't create any groups or tables don't need to provide $groups or $tables entries.

In case of an error during the install, Geeklog will also use this information to attempt a cleanup of the database, i.e. remove groups, permissions, etc.