Local Customisations

Local Customisations

by Dan Poltawski -
Number of replies: 7

I discovered the existence of the incredibly useful local/ folder and useful locallib hooks earlier today after seeing Tim's Commit to xmldb. This was quite frustrating as i've written modifications which have required DB table creation and really could've used that hook point!

So in the spirit of preventing others from suffering the same fate as me, i've (somewhat poorly) started Development:Local_customisation in the wiki. Could developers who know about these local hooks contribute so other poor souls don't need to write my_hacky_function() into db/upgrade.php too ;)

Dan



Average of ratings: Useful (1)
In reply to Dan Poltawski

Re: Local Customisations

by Tim Hunt -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
That looks fine.

They key point is to use local only as a very last resort when it really does not fit into one of the standard plug-in points.

And almost any change can be made to work as either a block or an admin report. (You can have a block that is set up so you are not allowed to add it to any page, but it is still there as a repository of code.) Some of the things that we at the OU did in local when we were younger and more innocent I would now do in other ways. Indeed, we have spent some time refactoring some of them into blocks.

Two cases where using local is OK are
* where you want to change a core database table, then you can use local/db/update.php and local/version.php, to avoid having to mess with lib/db.
* where you need some odd bits of code (functions or classes) in order that when you modify some core Moodle behaviour, you can then do some very minimal changes in core that basically just call your functions in local.
In reply to Tim Hunt

Re: Local Customisations

by Dan Poltawski -
And almost any change can be made to work as either a block or an admin report.

I don't know much about admin reports either. Can you create database tables in them? Also, is there a plug-in point for admin menu items?

In reply to Dan Poltawski

Re: Local Customisations

by Tim Hunt -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
> Can you create database tables in them?

No.

To learn about admin reports, look in the modules and plugins database for some examples. It should be clear what to do just be looking at examples. Basically you just need to create a folder in admin/report containing an index.php file and a lang folder. E.g. http://cvs.moodle.org/contrib/plugins/admin/report/moduleinstances/

However, you can include more code if you need it. E.g. http://moodle.org/mod/data/view.php?d=13&rid=1005

> is there a plug-in point for admin menu items?

No, you have to hack one of the files in admin/settings. At the OU we added a new page "OU site" in the admin tree under Server. We just stuck the definition in admin/settings/server.php, delineated by // ou-specific begins/ends comments, which are our convention for marking our customisations in core Moodle files. Crude, but in practice, that is never going to cause us merge problems.
In reply to Tim Hunt

Re: Local Customisations

by Dan Poltawski -

Thanks

The customisations i've done have added to admin menus and also also required their own database tables (as well as a few other patches into core stuff). Which is kinda why local/ looks perfect for what I was trying to achieve.

Out of interest, what advantages does moving local/ stuff to invisible blocks give you? And presumably having hidden blocks still means they appear in the blocks admin menu?

In reply to Dan Poltawski

Re: Local Customisations

by Tim Hunt -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
> what advantages does moving local/ stuff to invisible blocks give you?

None really. But where stuff needs some user interface, and is associated with a course, then making it a block is the right way to go, and that was the case with things we converted.
In reply to Dan Poltawski

Re: Local Customisations

by Robert Brenstein -
It would be nice to know as of which version of Moodle this is available. I mean that the documentation should state this.
In reply to Robert Brenstein

Re: Local Customisations

by Tim Hunt -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
It's been there since before the OU joined the party, which was before Moodle 1.6.