Inclusion of lib.php in settings.php

Inclusion of lib.php in settings.php

by Simon Vart -
Number of replies: 7

Hello, 


I'm starting building a new theme. I'm fairly new to Moodle. I had read a lot about it without trying it.

So now, i'm into it. Question :

I have created a generic function in lib.php which I need in : lib.php (for custom $THEME->csspostprocess) and in settings.php to generate settings.

My understand was that lib.php was including in each request, so my functions would have been accessible in settings.php. But they are not. I have undefine_functions error.

If I do require_once("$CFG->dirroot/theme/solerni/lib.php"), it works.

So, why is that my lib.php isn't included in settings.php (or called after it) ? 

Maybe I don't get yet how the differents pages and functions are loaded in Moodle (or if maybe my function is accessible via a global object ?).

If someone experienced could help me understand...


Regards

Simon

Average of ratings: -
In reply to Simon Vart

Re: Inclusion of lib.php in settings.php

by David Mudrák -
Picture of Core developers Picture of Documentation writers Picture of Moodle HQ Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers Picture of Plugins guardians Picture of Testers Picture of Translators

To be completely honest, I also lived in impression that lib.php files are included from all plugins on all requests. But Moodle seems to be more clever than that. The lib.php files are actually loaded only when needed (e.g. course format's lib.php is not loaded unless you are in a course that uses that format). But that is still quite often for many plugin types. For example the navigationlib loads lib.php files for all plugin types that are able to inject their own nodes into the navigation tree (the file must be loaded to see if the corresponding *_extend_navigation() function is provided).

So, if you really need to some functions in your settings.php, you should include your library explicitly. Also, you may probably want to use locallib.php to try and keep the lib.php as tiny as possible.

In reply to David Mudrák

Re: Inclusion of lib.php in settings.php

by Simon Vart -

Hi david,

It make sense, from a performance point of view. But the documentation is vague on this point precisely. 

I checked the lib.php of various plugins and see how they doing, and when I was sure it was not bad practice, I included my lib.php in settings.php. 

I have to use lib.php instead of localib.php because $THEME->csspostprocess search inside lib.php - so it's where the functions are supposed to be found (and if I include locallib.php into lib.php it would make no sense smile )

Thank you !

In reply to David Mudrák

Re: Inclusion of lib.php in settings.php

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

These days, better advice would be to put as much of your code as possible into classes, so you can use https://docs.moodle.org/dev/Automatic_class_loading which avoids a lot of these issues.

Average of ratings: Useful (1)
In reply to Tim Hunt

Re: Inclusion of lib.php in settings.php

by Simon Vart -

Hi Tim,


Good advice - create classes and call them when needed. 


Two questions, though : 

1/ What is the advantage from just doing an inclusion ? (as I would include this class in settings.php, it would the same as include the file in the code ? Just instead of a <code>require_once()</code> I would have <code>$mylin = new my_lib()</code> (If I understand correctly) ?

2/ I need to classes to be included in lib.php to take advantage of the phpostprocess core function. So, the lib.php is already available in some form in memory, so wouldn't I add complexity by making it loading a new class instead of just using what's instead ?

Thanks for your response. I'm into the process of understand Moodle internals and to respect them, so this is helpful.

In reply to Simon Vart

Re: Inclusion of lib.php in settings.php

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

When I say make a class, I mean make a class with a clear purpose, like

theme_mydesign_cssprocessing

Then, you can have a static method like

theme_mydesign_cssprocessing::get_processing_options();

and you can just call it anywhere without worrying about require_once.

Point 2. I don't understand. If phpostprocess is a core function, then you can call it from anywhere in Moodle.

In reply to Tim Hunt

Re: Inclusion of lib.php in settings.php

by Simon Vart -

Hi Tim,

I think I get you : having a class with an sole and clear purpose, call it instead of a whole lib.php file (which will probably end up including a whole lot of functions, purposeless in this context).

I made some typos : the function I was referring to is $THEME->csspostprocess = 'my_function';

I assume this is a core function and that this function will load my lib.php to find it. So including my lib.php in this function shouldn't be a overload (except that it will load every lib.php functions, so if I add function in this file, I would better use a class, is that what you mean ?).

In reply to Tim Hunt

Re: Inclusion of lib.php in settings.php

by Simon Vart -

Anyway, I have done what you did recommand. I have created a class inside a classes folder and refers to its static functions when needed without worrying about file inclusions.

Works like a charm, thanks you very much !