Added the ability for site administrators to delete (completely remove) enrollment records from the database.
Catalogs sorted by Order (menu_order) now have an additional sort (by post title) to improve ordering consistency for items with the same order, thanks @pondermatic!
Hooks in the dashboard order review template now pass the LLMS_Order.
LifterLMS Blocks
Updated to version 1.5.1
All blocks are now registered only for post types where they can actually be used.
Only register block visibility settings on static blocks. Fixes an issue causing core (or 3rd party) dynamic blocks from being managed within the block editor.
Bug Fixes
If an enrolled student accesses checkout for a course/membership they’re already enrolled in they will be shown a message stating as much.
Removed a redundant check for the existence of an order on the dashboard order review template.
When an order is deleted, student enrollment records for that order will be removed. This fixes an issue causing admins to not be able to manage the enrollment status of a student enrolled via a deleted order.
Fix issue causing errors when using the [lifterlms_lesson_mark_complete] shortcode on course post types.
Fixed an issue causing quiz questions to generate publicly accessible permalinks which could be indexed by search engines.
Only register block visibility settings on static blocks. Fixes an issue causing core (or 3rd party) dynamic blocks from being managed within the block editor.
LifterLMS has a really simple, straightforward and clean API to manage user enrollment into courses and memberships.
In this tutorial, we’ll explore this API in some detail. Using a couple of examples, we’ll build a few custom and automated user journeys. Finally, we’ll leave you with a couple of exercises that you can use to strengthen your understanding of the Enrollment API and explore its possibilities.
Is this for only for Programmers?
This tutorial is written for the benefit of non-programmers too. Concepts are simplified and abstracted for lesser details. Developers are encouraged to check the source code (linked to wherever relevant).
The focus is more on concepts so that course creators can use them to design user journeys that could then be implemented by a developer.
Added the ability to restrict coupons to courses and memberships which are in draft or scheduled status.
When recurring payments are disabled, output a “Staging” bubble on the “Orders” menu item.
Recurring recharges now add order notes and trigger actions when gateway or recurring payment status errors are encountered.
When managing recurring payment status through the warning notice, stay on the same page and clear nonces instead of redirecting to the LifterLMS Settings screen.
Updated the Action Scheduler library to the latest version (2.2.5)
Exposed the Action Scheduler’s scheduled actions interface as a tab on the LifterLMS Status page.
LifterLMS Blocks
Updated to version 1.4.1.
Fixed issue causing asset paths to have invalid double slashes.
Fixed issue causing frontend css assets to look for an unresolvable dependency.
Bug Fixes
Fixed an issue allowing instructors to view a list of students from courses and memberships they don’t have access to.
WooCommerce compatibility filters added in 3.31.0 are now scheduled at init instead of plugins_loaded, resolves conflicts with several WooCommerce add-ons which utilize core WC functions before LifterLMS functions are loaded.
You should be comfortable with copy pasting code and editing some text inside it to be able to use it. This code is theme independent and would work on almost all sites.
Plugin Conflicts
If you have a plugin that extends the login mechanism or post-login redirects, they may interfere with this recipe and it may not work.
That also means that this may not work that well with WooCommerce and you’d need to modify the recipe for that. If you do end up with a recipe for LifterLMS + WooCommerce sites, get in touch with us to publish it here.
Background
When a user lands on a lesson (or another piece of restricted content) on your site, they are either shown a notice or redirected to the course (membership, etc) to buy it and gain access.
This is fine for your prospective members (visitors) but some LifterLMS users find this unsatisfactory for existing members or students.
When students get links to such lessons (restricted content) in an email and click that to reach the lesson, one of two things can happen. If the student is logged in, they’ll see the lesson and things will go on smoothly.
Things are a bit complicated if the student isn’t logged in. There is no way for us to differentiate between anonymous visitors until they login. So, such students (coming from an email) will also be treated like casual visitors.
At this point, a student may not realise what’s going on and attempt to sign up for the course or membership again. That will tell them that they’re already signed up for a course (if they use their registered email address) or create a duplicate sign up (if they use a new email address).
What they need to do is go to the login screen and login. Now, even when the student logs in, they’ll be redirected to the Student Dashboard.
To go back to the lesson (from the email), they would need to open the email again, click on the link again and this time, they’ll be on the lesson as intended by the course creator.
What would have been much easier is if we could do something to the link in the email so that instead of all this, the user was redirected to a login screen and as soon as they login, redirect them back to the lesson seamlessly.
Goals
Add a parameter ?login=1 at the end of a restricted URL when adding it to emails intended for registered students who definitely have access when logged in.
When such a student clicks this link and lands on the restricted page, redirect them to the login screen.
On the login screen, inform the student that they need to login to access the restricted content.
After logging in, redirect the user back to the restricted content where they have complete access now.
Here’s a preview of what to expect from this recipe:
Only output admin course/membership relationship information for existing items. Fixes an issue caused by deleting courses/memberships associated with orders through order item meta data.
