Choose a WordPress learning setup by defining who may enter each course, how enrolment happens and what progress evidence the course owner needs. Match those decisions to the selected plugin and edition. Test the journey through a student account, including direct lesson access and the records created when the learner begins.
Begin with the learning arrangement. A public introduction, a registered course and a teacher-assigned course may need different entry rules. Write the intended audience and access decision for each course before selecting settings. Identify the person who can approve enrolment changes and explain the expected learner journey.
How do course settings change the enrolment route?
Sensei’s enrolment-flow documentation describes one WordPress learning plugin. Sensei’s enrolment flow depends on course settings and whether a product is linked. Treat that as a configuration question for each course, rather than expecting every course to behave like the first one created.
Disabling self-enrolment means an administrator or course teacher must enrol students manually. Record who performs that action and what information they need to identify the intended learner. The course instructions should give a clear route for someone who has been invited but cannot yet enter.
Open Access allows a guest to take a course without signing up. For Open Access, progress is tracked through a session cookie. Consider whether that model fits the course owner’s intended record of participation before selecting it for a course where individual progress needs to be reviewed.
Without Open Access or a linked product, enrolment requires registration. Write and inspect the actual account-creation journey that applies to the course. Confirm where the learner returns after registration and what action begins the course, keeping the observed route with the setup record.
If a course uses a product-based entry route, verify the required extension arrangement and current publisher instructions before adopting it. Keep the course’s learning purpose and the account’s eligibility requirements visible alongside any commerce setup. A course page’s appearance alone does not settle how a learner becomes enrolled.
Which features belong to the selected edition?
The publisher-maintained Sensei readme separates core features from Sensei Pro. Sensei LMS includes reports for student progress and performance. Its Course List block can display available courses on a page or post. These features can support discovery and review, but the owner still needs to define what they intend to observe.
The publisher lists groups and cohorts under Sensei Pro. The publisher lists course access periods under Sensei Pro. If a specification depends on grouping or time-limited access, record the edition requirement before treating it as part of a basic installation.
Make an edition-to-requirement sheet during selection. Describe the actual decision, such as assigning a course to an approved group or ending access according to an agreed course arrangement. Link the corresponding feature documentation and identify what must be demonstrated in the configured site.
Keep access requirements separate from teaching outcomes. A progress report can be part of the evidence the course owner reviews, while the meaning of completion belongs in the course’s assessment design. Describe those decisions explicitly so an administrative setting does not accidentally define what successful learning means.
What should an access test cover?
Sensei recommends creating a student test account to check enrolment. Use the learner route instead of relying on an administrator’s view. Keep controlled sample material and identify which account is being used for each observation, especially when several browser sessions are open.
The original worksheet below covers entry decisions and the evidence to retain. Complete it for the selected course and edition, and add any specific requirement the course owner needs to verify.
| Learner state | Intended access question | Evidence to retain |
|---|---|---|
| Guest | Is public entry intended for this course? | Course and direct-lesson observations |
| Registered, not enrolled | How should the learner begin? | Displayed instruction and enrolment action |
| Manually assigned learner | Has the correct person been enrolled? | Account identity and course record |
| Enrolled learner | Can the intended lessons be reached? | Lesson route and relevant progress record |
| Different learner | Does the same direct link behave as intended? | Access result for the second account |
| Time-limited arrangement | Which documented edition rule applies? | Approved requirement and configured demonstration |
Include the course page and a copied lesson address in the check. Ask the reviewer to explain which account and course state produced each result. Where the outcome differs from the intended access rule, retain the observation for investigation before changing several settings at once.
Original public-introduction and assigned-course exercise
Prepare a hypothetical training site with an introductory course and a separate course intended for assigned learners. Use fictional lesson content and sample accounts in an authorised test arrangement. Write the intended guest and registered-user behaviour for each course before configuring it.
First, inspect the introductory course as a guest. Record the entry action and what happens when the visitor starts. Ask the course owner whether the documented guest-progress model fits the intended purpose of this introduction, or whether an identified learner record is needed instead.
Next, enrol the intended sample learner in the assigned course through the chosen manual route. Use that learner’s account to enter the course and open a lesson. Inspect the relevant course and progress information with the course owner, recording what each screen actually establishes.
Then open the copied lesson address through a separate, unassigned sample account and through a guest session. Compare the observations with the intended access rule. If a lesson is reachable unexpectedly, preserve the exact account state, course settings and URL so the maintainer can investigate the configuration.
Finally, have a colleague follow the learner instructions from the beginning. Ask them to identify where an enrolment question should go and what the course owner will check when a learner reports a problem. Revise unclear instructions and repeat the affected step using the same recorded starting state.
Keep the resulting worksheet with the course handover. Update the relevant row when enrolment rules, edition features or course ownership change. This gives the operating team a practical reference for answering access questions while preserving the distinction between a proposed rule and the behaviour actually observed.
Give course updates their own acceptance question. If an editor moves a lesson, changes the entry model or replaces an instruction, identify which learner states need checking again. Preserve a link to the previous worksheet so the owner can distinguish a deliberate access change from an unexpected result. Ask the maintainer to demonstrate the revised journey with the relevant sample account, then record the observation and any remaining issue beside the changed requirement.
For related work, see website development and hosting. Get started with your course audience, enrolment model and progress-reporting needs.
By Spout Team. AI-assisted drafting by Codex using the linked primary documentation.