Moodle 4.0 developer update

Moodle 4.0 This page will highlight the important changes that are coming in Moodle 4.0 for developers. Including how the UX improvements impact custom themes, relevant API changes, and what you can do as developer to prepare for the 4.0 release.

The core_courseformat subsystem

Most of the logic for rendering and editing a course has been moved to a new subsystem called courseformat. The subsystem is located in "course/format" folder so it includes all the format plugins inside. The methods and modules which are distributed between the course and the course/format folders are now rearranged or refactored to be aligned with the current Moodle coding style.

Mandatory renderer in course formats

Now format plugins renderer is not optional anymore. Legacy formats without a renderer will get a deprecation message but it will continue working however, they should create a new renderer as soon as possible. The section-based format can do it by extending the provided core_courseformat\output\section_renderer class which includes all the necessary methods.

New format base class

The old base_format class (which all plugins extend) is now renamed as core_courseformat\base. The new class provides all the functionally of the previous base_format but it has been refactored to be used as a centralized source of truth for the course rendering. Legacy formats should extend the new class to avoid the deprecation message.

Now, the plugin format class provides information such as:

• If the page is displaying a single or multiple section
• Give access to other related format objects like the modinfo, the course record, maximum number of sections...
• If the format is compatible with features like course index, reactive components, ajax...
• Other format specifics like the page title, the default section name, default blocks...

The format instance is now the main object output components will use to render a course (see next section for more information).

New course output classes and mustache files

Traditionally, section-based course formats uses print_single_section_page and print_multiple_section_page to render the course content. In Moodle 4.0 most of the course rendering methods are migrated to output components and mustache templates. The old methods will get deprecation messages if they use the old renderer methods.

This is an example of a format rendering a course:

// Get the course format instance.
$format = course_get_format($course);

// Get the specific format renderer.
$renderer = $format->get_renderer($PAGE);

if (!empty($displaysection)) {
    // Setup the format instance to display a single section.
    $format->set_section_number($displaysection);
}

// Create the ouptut instance and render it.
$outputclass = $format->get_output_classname('content');
$widget = new $outputclass($format);

echo $renderer->render($widget);

Format plugins are free to use its own output classes to render a course, or they could override the existing output classes by providing their own implementation. For example, the default output for "content" (as in the previous example) is "core_courseformat\output\local\|content", however, if the plugin has a "format_XXX\output\courseformat\content" class, the $format->class the get_output_class will return the overridden one.

Another important update on course rendering is that now all course structure is rendered using mustache templates instead of the original html_writer methods. Now themes are able to override the course format by providing alternative versions of the mustache files. All core course templates are located in "course/format/templates".

All the new output classes and a guide on how to migrate the current third-party plugins will be available soon.

Course editor javascript modules and frontend components

Soon.

Other course related 4.0 changes

• The majority of the javascript logic of the course editing is replaced by a new course editor AMD module. The old javascript is still available for third-party and it is not considered deprecated, however, it will replace eventually. Furthermore, some new 4.0 features such as the course index or adding sections via ajax are only available for formats compatible with the new course editor module.
• New web services

Behat changes

To make behat tests more readable and easy to maintain, it is recommended to use the most direct steps to get what the test needs. So since MDL-66335 was integrated, and the step was improved in MDL-72179 is highly recommended to use

I am on the "Activity name" "[modname] activity" page 

or

I am on the "Activity name" "[modname] activity" page logged in as "user"

instead of navigating to the activity via

I am on "Course" course homepage
I follow "Activity name"

Now that Course index (MDL-71209) is integrated but the project is not stable, these behat steps

I am on "Course" course homepage
I follow "Activity name"

will fail using Boost theme.

The reason for it is that the drawer used in Boost is hiding the course index. So when the test is trying to follow an "Activity name" link, it finds two different links:

• one in the course index
• another one in the course main content.

But the first one, the one in the course index, is hidden by the drawer, and the test fails.

However the recommended behat steps

I am on the "Activity name" "[modname] activity" page 

or

I am on the "Activity name" "[modname] activity" page logged in as "user"

work fine.

Some of the failing behats are fixed in https://github.com/ferranrecio/moodle/commit/c79d58a50b48aa6891ff1d3ba92a7b0ab2393c88#diff-fdf8b0b1eade3b69eaad038de0ddd7c8dec2be7afa32dc693fb929739a49fa9dR32 - MDL-71209

For example:

And I am on the "Test assignment name" "assign activity" page logged in as teacher1

instead of:

When I log in as "teacher1"
And I am on "Course" course homepage
And I follow "Test assignment name"

Core plugins review

A few plugins from core Moodle LMS which are no longer or hardly used have been removed and, if appropriate, added to the Moodle plugins directory.

More information about this project, the list of plugins to be removed and the process to follow for keeping them before upgrading to 4.0 can be found in the Core plugins review page.