|
[
Permalink
| « Hide
]
Penny Leach added a comment - 10/Sep/08 06:45 PM
adding watchers spam ping
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!
Note get_db_directories(
Ciao 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. 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... key changes are:
This code is not tested much,going to test it more today and fix regressions More info retated to local customisations at http://moodle.org/mod/forum/discuss.php?d=126017
Code review comments from looking at the patch
'mod_forum' is not consistent with how get_string has always worked.
... OK, am up to line 815 of the patch, and need to take a break. More later.
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) hmm, we could have both - get_plugin_directory() and get_component_directory() which accepts 'moodle' and unittest hooks as extra features
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.
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. 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 javascript - sure, I trust you completely :-D
ok, great, going to add it there, we can revert it anytime later if really needed, thanks
I prefer when all up-to-date info is in cvs including this local customisation info
committed into cvs, thanks a lot everybody
please test and report any problems thanks again 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. testin get_plugin_list('assignment'); ...
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 Anthony - I would suggest using "glossaryformat" plugin type. What would you guess a "wgrading" means? IMO "workshopgrading" is better (self-explanation), even longer.
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.
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
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.
David - Yep, I see why glossaryformat works better - good catch. Thanks and congrats on working with HQ! Peace - Anthony
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||