Plugin Autoinstall - Revision history

Roccivic at 14:58, 2 May 2011

2011-05-02T14:58:43Z

Roccivic at 21:10, 13 March 2011

2011-03-13T21:10:44Z

Roccivic: updated plugin dependecy and version control

2011-03-13T21:08:42Z

updated plugin dependecy and version control

Roccivic: better code snippet

2011-02-06T14:40:06Z

better code snippet

Roccivic: Added "Plugin dependencies and version control" feature information

2011-02-06T14:39:02Z

Added "Plugin dependencies and version control" feature information

Dirk: added a link to the plugin auto-uninstall function

2009-02-23T15:34:47Z

added a link to the plugin auto-uninstall function

Dirk: added link to configuration

2009-02-22T09:39:37Z

added link to configuration

Dirk: Added category

2009-02-22T09:37:39Z

Added category

Dirk: documented remaining functions

2009-02-22T09:36:34Z

documented remaining functions

Dirk: missing word

2009-02-21T22:39:26Z

missing word

@@ Line 87: / Line 87: @@
 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.
-'''Plugin dependencies and version control'''
+=== Plugin dependencies and version control ===
 Since Geeklog 1.8.0, a new and optional array, $requires, is available. It must contain dependency information for a plugin.

@@ Line 141: / Line 141: @@
          // Or you might lock out some of the capabilities of your plugin
          array('db' => 'mysql'),
          array('db' => 'mssql', 'version' => '9.0'), // At least SQL Server 2005
-         array('db' => 'pgsql', 'version' => '7.3', 'operator' => '>')
+         array('db' => 'mssql',
      );

@@ Line 80: / Line 80: @@
 The <code>$tables</code> array obviously lists all the table names used by the plugin (note that the names are given without the <code>$_DB_table_prefix</code>). Geeklog will add these tables names (with the proper prefix) to the global <code>$_TABLES</code> 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 <tt>functions.inc</tt> file.
 '''Plugin dependencies and version control'''
-Since Geeklog 1.8.0, a new and optional array, $requires, that can contain dependency information for a plugin. Each dependency is stored inside this array as another array. Here's an example:
+Since Geeklog 1.8.0, a new and optional array, $requires, is available. It must contain dependency information for a plugin.
 <pre>
 ...
      $requires= array(
-         // This plugin requires a version greater than 1.0.0 of 'someplugin'
+         // This plugin requires another plugin, 'someplugin', and supports MySQL and PgSQL databases.
-         array('name' => 'someplugin', 'version' => '1.0.0', 'operator' => '>'),
+         array('plugin' => 'someplugin'),
-         // The default 'operator' is '>='
+You can define any particular range of versions as the requirements for your plugin by adding the 'version' and 'operator' indeces to the arrays. Here's a more complex example:
-         // This plugin also requires a version greater than or equal to 1.0.0 of 'someotherplugin'
+<pre>
-         array('name' => 'someotherplugin', 'version' => '1.0.0'),
+...
          // Multiple dependencies are allowed for the same parent plugin
          // The below line ensures that only 'someplugin' with version less than 2.0.0 is used
-         array('name' => 'someotherplugin', 'version' => '2.0.0', 'operator' => '<')
+         array('plugin' => 'someotherplugin',
      );
@@ Line 106: / Line 151: @@
          'mappings'  => $mappings,
          'tables'    => $tables,
-         'requires'  => $requires
+         'requires'  => $requires // Add the dependency information to the installation parameters here
      );
 ...</pre>
 '''Note:''' Expect this function to be called more than once during installation. Also, the fact that the function is being called at all does not necessarily mean that the plugin will actually be installed.

@@ Line 140: / Line 140: @@
 <pre>function plugin_compatible_with_this_version_foo($pi_name) {
-    if (!function_exists('PLG_resolveDependencies')) {
+    if (function_exists('PLG_resolveDependencies')) {
         COM_errorLog('Plugin "foo" requires at least Geeklog 1.8.0, but you are running an older version.');
         return false;
+    }
 }</pre>

@@ Line 80: / Line 80: @@
 The <code>$tables</code> array obviously lists all the table names used by the plugin (note that the names are given without the <code>$_DB_table_prefix</code>). Geeklog will add these tables names (with the proper prefix) to the global <code>$_TABLES</code> 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 <tt>functions.inc</tt> file.
 Finally, all these arrays are wrapped into another array and returned from the autoinstall function.
@@ Line 106: / Line 136: @@
 The function should return <code>false</code> when the plugin requires a more recent Geeklog version. Return <code>true</code> if installation on the current Geeklog version is okay.

← Older revision		Revision as of 15:34, 23 February 2009
Line 125:		Line 125:

	Where the <code>plugin_initconfig_foo</code> function is implemented in a <tt>install_defaults.php</tt> file, that handles creation and updates of the plugin's config GUI elements.		Where the <code>plugin_initconfig_foo</code> function is implemented in a <tt>install_defaults.php</tt> file, that handles creation and updates of the plugin's config GUI elements.
		+
		+
		+	= Also see =
		+
		+	* [[Plugin Auto-Uninstall]]


	[[Category:Plugin Development]]		[[Category:Plugin Development]]

@@ Line 110: / Line 110: @@
 == plugin_load_configuration_ ==
-This function only needs to be implemented by plugins that use the Configuration GUI. A typical implementation would look like this:
+This function only needs to be implemented by plugins that use the [[PluginConfiguration|Configuration GUI]]. A typical implementation would look like this:
 <pre>function plugin_load_configuration_foo($pi_name)

← Older revision		Revision as of 09:37, 22 February 2009
Line 1:		Line 1:
−	~~<center>''(work in progress - scheduled for inclusion in Geeklog 1.6)''</center>~~
−
	= Introduction =		= Introduction =

Line 127:		Line 125:

	Where the <code>plugin_initconfig_foo</code> function is implemented in a <tt>install_defaults.php</tt> file, that handles creation and updates of the plugin's config GUI elements.		Where the <code>plugin_initconfig_foo</code> function is implemented in a <tt>install_defaults.php</tt> file, that handles creation and updates of the plugin's config GUI elements.
		+
		+
		+	[[Category:Plugin Development]]

@@ Line 28: / Line 28: @@
 Plugins that ship with an <tt>autoinstall.php</tt> file won't need to provide the "traditional" install script (<tt>admin/plugins/foo/install.php</tt>) unless they want to be backward-compatible with Geeklog releases prior to 1.6.
 == plugin_autoinstall_ ==
@@ Line 89: / Line 90: @@
 '''Note:''' Expect this function to be called more than once during installation. Also, the fact that the function is being called at all does not necessarily mean that the plugin will actually be installed.
 == plugin_postinstall_ ==
@@ Line 97: / Line 99: @@
 At this point, all the files are already in their correct place, the groups and permissions have been added and the plugin has been registered with Geeklog (i.e. has been added to the <tt>gl_plugins</tt> table). However, the plugin has not been loaded yet, i.e. you can not rely on any of your plugin's functions being available.

@@ Line 92: / Line 92: @@
 == plugin_postinstall_ ==
-Geeklog, armed with the information provided by the <code>plugin_autoinstall_</code> function, will take care of moving the plugin's files into their 3 standard locations, create the tables, the groups, and permissions. For any additional steps that need to performed during installation, the <code>plugin_postinstall_</code> function will be called:
+Geeklog, armed with the information provided by the <code>plugin_autoinstall_</code> function, will take care of moving the plugin's files into their 3 standard locations, create the tables, the groups, and permissions. For any additional steps that need to be performed during installation, the <code>plugin_postinstall_</code> function will be called:
 <pre>function plugin_postinstall_foo($pi_name)</pre>
 At this point, all the files are already in their correct place, the groups and permissions have been added and the plugin has been registered with Geeklog (i.e. has been added to the <tt>gl_plugins</tt> table). However, the plugin has not been loaded yet, i.e. you can not rely on any of your plugin's functions being available.