General developer forum

Proposal: local modification changes in 2.0

 
Picture of Petr Skoda
Proposal: local modification changes in 2.0
Core developersDocumentation writersPlugin developers
Hello developers and admins,

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
 
Average of ratings: -
Dan at desk in Moodle HQ, Perth
Re: Proposal: local modification changes in 2.0
Core developersMoodle Course Creator Certificate holdersMoodle HQPlugin developersTesters
Makes a lot of sense to me and I can't think any major drawbacks.

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/
 
Average of ratings: -
Picture of David Mudrák
Re: Proposal: local modification changes in 2.0
Core developersDocumentation writersMoodle HQParticularly helpful MoodlersPlugin developersPlugins guardiansTestersTranslators
My big +1 for this. Thanks for considering this Petr.
 
Average of ratings: -
Picture of sam marshall
Re: Proposal: local modification changes in 2.0
Core developersParticularly helpful MoodlersPlugin developersTesters
Hi,

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.

--sam
 
Average of ratings: -
Picture of Petr Skoda
Re: Proposal: local modification changes in 2.0
Core developersDocumentation writersPlugin developers
Hi sam!

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 wink

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!
 
Average of ratings: -
Picture of sam marshall
Re: Proposal: local modification changes in 2.0
Core developersParticularly helpful MoodlersPlugin developersTesters
1) Sounds good. I agree, general preupgrade.php for all plugins would be nice for those rare cases in future, but for immediate '2.0 upgrade' needs, the local/pre20 script would be fine. (If it wasn't implemented, most places capable of doing local development could probably hack it in themselves...)

2) great!

--sam
 
Average of ratings: -
Picture of Borja Rubio Reyes
Re: Proposal: local modification changes in 2.0
Plugin developers
Hello,

i would like to have some minor modifications related to roles in local customisations:
  1. 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]).
  2. 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.
Thanks a lot.
 
Average of ratings: -
Picture of Petr Skoda
Re: Proposal: local modification changes in 2.0
Core developersDocumentation writersPlugin developers
Hello Borja,

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.
 
Average of ratings: -
Picture of Borja Rubio Reyes
Re: Proposal: local modification changes in 2.0
Plugin developers
Ok Petr, I understand.

Thanks and regards.
 
Average of ratings: -
Picture of Chardelle Busch
Re: Proposal: local modification changes in 2.0
Core developersParticularly helpful Moodlers
There are a couple of things I would like to see:

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.
 
Average of ratings: -
Picture of Aharon Ben-Shemer
Re: Proposal: local modification changes in 2.0
 

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"--

local/xxx/version.php

local/xxx/lib.php

local/xxx/settings.php

local/xxx/cron.php

local/xxx/lan/en/local_xxx.php

and can I place some very specific files in a subdirectory of my own naming, e.g.

local/xxx/mysubdir/

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.

A

PS/ WIll

$module->cron

work in the versio.php file to control cron execution?

 
Average of ratings: -
Picture of Adam Olley
Re: Proposal: local modification changes in 2.0
 

"PS/ WIll

$module->cron

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 smile

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.

 
Average of ratings: -