Free, paid and restricted courses
Four access models, in increasing order of setup. Choose one per course before building it.
The four models
| Model | Configuration | Suits |
|---|---|---|
| Open | Nothing enabled | Marketing content, free introductions, public resources |
| Login required | To access this course, users must be logged in | Members, staff, registered users |
| Rule-based | A Global permission rule | Roles, purchases, subscriptions, time windows |
| Paid | This is a paid course, with a product associated | A single purchasable course |
Open
Nothing to configure. Anyone reaches the course and every lesson.
Use it for content whose purpose is to be found: an introduction, a free mini-course, a resource that supports the paid catalogue.
Remember that progress requires a signed-in student, so an open course shows no meaningful progress to anonymous visitors.
Login required
The course opens only for signed-in students, whoever they are. There is no check of what they bought or which role they hold.
Use it when the audience is "anyone with an account": an internal site, a members' area, a community resource.
Enable Add a login form on top so a signed-out visitor gets a form instead of a dead end.
Rule-based
The most capable model, and the one to reach for whenever access depends on who the student is or what they bought.
A rule is defined once in the theme's options and then selected on the course. Rules can require:
- a role, or the absence of one;
- the purchase of all, any or none of a set of products;
- a purchase made on, before or after a date, or within a number of days, weeks, months or years;
- an active subscription based on a set of products, with a status and a start-date condition.
One rule can serve many courses. Change the rule and every course using it changes, which is powerful and worth testing carefully.
Paid
The course is marked as paid, and access depends on the student having bought the product associated with the course.
Use it for a straightforward single-product course. For anything involving subscriptions, several products, time windows or roles, a permission rule expresses the requirement better and is the model to prefer.
Choosing
Answer three questions:
- Does the visitor need an account? No → open. Yes → continue.
- Does it matter who they are or what they bought? No → login required. Yes → continue.
- Is it a single simple purchase? Yes → paid course. Anything more → permission rule.
What every gated course also needs
Whatever the model, a blocked student must land somewhere useful:
- Content if no access — the message on the course, explaining what to do. It accepts shortcodes and a merge tag that prints links to the associated products.
- "Lesson not available" text — the equivalent for a lesson opened directly.
- A login form, when the obstacle is simply not being signed in.
A gate with no message is a dead end, and it is the most common reason a working course generates support requests.
Mixing models in a catalogue
A catalogue can hold all four. What should not vary within one course is the model itself: a course that is partly login-gated and partly rule-gated is confusing to test and to explain.
Use previews for the deliberate exception — see Public previews.
Before you build
- [ ] The model is chosen and written down.
- [ ] Any permission rule it needs exists.
- [ ] Any product it needs exists and is purchasable.
- [ ] The no-access message is drafted.
- [ ] Test accounts exist for a student who passes and one who does not.