Forum update

Jump to: navigation, search

Note: This page is a work-in-progress. Feedback and suggested improvements are welcome. Please join the discussion on or use the page comments.

Moodle Forum Revamp
Project state Specification
Tracker issue MDL-39707
Assignee Jason Fowler & Andrew Nicols @ Moodle HQ

Project goals

The headline goals of this update are:

  • to substantially improve the accessibility of the Moodle Forums;
  • to make the forums more modern in appearance;
  • to make it possible for theme designers and developers to override aspects of the forum layout easily;
  • to allow for creation of new forum types; and
  • to make it easier for subsequent creation of new features.

In achieving the above, a number of related benefits are anticipated:

  • a more manageable and maintainable codebase for the forum;
  • reduced complexity in the generated markup;
  • improved developer documentation;
  • a thorough review of all existing code; and
  • removal of long-since deprecated sections of code.

Although performance enhancements are desirable, we cannot state the effect of these changes on performance. It is hoped that the compartmentalisation of existing code into more manageable chunks will reduce memory consumption.


  • Backwards compatibility
  • Creating sub-plugins for "Forum Types" (Q&A etc) and "Forum View"
  • Subscription management
  • Editor Light - a cut down version of Atto for "Reply inline"
  • Make use of Renderables and Renders


At present the Moodle forums are the oldest part of the code base, and lag behind the rest of Moodle in a big way.

We hope to implement a new interface for the forums, based on the accessible view from MoodleRooms' HSU Forum, and add some new functionality over time.

Current issues

At present, a number of issues have been highlighted with the forum, including:

  1. the forum cannot be overridden by theme designers or developers;
  2. it is impossible to add contrib forum types;
  3. it is difficult to add new core forum types;
  4. the forum is not WCAG compliant;
  5. the forum themeing has been neglected and looks out-of-date when compared with other parts of Moodle;
  6. it is impossible to style or override appearance of forum emails;
  7. the forum does not use the new scheduling API;
  8. the "News forum" is very different from other types which complicates logic in many places;
  9. several core parts of Moodle are strongly tied to forums (e.g. News forums in courses);
  10. a number of core features are missing:
    • thread level subscription
    • anonymity;
    • the ability to send private replies in context;
    • inline reply;
    • post locking and time-based locking;
    • post hiding;
    • discussion sorting; and
    • the ability to make posts sticky;
  11. the forum code does not match the current coding guidelines.

Task list

Compartmentalise existing codebase

Forum is one of the oldest components in Moodle and precedes many of the current guidelines and best practices that we currently follow. As a result, much of the code is in a single library file and tightly linked to it's original functionality.

To make the codebase more manageable, we propose splitting apart the existing lib.php (8614 lines), and where relevant moving functionality to appropriate locations. These will include:

  • moving the display models to a new set of renderable objects;
  • moving the display views to a new set of renderers;
  • creation of a new sub-plugin type for different kinds of forum; and
  • moving shared code into relevant classes.

By doing so we will better help the community:

  • to create new types of forum (discussed below) thereby enhancing the pedagogical aspects of the Forum module;
  • by allowing theme designers to override individual renderers to change styling as desired; and
  • improving code manageability which should reduce time required to both fix issues, and add new features.

Update forum layout

The initial proposal is to model the new forum layout on the mod_hsuforum (contributed by Moodle Rooms).


As standard, the new forum layout should:

  • provide an accessible interface;
  • make clear use of CSS classes and selectors;
  • have a simplified DOM layout; and
  • make use of JavaScript and AJAX to improve the experience for users.


The mod_hsuforum code contributed by Moodle Rooms:

  • is relatively up-to-date with the core forum code;
  • makes use of renderers; and
  • has all JavaScript written in Shifted YUI modules and very close to our new coding guidelines.


  • the new interface is implemented as an alternate view and hard-coded in a similar way to existing views;
  • renderers contain a lot of logic, DB queries, and capability checks which would need removing.

The JavaScript seems largely good, though there are some up-front DOM changes which could instead be moved to the renderer to avoid costly DOM changes on each page load.

Create a new forum type sub-plugin

At present we have several types of forum type:

  • News forum (news)
  • Single simple discussion (single);
  • Each person posts one discussion (eachuser);
  • Question and Answer (qanda);
  • Standard forum displayed in a blog-like format (blog); and
  • Standard forum for general use (general).

However, there have been frequent requests for more types of forum for specific use-cases, pedagogical approaches, and other requirements (MDL-42981, MDL-20903, MDL-40385, MDL-3277, etc). At present all of the current forum types are hard-coded in lib.php and locallib.php so it is not possible for contrib developers to submit new forum types. It is also very difficult to add new forum types to core, and it is hard to maintain existing code. Cron logic is also heavily influenced by the existing types which makes debugging difficult.

As a resolution to these issues, we propose the creation of a new sub-plugin for forums for forum types.

Implement new subscription methods

At present it is only possible to subscribe to an entire forum, or opt out of an entire forum. Per-discussion subscription is not possible and is one of the most requested feature in Moodle.


Documentation will need to be written for the new renderers and renderables, as they are added to the element library.

Additionally, user documentation will be required for any changes to the interface (in-line reply, subscription management) etc.