WhatConverts GHL Iframe Late-Load Troubleshooting

WhatConverts GHL Iframe Late-Load Troubleshooting

What

Use this as an optional troubleshooting branch, not the default installation, when a normal single-step GoHighLevel/LeadConnector iframe form reaches GHL but does not create a WhatConverts Web Form lead.

Most GHL forms work with the standard WhatConverts child-frame setup: one idempotent form.wc_form wrapper, one client-specific profile loader, the matching WhatConverts form-set selector, and the normal visible submit button. Do not change forms where that standard setup already works.

A less common LeadConnector rendering sequence can inject the GHL Custom HTML after the iframe’s native load event has already fired. The generated WhatConverts profile script then assigns its initializer to window.onload, but that event will not fire again. The page can look fully configured while WhatConverts never attaches its submit listener.

The characteristic failure is:

• form.wc_form exists exactly once;
• the correct WhatConverts profile loader exists exactly once;
• the WhatConverts form set maps to .wc_form;
• the real visible GHL submit button fires one native submit event;
• document.readyState is already complete;
• the WhatConverts initialization flag remains false;
• window.onload still contains the generated WhatConverts initializer;
• clicking the real button produces zero /lead/form requests.

Who owns it

The Website Specialist owns browser diagnosis, the safe request probe, the repository/template update, and verification. The GoHighLevel Specialist owns replacing and saving the complete Custom HTML block in the exact GHL form when authenticated builder access is needed.

Do not ask the client or teammate to submit repeated real tests while request generation is still failing. Inspect GHL workflows and notifications before any real submission because a test can create contacts, opportunities, emails, SMS messages, and client-visible alerts.

Steps

1. Confirm this is the late-load case.

   • Open the public parent page in a fresh browser with explicit QA UTMs.
   • Identify the exact LeadConnector iframe and form ID.
   • Confirm the form is a normal single-step form with a real button[type="submit"].
   • Confirm one .wc_form wrapper, one correct profile loader, and the expected WhatConverts form-set mapping.
   • Click the real visible button in a probe that aborts every outbound POST. Do not replace the click with form.submit() or a synthetic submit event.

2. Inspect WhatConverts initialization state.

   • Confirm the iframe has reached document.readyState === 'complete'.
   • Confirm the generated WhatConverts initialization flag is still false.
   • Confirm window.onload still contains the WhatConverts initializer.
   • Confirm no WhatConverts submit listener is attached and the visible-button probe emitted zero /lead/form requests.

3. Prove the repair before installing it.

   • In the same POST-aborting probe, invoke the pending window.onload handler once.
   • Click the same real visible submit button again.
   • Continue only if this produces exactly one blocked /lead/form request with the expected profile ID, form-set ID, form fields, parent landing-page/UTM attribution, and child iframe URL.
   • If it still produces zero requests or creates duplicates, stop. Do not install this option.

4. Add the optional post-loader activation.

   • Keep the standard wc_form wrapper, attribution handoff, mutation handling, and profile loader unchanged.
   • Immediately after the one client-specific WhatConverts profile loader, add:

   <script type="text/javascript">
     window.setTimeout(function () {
       if (typeof window.onload === 'function') {
         window.onload();
       }
     }, 0);
   </script>

   This does not submit the form and does not call the WhatConverts API directly. It runs the WhatConverts initializer that LeadConnector loaded after the normal browser load event.

5. Save and verify the complete block.

   • Replace the existing GHL Custom HTML element. Do not add a second element.
   • Save through GHL’s third-party-script warning, then save the form.
   • Reopen the Custom HTML element and confirm the complete block persisted.
   • Keep the repository/template and live GHL block aligned.

6. Run a fresh safe production probe.

   • Do not manually invoke window.onload in this verification run. The installed production code must initialize WhatConverts itself.
   • Fill all actual fields and click the real visible button once.
   • Abort every POST so the check creates no GHL contact, WhatConverts lead, or notification.
   • Require exactly one correctly attributed /lead/form request.

7. Run one announced end-to-end test.

   • After the safe probe passes and the operator understands the notification consequences, submit one normal public form test.
   • Verify exactly one matching form submission/contact in GHL and exactly one matching Web Form lead in the correct WhatConverts profile.
   • Confirm fields, timestamp, landing page, source/medium, form identity, and iframe attribution independently in both systems.

Definition of done

• The standard wc_form architecture remains intact.
• The late-load repair was used only after the documented failure signature was proven.
• The live GHL Custom HTML contains one wrapper, one profile loader, and one post-loader activation.
• A fresh safe visible-button probe, without manual initialization, emits exactly one blocked /lead/form request.
• The request contains the correct profile, form set, submitted fields, parent attribution, and iframe URL.
• One announced real submission creates exactly one GHL record and exactly one WhatConverts lead.
• No custom direct API bridge, duplicate loader, duplicate wrapper, or alternate submit selector was introduced.
• Forms that already work with the standard setup were left unchanged.