Themeum has removed metaboxes in the Gutenberg editor for Courses and Lessons in version 3.0 that were there in earlier versions, and has implemented forced redirects to their frontend course builder. It now takes 5-6 clicks in version 3.0 to get to the Gutenberg editor for a particular lesson, and switching between different editors breaks existing Gutenberg blocks. So forcing their users to go through the frontend course builder with tinyMCE to get to Gutenberg via a button is not only designing for inconvenience, right now it’s effectively a self-destruct button for Gutenberg.
They say that they will look into fixing the issue with the broken blocks, but this is a known issue that comes up from time to time in the Classic Editor plugin’s support on WordPress.org and core developers haven’t come up with a way around it. To quote a lead maintainer of the Classic Editor plugin: “Was thinking it may be good to add a (permanent) warning when a post containing blocks is edited with the classic editor/TinyMCE” (see https://wordpress.org/…/plugin-stopped-working-with-6-7/).
It will be interesting to see how they resolve that particular issue, but the simplest solution is also the most ideal from an efficiency perspective: allow users to work exclusively in Gutenberg in the backend if that is what they want to do. However, it was clear from my brief discussion with Kawshar Ahmed, the founder of Themeum, and Shaikh, one of their lead developers that rather than engaging with the valid concerns that I was raising—such as breaking existing workflows, removing metabox functionality, and forcing users into a specific editor—they sought to pontificate on how great the frontend course builder is in Tutor LMS and ultimately declared it was a decision that was already made.
WordPress allows for choice and a more user-friendly approach would be to provide both options and let users decide which editor works best for their workflow. Kawshar argued that WordPress itself was taking a similar “forward-thinking mindset” with the development of Gutenberg and FSE, but what he overlooks is that core developers are contorting themselves trying to maintain backward compatibility (see https://dbushell.com/2021/08/03/wordpress-has-a-gutenberg-problem/), while Themeum is actively stripping away essential features in Tutor LMS 3.0 and sabotaging workflows that involve Gutenberg.
Shiny Objects & Pretty Things
The frontend course builder in 3.0 is pretty, but severely limited by comparison to what is available in the backend – even if we’re talking about Tutor LMS settings pages. They could eventually add those, but there are important things that you still won’t be able to do in the frontend. For instance, H5P interactive media has become an essential feature of modern LMS platforms, but adding the H5P creation tools on the frontend would be quite a feat that I seriously doubt is in their roadmap.
In fact, the H5P Integration addon for Tutor LMS is a very interesting example of the error and impracticality of these recent changes. The addon doesn’t provide frontend access to H5P creation tools, it’s just a drop down menu in the frontend course builder to select pre-existing H5P content, so instructors who only have access to the frontend course builder are unable to create their own H5P content. Of course, it was always possible for users with backend access to add H5P content to their pages, but harder to do when a plugin developer restricts access to the backend editor, like Themeum has done in version 3.0, which is undoubtedly the reason for their approach to the H5P integration. While the integration solves the problem that was created when they implemented restrictions to those who do have backend access, it still overlooks those who don’t have backend access! (There are similar issues with half-baked integrations in Tutor LMS, such as their “Tutor LMS BunnyNet Integration” addon, but you get the point…)
As a result, even if you have backend access, Tutor LMS 3.0 has implemented a severely fractured course creation experience bouncing around between the frontend and the backend. Not because that’s the way it has to be, but because Tutor LMS consciously decided to strip out features in Gutenberg, and restrict access to it. All in favor of a limited, but very pretty frontend course builder – a mere shiny object that they think will persuade users to use Tutor LMS.
Instructor Access in Tutor LMS 3.0
On the surface, Themeum achieved something great with Tutor LMS and, prior to version 3.0, it fully supported Gutenberg. People can be persuaded by “pretty things” but breaking further and further away from core is no longer the only, or best, way to achieve “pretty things” anymore and as we discussed it would be really, really hard to replicate the entire backend. I recently made a video on how to give instructors access to the h5p creation tools on the backend without giving them full access using plugins like uiXpress or WP Frontend Admin. With uiXpress you can also let instructors access other backend pages relevant to them, such as other Tutor setting pages and the media library. First though, you have to disable the setting, “Hide Admin Bar and Restrict Access to WP Admin for Instructors” in Tutor LMS to give them access to the following pages:
- Courses
- Course Bundles
- Announcements
- Q&A
- Quiz Attempts
- Google Classroom
- H5P (similar to the H5P plugin’s “My Results” page)
- Assignments
- Zoom
- Create Course (this page is probably a leftover of version 2.0, because it isn’t there otherwise and results in a blank screen)
Now, I imagine that all of these pages have role-based filtering implemented so instructors only see their own data, and nobody else’s. It is kind of hard to tell because I am currently testing on a site with only demo content, but signing-in as a new instructor I do see a course in the “Assignments” pages’ “Course” filter drop down that they shouldn’t have access to. So at the very least there’s some more work to be done there.
The manage_tutor Capability
On the other hand, I wondered why they don’t have access to other relevant pages, such as:
- Orders
- Subscriptions
- Coupons
- Students
- Withdraw Requests
- Enrollment
- Google Meet
- Gradebook
- Reports
If role-based data filtering is implemented, these pages would be useful for instructors to access as well. I wondered… So I granted my instructors access by enabling the manage_tutor capability on the instructor role. That gave them access to:
- What’s New
- Students
- Withdraw Requests
- Addons
- Enrollment
- Google Meet
- Gradebook
- Reports
- Tools
- Settings
- License
But it did not give them access to Orders, Subscriptions, or Coupons – probably because those have role-based access restrictions. Funnily enough though, the Addons, Tools, Settings, and License pages do NOT have role-based access restrictions enabled. I immediately hid those pages from instructors using uiXpress, but that should also be fixed on Tutor LMS.
Inconsistent Implementation of Role-Based Filtering
The issue that I see now is that there is no role-based data filtering on the Students, Withdraw Requests, Enrollment, Gradebook, or Reports pages on the backend. Also, the instructors still do not have access to the Orders, Subscriptions, or Coupons pages. On the frontend dashboard, however, they DO have access to Withdrawals, Analytics, Google Meet, and can create Subscriptions and view Orders.
However, that is the reason work should be done to fix permissions and grant access to these backend pages in Tutor LMS – despite having a frontend course builder, there are more options and available mechanisms on the backend that would be great to make available to instructors if it was secure – but in Tutor LMS it is not.
Fractured Workflows in Tutor LMS
We are assuming that a good portion of Tutor LMS users will still want to use the Gutenberg editor and create H5P content – but even if one were to argue that it is the opposite case, Tutor LMS does NOT provide a unified interface for creating courses even though it includes a frontend course builder and provides a setting for granting instructors limited access to the backend (although they have begun stripping out features available on the backend after version 3.0). Meaning no matter how admins or instructors create their courses in Tutor LMS, they will have to bounce around between the backend and the frontend given the current implementation. Let’s go over how and why:
- The Courses page on the backend has a codependency with the frontend course builder as-of version 3.0, so instructors are redirected to the frontend course builder.
- The Gutenberg editor is not accessible on the frontend, so instructors are redirected to the backend even if they are editing the lesson on the frontend.
- Even if instructors do have direct access to the backend, they have to navigate through the frontend course builder to get to the Gutenberg editor for a lesson on the backend.
- Creating H5P content is done on the backend.
- Withdraw requests are only accessible to instructors on the fontend, even though there is a backend page for it.
- Analytics are only accessible to instructors on the fontend, even though there is a backend page for it (Reports).
- The existing Students page on the backend is not accessible to instructors even though there is a backend page for it, they have to navigate to the frontend dashboard > Analytics > Students.
- It also seems like instructors do not have access to the Enrollment page (to manage student enrollment status in their courses). Admins have to handle this for them.
- Instructors do not have access to Orders, Subscriptions, or Coupons page (some limited info is available in Analytics on the frontend). It seems like admins are the only ones who can create coupons, and manage orders and subscriptions.
- I’m not sure if there is an equivalent Gradebook page on the frontend.
Role-based filtering mechanisms in Tutor LMS
The enrollment data is retrieved utilizing custom database queries in posts_clauses_request or other utility functions to fetch the contents of the Enrollment page. The data is primarily stored in the wp_tutor_enrollments table, which contains records of student enrollments in various courses. To retrieve this data, Tutor LMS performs SQL queries that join this table with other relevant tables, such as wp_users (for student information) and wp_posts (for course details). These queries are constructed using WordPress’s $wpdb class, allowing for direct interaction with the database.
However, unlike WP_Query, there is no unified API for data retrieval in Tutor LMS, leading to fragmented and case-specific logic scattered across multiple files (e.g., Admin.php, utility classes, and AJAX handlers). Queries are often tailored to specific use cases, meaning that logic, such as role-based filtering, would need to be added individually to each query. So adding role-based filtering logic would require manually modifying all relevant SQL queries involved.
Breaking with Core
I sincerely hope Themeum will prioritize user choice and flexibility over unilateral decisions in the future, but the fact of the matter is the backend editor has been neglected in Tutor LMS for a long time:
- While WordPress has fully adopted React for Gutenberg, Tutor LMS 2.7.7 still used outdated metaboxes, PHP-rendered forms, and jQuery-driven interfaces rather than providing a true block-based, React-powered editing experience.
- The course meta system is cluttered with direct database queries and redundant calls to
update_post_meta(), leading to unnecessary complexity and maintenance overhead. - Tutor LMS still heavily relied on procedural PHP functions, legacy AJAX calls, and direct
$_POSThandling rather than leveraging the modern WP REST API. - The right-hand settings panel is underutilized, even as the most accessible space for settings.
The UI in the backend editor also left a lot to be desired:
- The right-hand settings panel is underutilized, even as the most accessible space for settings.
- The metabox area below the editor canvas – by extension – is overutilized, even as the least accessible space for settings (but best for larger fields).
- The interactive “Course Builder” metabox is only available in the main Course editor.
- The workflow is overly linear and unnecessarily restrictive, while relying on modals with limited tinyMCE editors to compensate.
After spending close to a week pouring over Tutor LMS’s codebase, I came up with a very strategic plan to re-implement settings in the backend editor as a modern React-based Gutenberg UI using the WP REST API, but everything was so disorganized and built on legacy/non-standard code for WordPress, the old code was only useful as a reference for creating all the endpoints and rebuilding the entire backend editor UI from scratch. Customizing Tutor LMS was always an uphill battle, requiring overriding this, and adding in that, just to get it to work with basic stuff in WordPress. I started to come to terms with the fact that even the architecture in 3.0 will need a complete overhaul at some point.
Continuing to swim upstream, and even dramatically increasing the scale of that undertaking, is a fools errand. The underlying architecture of Sensei LMS, on the other hand, is built on modern WordPress development best practices. I will still need to do quite a bit of development work (there’s no way I’m using WooCommerce Subscriptions), but it will be a far better starting place. I can get back to developing to enhance the plugin, rather than getting it to work with WordPress in the first place.
The strength and future of WordPress is not some single solution that looks pretty and does as much for you as possible. Instead, WordPress’s singular strength that sets it apart and allows it to continue to thrive even though there are newer, more modern CMS options out there, is the integrated ecosystem of thousands of developers adhering to the WordPress core standards, collaborating seamlessly to unlock endless possibilities within a modular framework. Themeum was never really aligned with WordPress best practices to begin with, but they have now decided to remove Gutenberg support in order to promote their extended product line.