Heads up: all plugin version numbers moving from config to config_plugins in head

Heads up: all plugin version numbers moving from config to config_plugins in head

by Tim Hunt -
Number of replies: 16
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
In case you don't know, config_plugins is a table in Moodle designed to take some of the load off the config table. Since all the data from config is loaded for every single moodle page that is displayed, it obviously helps performance to keep the config table as small as possible. On the other hand, all parts of Moodle need a place to store settings. The solution that was introduced some time ago was the config_plugins table, which is like config, but with an extra plugin column. That way, for example, you only need to load the quiz config settings if you are doing something that involves the quiz - well you do in HEAD, since I converted the quiz module the other day. To get at the data in the config table, you use the get/set_config functions.

Anyway, the next step I am going to do is to move all the plugintype_pluginname_version values from config to config_plugins (MDL-16411). That should save another 30+ config rows.

I mention this here for two reasons. First, it is a big scary change that might break people's development environments if I screw up, so it seemed only fair to give a warning.

Second, I wanted to give more publicity to the config_plugins table, and get/set_config, in the hope that it inspires more people to use this, rather than shoving everything in $CFG. Converting is not acutally that hard. The quiz conversion was done as part of the changes for MDL-7010. The upgrade code is http://cvs.moodle.org/moodle/mod/quiz/db/upgrade.php?r1=1.23&r2=1.24. Then you need to search your code for occurrences of $CFG->, and check them all out. If you have a more sophisitcated regular expression search available, search for /\$CFG->(?!wwwroot|dirroot|libdir|dataroot)/, which will miss out the most common $CFG variables that do not belong to your pugin.
Average of ratings: Useful (1)
In reply to Tim Hunt

Re: Heads up: all plugin version numbers moving from config to config_plugins in head

by Tim Hunt -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
Just to let you know, this is now in CVS in HEAD. Penny has already found the stupid mistake I made, which is now fixed, so we think it is working.
In reply to Tim Hunt

Re: Heads up: all plugin version numbers moving from config to config_plugins in head

by Anthony Borrow -
Picture of Core developers Picture of Plugin developers Picture of Testers
Tim - Thanks for your work on this. On the CONTRIB side, I would encourage all plugin maintainers to make use of the config_plugins table. I folks have questions they can send me a Moodle message. I switched from using the config table to using the config_plugins table with the Birthday and MRBS blocks without too much difficulty. Thanks for your work on MDL-16564. It's a small detail that makes a big difference. Peace - Anthony
In reply to Anthony Borrow

Re: Heads up: all plugin version numbers moving from config to config_plugins in head

by Tim Hunt -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
Anthony, do you think it is worth documenting what you had to do to convert your plugins in a tutorial on Moodle docs?
In reply to Tim Hunt

Re: Heads up: all plugin version numbers moving from config to config_plugins in head

by Anthony Borrow -
Picture of Core developers Picture of Plugin developers Picture of Testers
Tim - I think documentation is always worth it but in the midst of studies my time is really sparse. Essentially it was just a matter of replace $CFG->plugin_value with $cfg_blockname and populating $cfg_blockname with get_config(blockname). Folks may want to make it a global variable. With the changes in head for the admin settings everything else should be pretty straight forward. Peace - Anthony
In reply to Tim Hunt

Re: Heads up: all plugin version numbers moving from config to config_plugins in head

by Jason Hardin -
I can work up some documentation on how we implemented the config_plugins as well as some documentation on how to create a custom admin_setting. I had to do both yesterday for on of our clients external integrations.
In reply to Tim Hunt

Re: Heads up: all plugin version numbers moving from config to config_plugins in head

by Mark Nielsen -
Just some more information:
  • The admin settings class can store your settings in the config_plugins table by setting the data member "plugin" to the name of the plugin. To do this, I usually create all of my settings and assign them to an array. Then I loop through the array and assign the plugin and then add the setting to the settings page.
  • You can use modname_install() and modname_uninstall() hooks in mod/modname/lib.php to create default config_plugins settings and to cleanup your settings on the deletion of your module. Think there are similar hooks for blocks as well.
  • Looks like in HEAD you can now use mod/modname/defaults.php to create defaults in config_plugins table. For 1.9 or earlier you'll have to use the above for defaults.
Cheers,
Mark
In reply to Mark Nielsen

Re: Heads up: all plugin version numbers moving from config to config_plugins in head

by Tim Hunt -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
MDL-16564 is about making the first bullet point easier. It lets you call your settings something like 'myplugin/mysetting', rather than having to set $mysetting->plugin = 'myplugin' in a separate line of code.
In reply to Tim Hunt

Re: Heads up: all plugin version numbers moving from config to config_plugins in head

by Jason Hardin -
so is myplugin/mysetting similar to setting $config->plugin = "myplugin" ?

I have concerns with the naming convention of mod/myplugin or blocks/myblock when attempting to use javascript in settings.php. External integrations like Elluminate and several integrations we are working on use javscript and buttons to allow the user to test a connection to the external systme before saving the changes to the module or block.

The mod/myplugin creates a javascript unusable name for the html input similar to s_mod/myplugin_mysetting. I would recommend that the naming convention for settings be mod_myplugin or blocks_myplugin to make the name of the html input javascript usable.

Also is there any way to add a button and html area to the standard admin_settings_config class in core?

I have found multiple integrations that need these fields and we have to keep redefining them everytime in a seperate class for the module or block. I will create a ticket in trak for it as a new feature.
In reply to Jason Hardin

Re: Heads up: all plugin version numbers moving from config to config_plugins in head

by Tim Hunt -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
Yes, the notation myplugin/mysetting is just a simple hack to get both $setting->name and $setting->plugin into the constuctor without having to type something like new admin_setting_xxx(array('myplugin', 'mysetting'), ...) or new admin_setting_xxx('mysetting', ..., 'myplugin'); in the settings.php file. All that happens is that in the setting constructor, it does explode('/', $name), and if it gets two bits, it sets $setting->plugin.

The naming convention for settings (and for language files) is already that the plugin name is mymod an activity module or block_myblock for a block, or qtype_myquestion type for a question type, etc.

I don't quite see the purpose of a setting class that has both a HTML area and a button. Can you give an example please? If there is a good use for them, create a tracker ticket and attach a patch.
In reply to Tim Hunt

Re: Heads up: all plugin version numbers moving from config to config_plugins in head

by Jason Hardin -
Tim I was actually looking to add 2 new config types button and html area.

The button example is like what I did below:

class admin_setting_webex_button extends admin_setting {
var $js;
function admin_setting_webex_button($name, $visiblename, $description, $defaultsetting, $js) {
$this->js = $js;
parent::admin_setting($name, $visiblename, $description, $defaultsetting);
}

function get_setting() {
return true;
}

function get_defaultsetting() {
return true;
}

function write_setting($data) {
// do not write any setting
return '';
}

function output_html($data, $query='') {

$return = '<center><input type="button" onclick="'.$this->js.'" value="'.$this->visiblename.'" /></center>';

return $return;
}
}

This would be a button that executes some javascript that can be added to the settings page through require_js.

The HTML area setting would be similar to below:
class admin_setting_acxiom_confightml extends admin_setting {

var $cols;
var $rows;

function admin_setting_acxiom_confightml($name, $visiblename, $description, $defaultsetting, $rows, $cols) {
$this->cols = $cols;
$this->rows = $rows;

parent::admin_setting($name, $visiblename, $description, $defaultsetting);
}

function get_setting() {
return $this->config_read($this->name);
}

function write_setting($data) {

return ($this->config_write($this->name, $data) ? '' : get_string('errorsetting', 'admin'));
}

function output_html($data, $query='') {

global $CFG;

$CFG->adminusehtmleditor = can_use_html_editor();
$return = '<div class="form-htmlarea">'.print_textarea($CFG->adminusehtmleditor, $this->rows, $this->cols, 0, 0, $this->get_full_name(), $data, 0, true).'</div>';

return format_admin_setting($this, $this->visiblename, $return, $this->description, false, '', NULL, $query);
}
}

This would create a text area using the moodle html area similar to the front page settings, in case a block or module wants to use html displaying from the site configuration.
In reply to Jason Hardin

Re: Heads up: all plugin version numbers moving from config to config_plugins in head

by Tim Hunt -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
I was wondering why you could possibly want a JavaScript admin setting - and found the answer in the bug:

"The first would be a JavaScript button, this allows a developer working on an external integration to execute a connection test to an external system from the settings page instead of saving the changes and then attempting to add the activity to a course and getting errors. The Elluminate integration is an example of a released module that uses this test connection button using config.html. The javascript would generally be added to the page through require_js()."

This just looks like an evil abuse of the admin settings tree structures. Logically, the button and the JavaScript are part of the connection settings. Isn't it better to make a specific Ellumiate connection settings admin setting that subclasses admin_setting_configtext or whatever, and outputs the button and the specific javascript in addition to the normal controls? Hmm. I suppose the connection settings may comprise several different settings fields. In that case, a separate fake admin setting makes sense. But I still think that this is a specific one-off, and not something we need generally available in core. For example, this setting will also need to require_js the appropriate .js file. Anyway, I think that this should be done as a specific admin_setting_validate_elluminate_conn, or something, that is private to the Elluminate module.

About the HTML editor, the front page description already uses that. If we put a generic HTML edtior setting type into core, we should rewrite admin_setting_special_frontpagedesc to not be a special case, or, if there really is additional special processing that this setting needs to do, refactor it to inherit from the generic setting type you just made.

So, in summary, I would check in a patch that just did the HTML editor one, but only if the patch included refactoring admin_setting_special_frontpagedesc.

(By the way, if you just type a bug number like MDL-16661 it automatically gets linkified.)
In reply to Tim Hunt

Re: Heads up: all plugin version numbers moving from config to config_plugins in head

by Jason Hardin -
I guess Tim my question would be when does it move from a one off to we have enough integrations for it to be better in a library function if they are all doing the same thing?

We currently have 3 unreleased integrations at Moodlerooms that use this funcitonality, with probably 4-5 more integrations for clients that could benefit from the same funcitonality. There are 2 modules Elluminate and Wimba that could use the funcitoanlity. I could also see every enrollment and authenticaiton plugin adding something like this to improve Admin connectivity debugging at the settings level.

The problem these buttons are trying to solve is when my integration with an external system has multiple points of failure to connectivity. For example an Elluminate, Wimba or WebEx integration has the following connectivity failure points:
1. I recieved the wrong administrative user name and password
2. I recieved the wrong url to connect to the server
3. There is a minor typo in any of those but they were correct to begin with
4. There is a ip filter on the host server that is incorrectly setup
5. There is a firewall setup on the Moodle servers network blocking a conneciton

If any of these points fail and the integration has no way to test the connection other than creating an activity then the System administrator has no way to validate the information they entered, or recieved from the external system administrator works correctly until after adding the activity fails.
In reply to Jason Hardin

Re: Heads up: all plugin version numbers moving from config to config_plugins in head

by Tim Hunt -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
OK, there is a definite need there, but I still shudder at the thought of the ways that an execute arbitrary JavaScript button component could be abused.

Also, if a test is worth doing client-side on the click of a button, it is probably also worth doing server-side when the admin page is submitted.

So, perhaps it would be OK if we called the 'setting' something like admin_settings_validator that makes the intent clear. Although it is not actually a setting stored in the database, it is still something that needs to appear on the settings page, perhaps with an error message next to it.

When you create one and add it to the settings page, there would be some optional arguments that you pass to the constructor. One would be $clientsidevalidator. If that is set, then the a button the runs the validation JS would be output. Then $serversidevalidator would be a PHP callback to use.

Have you been following the thread about JavaScript in Moodle? Anyway, you should know about require_js so you can easily reference any JavaScript files you need.
In reply to Tim Hunt

Re: Heads up: all plugin version numbers moving from config to config_plugins in head

by Jason Hardin -
I was actually thinking about this more and talked to Michael Penney more about the idea yesterday. I realized where the idea of this being a hack is coming from. You are correct I think the js button is a hack of the settings system as well now.

My major concern now is with the accessibility of a js button on the settings page. It would be much better programmically to do what you recommended and validate the settings on submission on the server-side. Thus why the js button is a hack because validation on submission on the server side takes core modifications.

I have modified the ticket to only request the addition of the html are config setting and I will be updating the patch.

I am going to also look into what I can put together as a patch to the settings funcitonality to allow a process on the server side to test administrative settings on save.

I was thinking something along the lines of if a file called settingsvalidation.php exists it is processed or included. I will post more ideas on this as I have time, but I think this is the best way to solve the need rather than pushing for a button hack that could break Moodle's accessibility.


In reply to Jason Hardin

Re: Heads up: all plugin version numbers moving from config to config_plugins in head

by Tim Hunt -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
It would be nice to avoid the needs for an extra php file. Can't we find a way to include this in settings.php?