WordPress Custom HTML disappears: compare entered, saved and rendered content

Preserve the original and the intended outcome

Save a protected copy of the material before experimenting. Remove account tokens, private member details and secret-bearing embed addresses from anything you share with support. Record whether the intended result is ordinary text, an embedded service, a visual layout or executable functionality.

For the club, the requirement might be “show the current timetable with a usable link to the booking page.” A supplied script is only one possible implementation. An approved block or ordinary link may fulfill the requirement without putting executable markup into an editorial field.

Record the post, block type, version, user role and whether this is a single site or Multisite. A tutorial screenshot from another release is not sufficient evidence that your controls are missing or broken.

Check the version-sensitive editing controls

The current Custom HTML documentation describes separate HTML, CSS and JavaScript panels starting with WordPress 7.0. CSS and JavaScript panels depend on the effective unfiltered_html capability. Without that capability, disallowed markup can be removed when content is saved or updated.

Use the documented controls for the actual version and block on your site. A theme, editor extension or older installation may differ. Do not repeatedly paste the same script into different blocks to evade a restriction; first establish whether the intended integration is permitted and supported.

If the purpose is to show source code to readers, choose a Code block rather than trying to execute it. If the purpose is functionality, have the responsible maintainer review the integration and its allowed content path.

Understand filtering without bypassing it

The wp_kses reference describes filtering against allowed element names, attributes, values and protocols. The permitted set depends on the context. This explains why retaining some ordinary markup does not imply that every script, frame or attribute must also survive.

A difference consistent with filtering is a lead, not proof of which component applied it. Ask the maintainer to inspect the relevant save path and policy. Do not turn off the site’s filtering, add a blanket allowance for arbitrary HTML or ask an administrator to save unreviewed code simply to preserve every byte.

For the club example, retaining the timetable text but removing an embedded script may leave a visible yet noninteractive page. The acceptance check must examine the required booking journey, not only whether a paragraph remains.

Check effective capability, not the role label

WordPress’s capability documentation distinguishes unfiltered_html and the Multisite Super Admin boundary. A person called Administrator is not automatically entitled to unrestricted HTML in every installation.

The current map_meta_cap implementation also shows that DISALLOW_UNFILTERED_HTML can deny this capability, including for administrators, and that ordinary Multisite administrators are restricted. Ask the site or network owner which policy intentionally applies.

The purpose of that check is to choose an authorized solution, not to promote all editors or remove a network safeguard. A collaborator should not need broader site administration merely to publish a timetable. Agree who may maintain a reviewed integration and how editors will update its ordinary content afterwards.

Inspect delivery before changing caches

When reopened source is correct, inspect the exact page representation available to the authorized test reader. Confirm its address, publication state and active template. Compare a safe distinctive text fragment in the response with the saved content, without disclosing private drafts through a public diagnostic tool.

If the delivered copy is old or generated elsewhere, use our changes-not-showing investigation. Clearing caches cannot recover markup that is absent from the saved record; repeatedly purging everything can obscure the original observation.

Conversely, a current response containing the expected markup moves the investigation forward. Preserve the original source comparison so a later visual fix is not mistaken for a storage repair.

Separate markup presence from runtime success

If the saved and delivered material is present, inspect the failing resource or behavior. A remote embed may refuse the environment, a script may fail to load, or a runtime error may interrupt initialization. Treat those as hypotheses to connect with evidence rather than guaranteed causes.

Use the Console and Network workflow to record the relevant non-secret error and request. Do not relax the whole security policy, expose a private endpoint or enable an untrusted script to make the preview look complete.

For public pages with important JavaScript-generated text, our response-versus-rendered-content guide covers a separate discoverability check. A successful editor preview does not establish what readers or search systems receive.

Choose a durable supported route

Return to the original outcome. Ordinary headings, paragraphs and links often belong in native blocks. A third-party interactive component belongs in a maintained integration with documented prerequisites and a responsible owner. Keep its configuration separate from routine editorial permissions where the supported implementation allows that.

If the supplier cannot explain the code’s requirements, defer it and provide a usable approved alternative. Do not turn a script’s disappearance into an instruction to grant everyone unrestricted code access. Document the chosen route, relevant versions and who handles future updates.

Accept the repair at all four stages

Check that an authorized editor can enter the permitted material, save it, reopen it unchanged as intended and obtain the expected reader-facing result. Include a clear failure or fallback state for an unavailable external component. Preserve filtering and the intended user-permission boundary.

Keep the private source comparison and observed result with the support handoff. The useful answer is where the change occurred and how the supported content journey now works, rather than a promise that every possible HTML fragment will survive every WordPress installation.