We encountered a situation when organizations using Totara wanted to add BigBlueButton for live virtual learning.
BigBlueButton was attractive because it is open source and can be self-hosted. For organizations with requirements around data control, infrastructure, or data residency, that flexibility can be important.
The expected learner experience was straightforward: trainers should be able to add BigBlueButton directly to a Totara course as an activity, create virtual meetings, and allow learners to join those meetings without leaving the learning platform.
The technical reality was less straightforward.
The plugin existed, but it was built around Moodle
An open-source BigBlueButton plugin was already available. However, it had primarily been developed around Moodle rather than the Totara environment in which our clients needed to use it.
That distinction created problems in several areas. Administrative settings did not behave as expected, meeting creation and joining were unreliable, and parts of the plugin depended on older Moodle conventions.
The production environments were also running PHP 8.4, which exposed additional compatibility problems in the plugin’s code.
Why Moodle compatibility does not guarantee Totara compatibility
Totara and Moodle share common roots, but they should not be treated as interchangeable platforms. Totara has continued to evolve its own architecture, enterprise functionality, administrative patterns, and integration capabilities. That means a plugin originally built for Moodle may provide a useful starting point without necessarily being production-ready for Totara.
For organizations evaluating a Totara integration, installation should therefore be treated as the beginning of validation rather than proof that the integration is ready.
First, we diagnosed the integration rather than patching symptoms
Our first step was to audit the BigBlueButton plugin against the current Totara environment.
We mapped where the integration depended on Moodle-specific administrative behavior, where configuration calls were no longer appropriate, and where the runtime was failing under PHP 8.4.
This distinction mattered. Fixing errors individually may have made the integration appear functional temporarily, but it would not have addressed the underlying compatibility problem.
The objective was to understand what needed to change for BigBlueButton to behave like a reliable, native-feeling activity within the Totara environment.
Rebuilding the configuration layer for Totara
One of the most important issues was the plugin’s administrative configuration. The existing implementation relied on legacy configuration patterns that were not behaving correctly in Totara.
We migrated the relevant configuration handling to Totara’s core\setting framework so administrators could manage BigBlueButton through the platform’s expected settings structure.
The result was not simply cleaner code. It also created a more consistent administration experience for the people responsible for operating the LMS.
Making the integration compatible with PHP 8.4
The runtime environment introduced another layer of complexity.
PHP 8.4 applies stricter behavior to coding patterns that older PHP releases may have tolerated. The plugin contained issues involving undefined variables, non-nullable type handling, meeting logic, redirects, and other runtime assumptions.
Our engineers corrected these problems so the integration matched the version of PHP the clients were actually running instead of depending on legacy behavior.
Making BigBlueButton work correctly inside Totara
Technical compatibility alone was not enough. BigBlueButton also needed to behave correctly as a standalone activity within Totara courses. We aligned meeting creation, joining, redirects, configuration flow, and activity behavior with the expected Totara experience.
Where organizations wanted to use BigBlueButton alongside Totara Seminars, the activity could support that broader learning workflow without being dependent on Seminar itself.
This meant looking at the integration from the perspective of administrators, trainers, and learners rather than treating it only as a code-level exercise.
Testing the complete learning workflow
A plugin being successfully installed does not tell you whether the learning experience will work.
We tested realistic BigBlueButton activity scenarios, including configuring the activity, creating virtual meetings, joining as trainers, joining as learners, handling redirects, and managing errors.
We also validated how the activity could be used within wider Totara learning workflows, including scenarios where organizations chose to use it alongside Seminars.
That end-to-end validation was essential because the most important integration failures often appear across the user journey rather than inside an individual component.
A reliable Totara integration should be evaluated against the workflow it is supposed to support.
From non-functional to production-ready
The resulting integration gave the organizations a stable way to use BigBlueButton within their Totara environments.
Administrators could configure the integration correctly. Trainers could add and manage virtual classroom activities within courses. Learners could reliably join meetings. And the plugin was hardened for PHP 8.4.
Organizations could use BigBlueButton independently as a course activity or incorporate it into broader learning workflows, including those involving Totara Seminars.
It also preserved one of the main reasons for choosing BigBlueButton in the first place: the ability to operate a self-hosted virtual classroom environment.
Need a Totara integration that actually works in production?
Existing plugins are often only the starting point. If your Totara integration needs compatibility fixes, custom development, or end-to-end workflow validation, Edly can help you make it reliable, maintainable, and ready for real learners.
