PluginConfiguration - Revision history

Tom: /* Tabs */

2011-04-05T14:49:24Z

‎Tabs

Tom: /* Tabs */

2011-04-05T14:47:44Z

‎Tabs

Tom: /* Introduction */

2011-04-04T19:53:19Z

‎Introduction

Tom: /* Introduction */

2011-04-04T19:51:49Z

‎Introduction

Tom: /* Fieldsets */

2011-02-14T21:31:52Z

‎Fieldsets

Tom: /* Fieldsets */

2011-02-14T21:29:57Z

‎Fieldsets

Tom: /* Subgroups and Fieldsets */

2011-02-14T21:22:40Z

‎Subgroups and Fieldsets

Tom: /* Initialization */

2011-02-13T14:53:08Z

‎Initialization

Tom: /* Introduction */

2011-02-13T14:51:50Z

‎Introduction

LWC: Added how to deal with existing groups when upgrading a plugin

2008-06-26T16:39:21Z

Added how to deal with existing groups when upgrading a plugin

@@ Line 69: / Line 69: @@
 === Tabs ===
-A Tab is a group of options displayed once the user has selected a plugin and a subgroup in the Configuration admin panel. The tab name must be unique for the group (i.e. plugin). You can have more than one tab per subgroup:
+A Tab is a group of options displayed once the user has selected a plugin and a subgroup in the Configuration admin panel. You can have more than one tab per subgroup:
 <pre>$my_config->add('tab_main', NULL, 'tab', 0, 0, NULL, 0, true, 'myplugin', 0);
@@ Line 77: / Line 77: @@
 The display name of a tab is taken from the corresponding entry in <code>$LANG_tab['myplugin']</code> in the plugin's language file.
-Again, there's a convention that entries for tab names should start with '<tt>tab_</tt>' while the actual name is left to the plugin author.
+Again, there's a convention that entries for tab names should start with '<tt>tab_</tt>' while the actual name is left to the plugin author. The tab name must be unique for the group (i.e. plugin) since the configuration security works off of the group and tab name.
 === Fieldsets ===

@@ Line 69: / Line 69: @@
 === Tabs ===
-A Tab is a group of options displayed once the user has selected a plugin and a subgroup in the Configuration admin panel. You can have more than one tab per subgroup:
+A Tab is a group of options displayed once the user has selected a plugin and a subgroup in the Configuration admin panel. The tab name must be unique for the group (i.e. plugin). You can have more than one tab per subgroup:
 <pre>$my_config->add('tab_main', NULL, 'tab', 0, 0, NULL, 0, true, 'myplugin', 0);

@@ Line 11: / Line 11: @@
 As of Geeklog 1.8.0 the configuration class was updated with built in tab support while still being fully backwards compatible. Group rights were also extended to these tabs. The Geeklog Configuration checks to see if a group right exists for the tab and if so, then checks to see if the user has access to the tab. For plugin authors wishing to extend this functionality to their plugins all then need to do is add a Group right in the following format:
-config.plugin_name.tab_name
+<pre>config.plugin_name.tab_name</pre>
-Where the "plugin_name is the name of the plugin and the "tab_name" is the name of the tab. Core plugins have been updated with this feature so you can check them out for a complete example.
+Where the "plugin_name" is the name of the plugin and the "tab_name" is the name of the tab. The Geeklog core plugins have been updated with this feature so you can check them out for a complete example.
 == Usage in plugins ==

@@ Line 9: / Line 9: @@
 As of Geeklog 1.5.0, there is now a common [[Configuration Class]] that provides both a GUI (graphical front end) for easy access and a database schema to store configuration settings in the database.
-As of Geeklog 1.8.0 the configuration class was updated with built in tab support while still being fully backwards compatible.
+As of Geeklog 1.8.0 the configuration class was updated with built in tab support while still being fully backwards compatible. Group rights were also extended to these tabs. The Geeklog Configuration checks to see if a group right exists for the tab and if so, then checks to see if the user has access to the tab. For plugin authors wishing to extend this functionality to their plugins all then need to do is add a Group right in the following format:
 == Usage in plugins ==

@@ Line 87: / Line 87: @@
 Again, there's a convention that entries for fieldset names should start with '<tt>fs_</tt>' while the actual name is left to the plugin author.
-While you are not required to use fieldsets they do group similar configuration items together and allow for easier readability. This is especially true if javascript is not enabled in the browser. When javascript is not enabled, all configuration items will be displayed in one long list. For this reason alone we suggest to have at least one fieldset per tab.
+While you are not required to use fieldsets, they do group similar configuration items together and allow for easier readability. This is especially true if javascript is not enabled in the browser. When javascript is not enabled, all configuration items will be displayed in one long list. For this reason alone we suggest to have at least one fieldset per tab.
 '''Tip:''' Refer to the code of the plugins bundled with Geeklog for implementation details.
 [[Category:Plugin Development]]

@@ Line 49: / Line 49: @@
 '''Tip:''' You will often need this initialization code in two places: In the installation script and when upgrading your (previously installed) plugin after the Geeklog version it's running on has been updated to 1.5.0 (or later). You may therefore want to put the code in a separate include file, e.g. <tt>install_defaults.php</tt>, as used by the plugins that are bundled with Geeklog.
-== Subgroups and Fieldsets ==
+== Subgroups, Tabs and Fieldsets ==
-As you've seen above, a plugin's configuration is called a "group" in the configuration table. The configuration options can be further sub-divided into Subgroups and Fieldsets:
+As you've seen above, a plugin's configuration is called a "group" in the configuration table. The configuration options can be further sub-divided into Subgroups, Tabs and Fieldsets:
 === Subgroups ===
@@ Line 57: / Line 57: @@
 Every plugin will need to create at least one subgroup:
-<pre>$my_config->('sg_main', NULL, 'subgroup', 0, 0, NULL, 0, true, 'myplugin');</pre>
+<pre>$my_config->('sg_main', NULL, 'subgroup', 0, 0, NULL, 0, true, 'myplugin', 0);</pre>
 This creates a subgroup "sg_main". A subgroup is displayed in the second block on the Configuation admin panel, after you click on the plugin's entry in the first block. The display name that will show up in the second block is taken from the corresponding <code>$LANG_configsubgroups['myplugin']</code> entry in the plugin's language file.
 The convention is that name of subgroup entries starts with '<tt>sg_</tt>'. The actual name is not important and is left for the plugin author to choose.
 === Fieldsets ===
-A fieldset is a group of options displayed once the user has selected a plugin and a subgroup in the Configuration admin panel. You can have more than one fieldset per subgroup:
+A fieldset is a group of options displayed once the user has selected a plugin, a subgroup and a tab in the Configuration admin panel. You can have 0, 1 or many fieldsets per tab:
-<pre>$my_config->add('fs_main', NULL, 'fieldset', 0, 0, NULL, 0, true, 'myplugin');
+<pre>$my_config->add('fs_perm_story', NULL, 'fieldset', 0, 0, NULL, 0, true, 'myplugin', 1);
 ...
-$my_config->add('fs_permissions', NULL, 'fieldset', 0, 1, NULL, 0, true, 'myplugin');</pre>
+$my_config->add('fs_perm_topic', NULL, 'fieldset', 0, 1, NULL, 0, true, 'myplugin', 1);</pre>
 The display name of a fieldset is taken from the corresponding entry in <code>$LANG_fs['myplugin']</code> in the plugin's language file.

@@ Line 41: / Line 41: @@
          DB_query ("DELETE FROM {$_TABLES['conf_values']} WHERE group_name = 'myplugin'");
-$my_config->add('my_option1', 42, 'text', 0, 0, 0, 10, true, 'myplugin');
+$my_config->add('my_option1', 42, 'text', 0, 0, 0, 10, true, 'myplugin', 0);
 ...
 </pre>

← Older revision		Revision as of 14:51, 13 February 2011
Line 8:		Line 8:

	As of Geeklog 1.5.0, there is now a common [[Configuration Class]] that provides both a GUI (graphical front end) for easy access and a database schema to store configuration settings in the database.		As of Geeklog 1.5.0, there is now a common [[Configuration Class]] that provides both a GUI (graphical front end) for easy access and a database schema to store configuration settings in the database.
		+
		+	As of Geeklog 1.8.0 the configuration class was updated with built in tab support while still being fully backwards compatible.

	== Usage in plugins ==		== Usage in plugins ==

@@ Line 8: / Line 8: @@
 As of Geeklog 1.5.0, there is now a common [[Configuration Class]] that provides both a GUI (graphical front end) for easy access and a database schema to store configuration settings in the database.
 == Usage in plugins ==
@@ Line 34: / Line 33: @@
 == Initialization ==
-During installation of a plugin, it will have to create a new group for its configuration and then add all of its config options:
+During installation/upgrade of a plugin, it will have to create a new group for its configuration and then add all of its config options:
 <pre>$my_config = config::get_instance();
-if (!$my_config->group_exists('myplugin')) {
+if ($my_config->group_exists('myplugin')) {
-    $my_config->add('my_option1', 42, 'text', 0, 0, 0, 10, true, 'myplugin');
+$my_config->add('my_option1', 42, 'text', 0, 0, 0, 10, true, 'myplugin');
-    ...
+...
 </pre>
 See the description of the [[Configuration Class]] for details.