Issue Details (XML | Word | Printable)

Key: MDL-16438
Type: Bug Bug
Status: Reopened Reopened
Priority: Minor Minor
Assignee: Petr Skoda
Reporter: Penny Leach
Votes: 1
Watchers: 9
Operations

Add/Edit UI Mockup to this issue
If you were logged in you would be able to see more operations.
Moodle

centralise information about plugins to avoid duplication

Created: 10/Sep/08 06:44 PM   Updated: 01/Sep/09 04:13 AM
Return to search
Component/s: General
Affects Version/s: 2.0
Fix Version/s: 2.0

File Attachments: 1. Text File plugins_cleanup9.patch (103 kB)

Issue Links:
Dependency
Relates

Participants: Anthony Borrow, Dan Poltawski, David Mudrak, Eloy Lafuente (stronk7), Nicolas Connault, Penny Leach, Petr Skoda and Tim Hunt
Security Level: None
Resolved date: 19/Jun/09
Affected Branches: MOODLE_20_STABLE
Fixed Branches: MOODLE_20_STABLE

Sub-Tasks  All   Open   
 Sub-Task Progress: 
No sub-tasks match this view.

 Description  « Hide
From a conversation in jabber and following on from MDL-16392

It would be good to have an array somewhere containing all information about plugins, where their db directories are etc. At the moment get_db_directories seems to contain most of this information but there are other places in moodle that duplicate this (the example was events_load_def).

If we could maintain *one* array containing this information and then a few helper functions around it we could potentially:

a) remove a lot of duplication
b) make it easier to add new plugin 'types' later without having to add db location information in muliple places

 All   Comments   Change History   Version Control      Sort Order: Ascending order - Click to sort in descending order
Penny Leach added a comment - 10/Sep/08 06:45 PM
adding watchers spam ping

Tim Hunt added a comment - 11/Sep/08 10:04 AM
Martin is happy for me to add this to the end of my Moodle 2.0 todo list.

Dan Poltawski added a comment - 07/Jan/09 10:45 PM
Just linking this to MDL-16487 - which is a bug I created mentioning that the plugins check during install/upgrade is outdated. I'm pretty sure we'd need to improve that page a bit to make it more useful with all our plugin types though!

Eloy Lafuente (stronk7) added a comment - 16/Jun/09 06:31 PM
Note get_db_directories(MDL-19346) is using, since some weeks ago () get_plugin_types() and that should be considered the standard way to detects allowed paths everywhere.

Ciao


Tim Hunt added a comment - 16/Jun/09 08:02 PM
Note, get_plugin_types() uses different prefixes than string_manager for a few plugin types (e.g. mod/quiz/report) which is potentially confusing. Also, the lists in get_plugin_types() and string_manager include different types. This worries me.

I also think it should be moved out of adminlib.php, since It is probably needed in places where you don't need the rest of adminlib.php. I will probably move it to moodlelib.php if not one objects.


Petr Skoda added a comment - 16/Jun/09 08:51 PM
mod/quiz/plugin is not a good example - it is hardcoded "module subplugin" in one specific module, hopefully similar uses in resource and asignment will be eliminated soon.

anyway I agree this code needs a bit of cleanup and since it is me who introduced it working on solution now...


Tim Hunt added a comment - 16/Jun/09 10:45 PM
Petr, you asked for it

Also, can I make an additional request for a get_plugin_dir function that does

quiz -> mod/quiz
qtype_shortanswer -> question/type/shortanswer

and so on. Thanks.


Petr Skoda added a comment - 17/Jun/09 02:54 PM
key changes are:
  • function get_plugin_types($fullpaths=true) now returns full paths by default
  • function get_plugin_types() supports module subtypes - no more hardcoding of quiz reports and friends
  • new function get_plugin_directory($plugintype, $name, $fullpaths=true)
  • new function get_plugin_list($plugintype, $fullpaths=true)
  • normalized component values (aka full plugin names) in capabilities, events and messaging tables
  • fixed assignment and quiz plugin names
  • fixed savepoint version bug
  • get_string() separation of full reports and course reports
  • plugin support everywhere
  • local/ support completely replaced by plugins in /local/xxxx/*

This code is not tested much,going to test it more today and fix regressions



Tim Hunt added a comment - 18/Jun/09 03:21 PM
Code review comments from looking at the patch
  • http://docs.moodle.org/en/Development:Coding_style#Foreach shows space around => in foreach loops. (foreach ($modules as $module=>$moduledir)
    Unknown macro: { should be foreach ($modules as $module => $moduledir) {) * Instead of changing {code} $mods = get_list_of_plugins('mod'); if (!in_array(strtolower($modulename), $mods)) { {code}
    to
    $mods = get_plugin_list('mod');
    
            $mods = array_keys($mods);
    
             if (!in_array(strtolower($modulename), $mods)) {

    you could do
    
    

    $mods = get_list_of_plugins('mod');
    if (!array_key_exists(strtolower($modulename), $mods)) {{code}}
  • Or, is it worth making a plugin_exists($type, $modulename) function? (No need to get a list of all plugins if you just want to know whether one exists.)
  • Similarly, you could write function get_plugins_with_file($type, $filename), so you can say things like get_plugins_with_file('local', 'cron.php'); get_plugins_with_file('gradeimport', 'lib.php'); Would let you delete if(file_exists(...)) code from lots of other places.
  • case FEATURE_MOD_SUBPLUGINS: return array('quiz'=>'mod/quiz/report'); is really nice!
  • Surely we don't need the if in
    if ($mods = get_plugin_list('mod')) {
    
            foreach ($mods as $mod=>$moddir) {

    I hope get_plugin_list('mod') returns an empty array when there are none.

  • @param string $component full plugin name, examples: 'moodle', 'mod_forum'

'mod_forum' is not consistent with how get_string has always worked.

  • get_cached_capabilities, the new logic here looks broken. Oh, I see, will you force a complete reload of the table, so the contents of the component field is updated for all rows?

... OK, am up to line 815 of the patch, and need to take a break. More later.


Petr Skoda added a comment - 18/Jun/09 03:31 PM
  • coding style - oki, going to change my style
  • mod - I did not want to do major refactoring at the same time, sometimes I resorted to array_keys - lazy and greater danger of regressions - but in general I agree
  • plugin_exists() - yes good idea
  • get_plugin_with_file() - yes, good idea
  • mod always exist - the same as $mod above
  • component string were previously "mod/forum", I personally hate the missing "mod_" prefix in string, tables and everything because it may cause collisions
  • get_cached_capabilities was buggy in fact because it did not use component string, you could not define mod/forum:something outside of forum - local hooks

Petr Skoda added a comment - 18/Jun/09 03:45 PM
hmm, I think we could standardize the "component name" - moodle, mod_forum, block_something (we could add automatic conversion of forum to mod_forum for BC reasons)
so instead of get_plugin_directory($type, $plugin, $fullpath) would be get_component_directory($component, $fullpath);

get_plugin_types($fullpaths=true)
get_plugin_list($plugintype, $fullpaths=true, $withfile=null)
get_component_directory($component, $fullpaths=true)


Petr Skoda added a comment - 18/Jun/09 03:57 PM
hmm, we could have both - get_plugin_directory() and get_component_directory() which accepts 'moodle' and unittest hooks as extra features

Tim Hunt added a comment - 18/Jun/09 04:34 PM
  • It seems that the old get_list_of_plugins is still there. Why? (Backwards compatibility, I guess.)
  • Wow! locallib.php is completely gone. Is the information from all the useful comments preserved somewhere (in updated form)? I guess it should be on moodle docs.
  • $plugs = get_plugin_list($type); I would prefer the variable name $plugins, but I guess the above comment about refactoring applies.
  • javascript-mod.php is a bit of a nasty hack. I am hoping to phase it out and let people use $PAGE->requires instead. (Should be better performance than doing is_readable on a file in about a 100 different folders. Therefore, can we leave this doing only mod, block and filter for backwards compatibility.
  • Diffstat says:
    48 files changed, 467 insertions, 763 deletions
    300 lines of code saved. Very nice.

In summary, this is brillant. Please get it finishded, tested, and checked in soon

Of the above comments, the only one I feel strongly about is the javascript-mod.php one. Thank you.


Petr Skoda added a comment - 18/Jun/09 04:37 PM
  • get_list_of_plugins() is there because it is used for lang and otehr custom types, we need it for BC too - those are not true plugins
  • yes locallib info needs to be stored somewhere, locallib.txt ?
  • yes, longer names are better

Tim Hunt added a comment - 18/Jun/09 04:42 PM
1. Ah, so now get_list_of_plugins is needed, but has a confusing name. Please make sure the PHPdoc comment explains.
2. Martin suggested local/readme.txt. Seems sensible to me.

You did not comment on the javascript-mod.php bit. I hope that means you agree.


Petr Skoda added a comment - 18/Jun/09 04:50 PM
1. sure - doing
2. adding local might cause problems in CVS updates, could it? I intentionally did not put anything into "/local/", I guess we should ask GIT people too

Petr Skoda added a comment - 18/Jun/09 04:55 PM
javascript - sure, I trust you completely :-D

Tim Hunt added a comment - 18/Jun/09 06:11 PM
I think becuase of the way CVS only tracks files, adding local/readme.txt will only cause problems for people who already have a file called exactly that.

Petr Skoda added a comment - 18/Jun/09 06:15 PM
ok, great, going to add it there, we can revert it anytime later if really needed, thanks

Petr Skoda added a comment - 18/Jun/09 06:15 PM
I prefer when all up-to-date info is in cvs including this local customisation info

Petr Skoda added a comment - 19/Jun/09 10:28 PM
committed into cvs, thanks a lot everybody
please test and report any problems

thanks again


Tim Hunt added a comment - 19/Jun/09 10:37 PM
Yay! thanks Petr.

Nicolas Connault added a comment - 25/Jun/09 09:11 AM - edited
Petr, this doesn't seem to work with the assignment module.

In mod/assignment/lib.php line 3140, you use

$assignmenttypes = get_plugin_list('assignment');

This always returns an empty array, no matter what is in mod/assignment/type

Delving a bit deeper, in lib/moodlelib.php lines 6841-6847, we see that there is possible way that get_plugin_list('assignment') could return anything, no matter was exists in mod/assignment.


Tim Hunt added a comment - 25/Jun/09 10:53 AM
Nico, there is a possible way, but it is commented out. Lines 6791-6801.

I wonder why Petr commented that out?


Petr Skoda added a comment - 25/Jun/09 03:08 PM
testin get_plugin_list('assignment'); ...

Anthony Borrow added a comment - 29/Aug/09 02:56 PM
In relation to MDL-20152, I wonder if we should add something like gformat for glossary formats to the get_plugin_types function. I am thinking along the lines of:

'gformat' => 'mod/glossary/formats',

Peace - Anthony


David Mudrak added a comment - 31/Aug/09 09:22 PM
Anthony - I would suggest using "glossaryformat" plugin type. What would you guess a "wgrading" means? IMO "workshopgrading" is better (self-explanation), even longer.

David Mudrak added a comment - 31/Aug/09 09:25 PM
moodle_needs_upgrading() ignores subplugin requirements. IMO the subplugin's version.php should specify the minimal (and optionally maximal) supported parent plugin version. So the logic is: subplugin declares the required plugin's version, the plugin declares the required Moodle version.

Anthony Borrow added a comment - 01/Sep/09 12:49 AM
David - I agree I like glossary_format better but was trying to be 'consistent' with qformat which I am not a fan of. Generally speaking we do a very good job of keeping the code readable. I thought gformat was closest to qformat (question) but I believe I mentioned this previously to someone (perhaps Tim) and was told that it would be difficult to change. In any case, I just wanted to make a plug for making the glossary formats as plugin friendly as possible. Peace - Anthony

David Mudrak added a comment - 01/Sep/09 03:27 AM
Anthony - use glossaryformat with no underscore. The underscore is used as a separator between plugintype_pluginname. So for example mod/glossary/formats/plain can be refered as glossaryformat_plain.

Anthony Borrow added a comment - 01/Sep/09 04:13 AM
David - Yep, I see why glossaryformat works better - good catch. Thanks and congrats on working with HQ! Peace - Anthony