Dear Anthony and Aparup,

It's been driving me potty how I can make use of both get_config and set_config in my code, be user friendly and efficient. I can use them in my configuration file, but I do have to test of their existence, the result of which is thrown away (inefficient) as I then get the value again elsewhere in the code. i.e. get_config, if not exist, set_config, then in another file 'get_config'. Then if the user wants to change the defaults, then they now need to change them in the file and remove the respective database rows. Also, this means more database read's etc, rather than a straightforward language constant.

Or, can I use standard PHP constants -> http://php.net/manual/en/language.constants.php <- instead?

Cheers,

Gareth

Or even class constants?... http://php.net/manual/en/language.oop5.constants.php

Thanks for addressing the permissions issue. For me that was the biggest concern. I suspect you were misinformed about that but I wanted to be cautious about telling folks to adjust security settings on their servers as part of installing a plugin. I do not think that should be required at all for a plugin.

As for using get_config and set_config - that is certainly less of a show stopper for me and more of a recommendation to keep $CFG from becoming overly bloated. I'll look at the update and give you some more feedback later today. Peace - Anthony

Dear Anthony,

Thanks - I'm not actually using $CFG but my own $TCCFG.

Cheers,

Gareth

Generally speaking, as I understand it, creating global variables is discouraged see http://docs.moodle.org/dev/Coding_style#Variables - I see that you are storing the column data in course_format_options and for course formats that seems the best place to me for that information even for a plugin. With plugins like the birthday block that have a set of configuration options is when get_config and set_config make the most sense to use. For now, I would say don't worry about. I will go ahead and approve the entry. When I scan the code there are some things that catch my eye and I raise them as questions. We can continue to improve upon what you have but for now it seems good to share with the community. Peace - Anthony

In the 2.4 version, the Readme.txt file still has the recommendation to change security permissions on config.php - it is also vague which config.php you are referring to (the plugin's or the core config.php). In either case, I would like to see that removed. File permissions need to be set consistently and you may want to make a reference to http://docs.moodle.org/24/en/Security_recommendations#Most_secure.2Fparanoid_file_permissions for folks. I cannot see a need to have execute permissions on a config.php file. Peace - Anthony

In any case, once the Readme.txt file is cleaned up then I think this can be approved. Peace - Anthony

Ops! Did not spot that - lost track of where I was! I'll make the corrections, disable the old versions and get back to you. Plus have a look at the Moodle docs on globals. Cheers, Gareth

Really likr this one as it makes much better use of screen real estate. One quesiton though is it possible to get the topics to go across the columns rather than down - so they would be paired (1 2) (3 4) etc down the page?

Dear Simon,

Yes it is. It is just a matter of adding the code to do this. I've recently devised and implemented the required code in Collapsed Topics for Moodle 2.4, so it is just a matter of spending a few hours transposing the code and testing.

What version of Moodle are you using?

Cheers,

Gareth

Thanks for the update Gareth, just what I needed

Hi Gareth,

We seem to have a bug in Moodle 2.4.4 Official release.
We actually have 7 Moodle instances running from a single code base, 6 are fine but one is reporting the follwoing error:

Debug info: Argument 2 passed to has_capability() must be an instance of context, null given, called in [dirroot]/course/format/columns/renderer.php on line 264 and defined
Error code: codingerror
Stack trace:

line 406 of /lib/setuplib.php: coding_exception thrown
line 355 of /lib/accesslib.php: call to default_error_handler()
line 264 of /course/format/columns/renderer.php: call to has_capability()
line 555 of /course/format/columns/renderer.php: call to format_columns_renderer->section_header()
line 116 of /course/format/columns/format.php: call to format_columns_renderer->print_multiple_section_page()
line 276 of /course/view.php: call to require()

Clearly there must be some issue in the database for that instance.

Other course formats are all fine (we have grid, collapsable topics and one column installed too).

It doesnt seem to matter which course / category we apply this format to, they all throw that exception, but again, only in one instance.

Dear Jez,

Thank you for spotting that. It's a bug which only manifests itself when editing is on. I will publish an updated version hopefully within the next 24 hours. In the mean time if you edit the file 'renderer.php' and move line 298 which should contain '$context = context_course::instance($course->id);' to line 261 then that should fix the issue for you.

Cheers,

Gareth

Hi Gareth,

Thanks for looking at that so quickly!
I installed the latest version of the plugin (released today) and it resolved the issue.

Thanks! Jez

Hi Gareth,

Is there a way I can implement this within your Essentials theme? I have found the config.php page where I can alter the "//Main Course page" manually.

Most members of staff really like the three column layout which is a default however some want their course to be a two column layout. Is this possible using this Plugin?

Thanks in advance

Carl