Session Objective

Diagnose and fix the contact form GCLID propagation problem reported by Joe Choniski and the CMO. The reported failure was that a user could load the contact page with a fresh URL value such as ?gclid=VERIFY789, but the form would save and submit an older cached GCLID instead. The required outcome was clear: the live URL GCLID must always win, and the server-side handler must map the submitted value into Litify field GCLID_Custom__c exactly.

Problem Presented

The contact form was suspected of saving a stale GCLID from browser storage instead of the live GCLID in the current URL. This would break the first step in the Google Ads offline conversion loop because Litify would receive the wrong click ID, or no useful click ID, even when a visitor arrived from a current paid-search click.

The CMO also asked for a server-side check of wp-content/mu-plugins/sal-custom-contact-intake-v2.php, specifically whether incoming gclid was mapped to the Litify field GCLID_Custom__c, case-sensitive, with the double underscore c.

Diagnosis

The frontend bug was real. The live shared attribution script in Kadence Element 62671, Attribution Capture - Google Ads GCLID and UTMs, read from sal_attribution_v1 localStorage and used this pattern:

if (!store[fieldName]) {
  store[fieldName] = value;
}
store["last_" + fieldName] = value;

That meant an older stored gclid could remain in store.gclid even after the current URL supplied a fresh gclid. The form hydration then preferred attribution[fieldName] before last_gclid, so the stale cached value could populate the hidden form field.

The server-side mapping issue was also real. The MU plugin was mapping the submitted GCLID to GCLID__c. Salesforce/Litify has both GCLID__c and GCLID_Custom__c, but the requested field for the intake dashboard is GCLID_Custom__c.

What Was Fixed

Backups were created before edits under:

/home/master/codex-backups/gclid-contact-fix-20260603-150939/

Frontend fix:

if (value) {
  store[fieldName] = value;
  store["last_" + fieldName] = value;
  changed = true;
}

This makes the current URL value overwrite stale browser storage and keeps last_gclid aligned with the fresh value.

Server-side fix:

$updates['GCLID_Custom__c'] = substr( $gclid, 0, 255 );

The browser form field remains named gclid. The WordPress handler maps that browser field into Litify as GCLID_Custom__c. This preserves the existing form contract and changes only the destination field mapping.

No changes were made to how the form submits, to the submitted browser field names, to the email delivery logic, or to the Teams/call-center alert logic.