The permission access helper
pom_lms_user_matches_permission_rule( string|int $rule_id ): boolEvaluates one of the theme's permission rules against the current user.
What it is for
The access helpers call it internally. You would call it directly to apply the same rule to something that is not a course or a lesson — a download, a page section, a menu item, a shortcode — so that one rule governs a whole feature consistently.
if ( pom_lms_user_matches_permission_rule( $rule_id ) ) {
// Render the members-only section.
}What counts as no rule
An empty rule identifier means no requirement, and the helper returns true.
That is the same convention the course fields use: a course with no rule selected is not blocked by the rule step. Keep it in mind when passing a value that may be empty — an unset option grants access rather than denying it.
Rules come from the theme
POM LMS does not define permission rules. They are configured in the theme, and the helper evaluates them through the theme's permission-rule support.
If that support is unavailable, the helper returns false — it fails closed, which is the right direction for an access check.
What a rule can require
A rule has one requirement type:
| Type | Requires |
|---|---|
| Role is / Role is not | One of a set of roles, or none of them |
| Has purchased ALL / ANY / NONE of | A purchase relationship with a set of products |
| Has not purchased one of | The absence of a purchase |
| Subscription based on ALL / ANY of | A subscription to a set of products |
Purchase rules can additionally require a purchase date — a specific date, or more or less than a period ago. Subscription rules can additionally require a status and a start date.
There is no rule combining a role test with a purchase test. When you are designing a feature around rules, plan for one requirement per rule.
Product and subscription rule types require WooCommerce, and the subscription types additionally require its subscriptions extension. Without them, those types are not offered.
Rules are re-evaluated on every call
Nothing is cached between requests. A rule that depends on a subscription status or a purchase date reflects the state at the moment you call it — which is what makes membership access end correctly, and what makes time-based rules change behavior without anyone touching the site.
If you call it many times in one request, keep the result in a variable.
Reading the rule set on a course or lesson
$rule_id = pom_lms_get_post_permission_rule( $post_id );Returns the rule identifier configured on a course or lesson, or an empty string if none is set.
Useful for building administration views — showing which rule governs which course. Do not use it to reimplement access: read the rule, and then let the access helpers decide.
Testing rule-based features
Any feature gated by a rule needs at least two accounts: one that matches and one that does not. For time-based rules, test on both sides of the boundary.
There is no preview mode and no "view as" — an administrator sees what an administrator's roles and orders qualify for, which is rarely what a student sees.