Activity restrictions are a Moodle course feature, not a hosting setting: you configure them entirely inside the Moodle admin, on the "Restrict access" panel of any activity or resource. Nothing about Flashcloud's stack limits or changes that behavior. What can affect how reliably the rules apply comes down to PHP version and caching, both of which you control from the portal.
How restrict access works in Moodle
Every activity, resource, and section in a Moodle course has a "Restrict access" panel where you add one or more conditions: a required grade on another activity, a date range, group or group membership, a completion status on a prerequisite item, or a user profile field. Conditions can be nested with "any"/"all" logic and combined with "Hide entirely" or "Show grayed-out" display modes. This is stored in Moodle's own database tables and evaluated by Moodle's PHP code on every page load.
If restrictions aren't behaving as expected, the fix is almost always in Moodle itself:
- Confirm
Enable conditional accessis turned on under Site administration → Advanced features. - Confirm
Enable completion trackingis on if any restriction depends on activity completion. - Check that the prerequisite activity actually has completion tracking enabled on its own settings page, not only site-wide.
- Remember date restrictions use the server's timezone unless a user has a personal timezone set, so a "not available until" condition can look wrong by a few hours if timezones don't match.
Where Flashcloud's stack fits in
Moodle runs as a normal PHP application on our hosting stack. Each domain has its own PHP version, switchable from 7.4 through 8.3 from the PHP Version tile in the portal. Moodle publishes minimum and maximum supported PHP versions per release. If you're seeing odd behavior after a Moodle upgrade, deprecated PHP functions can throw errors that get swallowed, and restrictions can stop evaluating as a result. Check your installed Moodle version's requirements against what's set on the PHP Version tile first.
If a specific PHP setting needs adjusting, like max_execution_time or upload_max_filesize for course backups, that's done separately in cPanel under Software → MultiPHP INI Editor, in Basic or Editor mode, per docroot (see accessing cPanel). The PHP Version tile only switches the version; it doesn't touch these limits.
Moodle relies on a working cron job to process scheduled tasks, including some restriction-related notifications. Cron Jobs are a native portal tile if you'd rather manage the schedule there. See our portal map for where each tool lives.
Caching and why restrictions still show up promptly
A reasonable worry with any caching stack is whether it will show a restricted activity to someone it shouldn't, or hide one that just became available. Moodle is a separate PHP application with its own internal caching layer (MUC, the Moodle Universal Cache) for things like course structure and language strings, and that cache is invalidated by Moodle itself whenever a restriction, grade, or completion state changes. Read more about how the underlying server is tuned in how we make your site fast and the cache stack we ship with every WordPress install.
Because access conditions are evaluated against the database on each request rather than served from a static cache, a student who completes the prerequisite activity will typically see the next one unlock on their next page load.
When to open a ticket
If you've confirmed the Moodle-side settings are correct and restrictions still aren't evaluating consistently, especially after a PHP version change or a Moodle core update, open a ticket from Support in the portal. It's worth including your Moodle version, the PHP version currently set, and one example activity ID that's misbehaving so our team can help confirm nothing on our end is interfering.