Authentication Language Strings Problem

Authentication Language Strings Problem

by Ian Robotham -
Number of replies: 5
Hi All,

We have various custom (in-house developed) authentication plugins and have our language files in /auth/<plugin>/lang/en_utf8/auth_<plugin>.php These work fine on the manage authentication plugins admin page and on the menu, however they don't work on the User adding/editing pages - it shows the default unresolved auth_<plugin>title string.

After a bit of looking in to one of the pages (user/editadvanced_form.php), the strings are obtained by:
$modules = get_list_of_plugins('auth');
$auth_options = array();
foreach ($modules as $module) {
$auth_options[$module] = get_string("auth_$module"."title", "auth");
}

So I did some digging into the get_string() method, and came across this:

5323 if (!in_array($module, $exceptions)) {
5324 $dividerpos = strpos($module, '_');
5325 if ($dividerpos === false) {
5326 $type = '';
5327 $plugin = $module;
5328 } else {
5329 $type = substr($module, 0, $dividerpos + 1);
5330 $plugin = substr($module, $dividerpos + 1);
5331 }
5332 if (!empty($rules[$type])) {
5333 foreach ($rules[$type] as $location) {
5334 $locations[] = $CFG->dirroot . "/$location/$plugin/lang/";
5335 }
5336 }
5337 }
Now since we are passing in "auth", line 5325 will evaluate to true, meaning we are going to be looking for our language strings in $CFG->dirroot . "/$location/auth/lang/ and looking at places_to_search_for_lang_strings(), passing in '' means it looks in mod.

So I tried this out, by putting our language strings in /mod/auth/lang/en_utf8/auth.php and this works fine - the strings appear ok.

Is this really the intended behaviour or is it (as I suspect) a bug? If it is a bug, which is the best/preferred way to fix this - is it to:
  1. add an additional test to get_string() to check for "auth" coming in and redirecting it to the appropriate file.
  2. change the places where it's getting the string, to use whatever method is used by the manage auth plugins page (if so can somebody point me to where this is - I'm a bit confused with the $page =& $adminroot->locate($section); and where the actual files for this are!)
  3. Some other way - suggestions please!
We're looking to fix this and then contribute it back to the community, so if you can give me your thoughts I'd be grateful.

Thanks in advance,

Ian
Average of ratings: -
In reply to Ian Robotham

Re: Authentication Language Strings Problem

by Tim Hunt -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
Is this really the intended behaviour?

NO.

I think the code that gets the plugin name should be changed to something like

$auth_options[$module] = get_string("auth_$module"."title", "auth_$module");

Then, it should look in auth/$module/land/en_utf8/auth_$module.php.
Average of ratings: -
In reply to Tim Hunt

Re: Authentication Language Strings Problem

by Ian Robotham -
Thanks for your reply.

I've tried that and whilst it solves the problem for all custom plugins, it then can't find the language strings for the core plugins (I think this is due to it looking for files called auth_<plugin>.php in the various language locations, whereas they are all located in a single auth.php file).

I then thought what about giving it a custom path to look in, however because the "module" is still set as auth, it is looking for auth.php files just in the local auth plugin folders (/auth/<plugin>/lang/en_utf8/auth.php) however as these files are called auth_<plugin>.php it doesn't solve it.

I've had a dig around in auth_plugin_base and spotted that there is a get_title() function in there, which basically checks the return value from get_string() and checks if it is a [[]] type and looks in the plugin folder if it is. So I guess there are two options:
  1. Create an instance of each plugin and call getTitle() on it - not the most efficient method
  2. Copy the code from auth_plugin_base - maybe slightly less maintainable if significant changes to naming etc. of auth plugins.
I'm planning on using #2, unless you (or anybody) can think of a better way/reason why not to do this.

Thanks,

Ian
Average of ratings: -
In reply to Ian Robotham

Re: Authentication Language Strings Problem

by Ian Robotham -
In case anybody stumbles across this from a search or whatever, this is recorded in the tracker along with a patch:

http://tracker.moodle.org/browse/MDL-18273
Average of ratings: -
In reply to Ian Robotham

Re: Authentication Language Strings Problem

by Susana L. -
I also had that problem. Moodle 1.9.5 fixes the problem from add/editing user screen. But i still have {{custompluginame}} on editing plugin page. Even if i add the string to my auth_custompluginame.php file i still see {{custompluginame}} on edit plugin page...
Average of ratings: -
In reply to Ian Robotham

Re: Authentication Language Strings Problem

by Darko Miletić -
The issue is backu with us in Moodle 1.9.6+. I reopened the issue.
Average of ratings: -