anybody interested in local/* customisations of moodle, please have a look at http://docs.moodle.org/en/Development:Local_customisation#Local_plugins_in_2.0_proposal
This proposal is a byproduct of my recent attempt to cleanup handling of plugins in Moodle core (MDL-16438).
Please post your comments, objections and ideas here.
Thanks a lot
If you want to see example of a currently in use 'local plugin' when thinking about backwards compatbility, one of ours is in contrib: cvs:/contrib/patches/cleo_mis_tool/
Definitely agreed, here's a few points:
1) We use local upgrade significantly to modify core db tables, and, yes, I understand this is at our own risk, but I bet lots of other people do it too.
Just one 'edge case' issue... I agree that upgrade should run at consistent time (after everything else), however I wonder if there should be a 'pre-upgrade' event hook that local could use. This would deal with situations where we have done something evil to a local table and it breaks the core update.
pre-upgrade: local event handler undoes evil thing to table
upgrade, core: standard upgrade changes table and now works
upgrade, local: local upgrade re-applies evil change to table
probably not an absolute requirement or anything, but it might help if possible. However this would require for the event system to be in a stable state (or at least capable of recovering) when there has been a code change but no db change yet... which perhaps is why not using the event system has been so popular.
2) I guess that where local plugins *do* want a user interface, they are supposed to achieve this by defining a settings.php? (Which could then include links to their other scripts or whatever.) Which is something you listed as a local feature but haven't said how it will work yet? That's fine, just checking.
I would say this is going to be a big migration task for us but in fact I think we will throw away local/* when we finally upgrade to 2.0, and put back anything that we can't do without one feature at a time, creating new plugins as we go... and somehow somehow work out a database migration strategy... so frankly, changing local to a plugin system doesn't make much difference as we would basically have to redo it anyhow.
1/ we could create a special one time local/upgrade_pre20.php script which would be executed before main upgrade. This would solve current migration to plugins needs and in the future we could add general preupgrade.php support into plugin db directories, in fact we could add it to all plugins just in case somebody is doing something really weird with modules too
2/ yes settings.php support is already in my patch, we need to pinpoint all other places where local plugins might appear, I have added list of such places to wiki already
thanks for the feedback!
i would like to have some minor modifications related to roles in local customisations:
- Add a section in roles capabilities list for the local customization. It is to say the new capabilities added from local/xxx/db/access.php don't appear
in a section called Course in the list of capabilities but in a section called xxxx title (defined in local/xxxx/lang/en_utf8/local.php in any way, for example, $string[local:name]).
- Nowadays in local customisations you can add capabilities like mod/forum:whatever or moodle/course:whatever and not only like moodle/local/whatever. Would be a good idea that a capability like mod/forum:whatever appears in Forum section in capabilities list, moodle/course:whatever in Course section in capabilities list, and so on? Perhaps it would be problematic with texts related to this capabilities.
both your 1. and 2. are valid requests, but I think it would be better to deal with these later during my proposed roles, capabilities and enrolment improvement.
Thanks for feedback, I agree these should be solved later in 2.0dev.
Thanks and regards.
1. Maybe add a plugin checker file to admin block under plugins that prints the print_plugin_tables. It would be nice to run this BEFORE upgrading. Whenever I want to upgrade now, I just have to scan down the lists of plugins and see what non-standard plugins are there.
2. Add a column to the plugins pages tables after the Settings column called Info or Help with a link to plugin file. This file could include updated info, author info, help/instructions, etc. It would be nice if this file could be called when upgrading too--maybe before settings.php with a link to configure the plugin that goes to settings.php.
Sorry if I am just being dense, but I cannot really understand what is an example and what is required in the documentation for local plugins. For example, is the "/db" directory that appears in the examples just an example, or must there be this intervening level of file structure?
Specifically, can I get by with just the following files for my local plugin "xxx"--
and can I place some very specific files in a subdirectory of my own naming, e.g.
I do not need to worry about upgrades and installation scripts, and apart from configuration settings in the mdl_config_plugins table I do not write to the database or create any new tables. Also, there are no events, no web services, etc.
Would this work ok?
Thanks so much for your help.
work in the versio.php file to control cron execution?
work in the versio.php file to control cron execution?"
It will if you're using the lib function for cron:
lib.php: function <pluginname>_cron(), in your example: local_xxx_cron()
cron.php is legacy and not bound by the restrictions placed by $module->cron. It will run every time cron does
Also, if it's a local plugin, and not a "mod/" type plugin, then in version.php you'll want to be using the variable $plugin for setting the version/cron/etc. $module is for mod/'s only.