Prosopo Procaptcha: guard against wpautop hoisting captcha children out of the custom element

[forgetso]

Summary

The <mc4wp-procaptcha> custom element's setup() calls this.querySelector('.mc4wp-procaptcha__captcha') and passes the result straight to window.procaptcha.render(...). If the custom element ends up wrapped in a <p> (as it does under wpautop, or in many themes that filter form content), the browser's HTML parser auto-closes that <p> before the child <div> — block-level content is not permitted inside <p> — and hoists the captcha container out to become a sibling.

Result: querySelector returns null, render(null, …) throws a TypeError: Cannot read properties of null (reading 'tagName'), and the page's other JavaScript stops running.

Reproduced on gilliancooper.co.uk (Flatsome + LiteSpeed Cache). The problem has been latent since the integration shipped in October 2024; it only surfaces when the surrounding markup wraps the custom element in a <p>.

Fix

In setup():

• Fall back to the enclosing <form> when the local querySelector returns null, for both the captcha container and the validation error element.
• Skip rendering with a console.warn rather than crashing if the container is genuinely missing.
• Only attach the submit handler when a form is actually present.

The plugin's PHP-side markup is already correct — this is purely defensive against downstream markup post-processing.

Test plan

• Load a form with the default PHP-emitted markup (custom element and its <div> child intact) — widget renders as before.
• Load a form whose surrounding template wraps the field stub in a <p> (or run the content through wpautop) — widget renders using the sibling <div> instead of crashing.
• Confirm no console errors under the healthy case.