A Moodle Course Page Where the Layout Falls Apart Halfway Down
Pasting from Microsoft Word into Moodle can silently introduce unclosed HTML tags that shift or hide every activity below the source on the course page. The W3C Markup Validator identifies the exact activity causing the problem.
You open a course page and it is visibly broken. Everything looks fine at the top, then partway down the layout collapses: activities shift sideways, blocks jump to the wrong column, sections sit inside one another, or the whole right-hand side disappears. The activities at the top are untouched; everything below a certain point is mangled. Clearing caches and switching themes makes no difference. This guide explains what causes that specific failure and how to fix it.
What you are looking at
The tell-tale sign is that the breakage starts at a point on the page and affects everything after it, while everything before it is fine. That points to a single unclosed or malformed HTML tag in one piece of content, an unclosed <div>, <table>, or <p>, usually pasted in from Microsoft Word. Moodle renders a course page as one continuous HTML document, so an unbalanced tag in one activity does not stay contained: the browser keeps the tag “open” and every subsequent activity gets pulled inside it, which is why the damage cascades downward from one point.
The content that introduced it often looks completely normal in the editor. The visible damage appears further down the page, in activities that have nothing to do with the one that actually contains the broken tag. That mismatch is what makes this so confusing to diagnose by eye.
The thing most people miss first
Before hunting for the bad tag, check one setting, because on a standard Moodle site this symptom should not be possible at all.
By default, Moodle runs all HTML content through a cleaner (HTMLPurifier) before displaying it. That cleaner automatically closes unclosed tags and fixes broken nesting, so a malformed Word paste is repaired before it ever reaches the page. On a default site, the cascade described above simply does not happen.
It becomes possible only when “Enable trusted text” is switched on. That setting tells Moodle to skip the cleaning for content authored by trusted roles (anyone with the moodle/site:trustcontent capability), so that those users can use advanced markup the cleaner would otherwise strip. The side effect: their malformed markup is no longer auto-repaired, and a single unclosed tag now breaks the page exactly as you are seeing.
So the first move is to check it:
Site administration > Security > Site security settings > Enable trusted text.
If it is on, you have found the condition that allows the breakage. You now have two routes: turn the setting off (the broad fix), or find and fix the offending tag (the surgical fix). Often you want both, the setting change to prevent recurrence, the tag fix to repair the page that is already broken.
The broad fix: turn trusted text off
If your site does not actually need trusted text (most do not, it exists to allow scripts and embeds that the cleaner removes), turning it off restores Moodle’s automatic tag-balancing for all content. Existing malformed content then gets cleaned on render, and the layout repairs itself without you touching any individual activity.
Weigh this before flipping it: if trusted authors rely on embedded markup (custom scripts, certain iframes), turning trusted text off will strip that markup. If you are not knowingly using that capability, it is safe and is the cleanest prevention.
The surgical fix: find and repair the bad tag
If you need to keep trusted text on, or you want to repair the specific page, locate the unbalanced tag:
- View the page source (Ctrl+U in Chrome or Firefox). Scan for an opened
<div>or<table>with no matching close near where the layout starts to break. - Use developer tools (F12), Elements panel. The browser auto-corrects malformed markup as it builds the DOM; the point where its correction diverges from what you intended usually sits right at the broken tag.
- The W3C validator (validator.w3.org) can check markup, but its “validate by URL” mode cannot reach a login-protected course page. Use “validate by direct input” and paste the page source instead.
The activity to fix is the one whose content holds the unclosed structural tag, frequently a Label, Page, or Text and media area where formatted content was pasted. Edit it, switch the editor to its HTML source view (in TinyMCE, the HTML source-code button), close or remove the unbalanced tag, and save. If the editor keeps re-mangling the markup, set your editor preference to Plain text area temporarily, correct the raw HTML, and save. Reload the course page: the layout below the fixed content should be restored.
Preventing it from happening again
- The most reliable prevention is to stop malformed Word markup entering content at all. Tell authors to paste as plain text (Ctrl+Shift+V pastes without source formatting in most browsers) and apply formatting in the editor afterwards.
- If you do not have a genuine need for trusted content, leave “Enable trusted text” off. That single setting is the difference between Moodle quietly repairing a bad paste and a bad paste taking down half a course page.
The short version
A course page that breaks from one point downward is almost always a single unclosed HTML tag in pasted content, and on a healthy Moodle site it should not happen, because Moodle cleans HTML by default. If it is happening, “Enable trusted text” is switched on and is bypassing that cleaning. Check that setting first: turn it off to fix the whole class of problem, and fix the offending activity’s HTML to repair the page that is already broken.
Need help with a Moodle or Totara project?
Contact us