You deploy a code update or upgrade to a Moodle site, and afterwards the Edit mode toggle does nothing. You click it, the page reloads, and you are still not in editing mode (or the editing controls never appear). The site otherwise loads fine. This is almost always a stale JavaScript or theme cache, not a code problem, and it clears in a couple of minutes once you know what to purge.

Why a deployment causes it

Moodle serves its interface JavaScript and theme CSS from caches keyed on a revision number. When you deploy new code, the files on disk change, but browsers and the server may still be holding the previous cached versions. The Edit mode toggle is driven by a JavaScript module (an AMD module that calls a web service to flip your editing state). If the browser is running stale or half-updated JavaScript, the toggle silently fails to do its job even though the rest of the page renders normally.

This is why it specifically shows up after a deploy: the HTML and PHP are new, but the JS/theme layer is still cached from before. The fix is to force those caches to regenerate.

The fix, in order

1. Purge all caches. This is the single most likely fix. From the command line:

sudo -u www-data php admin/cli/purge_caches.php

Or, in the UI: Site administration > Development > Purge caches. This rebuilds the JavaScript and theme caches with a fresh revision, so browsers are served the new code.

2. Hard-refresh the browser. After purging server-side, your browser may still hold the old JavaScript. Do a hard reload (Ctrl+Shift+R, or Cmd+Shift+R on macOS) on the page where Edit mode is broken. A normal refresh is not always enough because the cached JS can be served from the browser’s own cache.

3. Reset the opcache if your server uses it. On a production server with opcache.validate_timestamps=0 (common on tuned hosts), PHP keeps serving the old compiled code until opcache is reset, which a cache purge does not do. Reload PHP-FPM (or the web server) to clear it. If you are not sure whether this applies, restarting the PHP service after a deploy is a safe habit.

After these three, click Edit mode again. In the overwhelming majority of cases it now works.

Confirming it is a JavaScript/cache issue

If you want to verify the cause rather than just apply the fix, open your browser’s developer tools (F12), go to the Console and Network tabs, and click the Edit mode toggle:

  • A failed request to Moodle’s AJAX service endpoint (/lib/ajax/service.php), or a JavaScript error in the console, confirms the JS layer is the problem.
  • A clean network log with no toggle request firing at all points to the JavaScript module not loading, again a cache/build issue.

Either way, the remedy is the cache purge and hard refresh above.

If it still does not work

A few less common causes, worth checking only after the cache steps:

  • Development cache settings left on. If $CFG->cachejs = false or $CFG->themedesignermode = true is set in config.php, JavaScript and theme assets are rebuilt on every request, which is slow and can serve inconsistent assets under load. These are explicitly “not for production servers”; remove them on a live site.
  • A theme that failed to compile. If the deploy included a theme change and the theme has a SCSS error, the theme cache can fail to build. Check the site with a known-good theme (for example, Boost) to isolate it.
  • A genuinely incomplete deployment. If the deploy itself was partial (interrupted file sync, failed git checkout), files may be missing or mismatched. Confirm the working tree is clean and matches the intended release before chasing caches further.

Avoiding it on future deploys

Make a cache purge (and an opcache reset, if applicable) a standard final step of your deployment process, after the code is in place and any database upgrade has run. Treating it as part of the deploy rather than a reaction to a broken toggle means the editing UI is never serving stale JavaScript to begin with.

Need help with a Moodle or Totara project?

Contact us