Preserve Form Scripts When Inserting HTML with PHP

A Gravity Forms form worked when rendered directly but broke after a theme helper inserted it before an article heading. JavaScript source appeared in the page, and the form’s security footer stopped working. Comparing the output before and after insertion showed that the placement code had changed characters inside an inline script. It had reparsed the rendered form with PHP’s HTML parser. The fix was to use the parser to find the location, insert a temporary marker, and substitute the original rendered form after serializing the article. That preserved the form output without asking the placement helper to reinterpret its scripts.

Compare direct output with the inserted result

The page showed source text after the form, so the first suspects were an unclosed script tag, a minifier, or a bad HTML field. The saved field and direct form output were valid. The corruption appeared only when the CTA placement rule moved the rendered form into article content.

Comparing the bytes before and after injection exposed the clue: a closing div inside a template literal had become a closing script followed by a div. The browser was faithfully reacting to markup the server had changed.

Check what DOMDocument changes during parsing

I used DOMDocument to find the nth heading and insert a fragment. That is reasonable for document structure. It is not safe to assume that arbitrary rendered fragments containing raw-text elements can be parsed and serialized byte-for-byte.

Inside script and style elements, strings may contain HTML-looking sequences that belong to another language. The fragment contained JavaScript as well as HTML, and the parse-and-serialize step did not preserve that JavaScript unchanged.

Locate the insertion point with a placeholder

I still needed the DOM to identify the correct insertion point. I no longer needed it to reinterpret the component. The new path creates a unique comment placeholder at the target location, serializes the surrounding article structure, then replaces that exact marker with the original rendered CTA bytes.

parse article structure
insert unique inert marker before target heading
serialize the article
replace marker with untouched rendered component

A per-document sequence and content hash make markers deterministic and extremely unlikely to collide with saved content.

Preserve only trusted, already-rendered output

“Insert raw HTML” can sound like permission to bypass escaping. It is not. The form has already been rendered by a trusted internal component after its normal validation and escaping. The placement helper leaves that finished output unchanged because reparsing it caused corruption.

User input still goes through the component’s normal security rules. The placeholder method does not make arbitrary request data trusted.

Cover every template that inserts the form

The theme had a standard content path and a Hub layout with section wrappers. Both used related placement logic and both could corrupt a form. PHP tests asserted exact preservation of template-literal markup and correct placement in each path.

This prevented a common partial fix where one template becomes safe while another still runs the old helper.

Verify the form behavior in a browser

I loaded the real local fixture at the project’s mobile widths. The test confirmed the form stayed visible, the expected security images were inserted, the function existed, and no JavaScript source leaked into body text. It then removed the generated footer, triggered the Gravity Forms post-render event, and verified the script restored it once.

That last step mattered because a byte comparison cannot prove the script still participates in the plugin’s lifecycle.

Keep component changes in the component

The placement layer can no longer inspect or sanitize the inside of the rendered CTA. The component must validate and escape its own output before placement. If placement needs to modify component internals later, string substitution is not the answer; the component should expose a structured option or return nodes through a representation designed for composition.

The incident also changed how I review helper names. A function called “HTML to nodes” sounded generic enough to reuse, but it also normalized markup through libxml. I now document whether a transformation preserves bytes, preserves browser meaning, or merely produces valid HTML. Those are different guarantees, and callers need to know which guarantee the function provides.

Content Security Policy also needs consideration. Preserving an inline script does not make inline scripting the ideal long-term design. Moving behavior into registered assets with nonces or hashes can improve security and caching. In this case, the placement system had to remain compatible with existing Gravity Forms content; redesigning the form’s script ownership was a separate project. Keeping the fix narrow prevented a production regression from becoming an unplanned platform rewrite.

Choose the parser for the transformation

When inserted content breaks, compare the exact output before and after each transformation. If placement only needs to choose a location, keep it from rewriting the finished component unnecessarily. A placeholder can preserve trusted, already-rendered output after the surrounding document is serialized. That does not make arbitrary input safe: validation and escaping still belong in the component. Test each template that uses the helper and verify the form’s actual browser behavior, including later render events.

Photo by Markus Spiske on Pexels.