Skip to content

Releases: CCDevelopment/progressio-performance-tracker

v1.4.0 — Elementor Pro Forms support + CTA depth fix

Choose a tag to compare

@CCDevelopment CCDevelopment released this 17 Aug 16:51

Added

  • Elementor Pro Forms support. GA4 form_submit now fires on Elementor's submit_success event, so only genuine successes are counted. Lead capture hooks elementor_pro/forms/new_record and posts to the Leads API.
    • Previously, Elementor submissions reached GA4 only through the generic submit fallback — which fires on the submit attempt, so reCAPTCHA-blocked and validation-failed submissions were counted — and never reached the Leads API at all.
  • "Elementor Pro Forms" added to the Form Plugin setting.

Fixed

  • CTA clicks were not tracked in nested page-builder markup. The matcher walked only 3 ancestors from the click target; Elementor nests button text 5–6 levels below the CTA class, so cta_click never fired on those sites. Matching is now by nearest ancestor with no depth limit, scoped to real controls (a, button, [role=button]) so a CTA class on a wrapper cannot turn every click inside it into an event.
  • cta_click now reports link_url correctly when the CTA class sits on a wrapper rather than on the link itself.
  • CTA class settings now tolerate multi-class values (btn btn--action) and stray leading dots; an unusable value is skipped instead of throwing on every click on the site.
  • readme.txt stable tag corrected (had drifted to 1.0.1).

Upgrade note

On sites where CTAs were previously silent, cta_click goes from zero to full volume on upgrade, and form_submit on Elementor sites drops slightly (successes only, no longer attempts) with form_plugin changing from generic to elementor. Annotate your GA4 property on the deploy date, and review any Google Ads conversion import or bidding that uses cta_click.

v1.3.0 — Fix WS Form lead capture

Choose a tag to compare

@CCDevelopment CCDevelopment released this 06 Jun 20:21

Fixed

  • WS Form leads now captured. WS Form submits over admin-ajax, so the previous rest_post_dispatch REST interception never fired and no leads were sent. The handler now uses WS Form's native server-side action hook wsf_submit_post_complete, which fires after any successful submission regardless of transport.
  • Field ids are mapped to labels and types from the WS Form form object, so name/email/phone extraction works reliably (email/tel field types are detected even with generic labels).

Upgrade note

Existing installs must confirm the saved Leads Endpoint in WP settings is https://dashboard.progressiodev.com/api/leads — the stored DB value overrides the code default.

v1.2.2 — Fix leads endpoint hostname

Choose a tag to compare

@CCDevelopment CCDevelopment released this 06 Jun 19:43

Fix

The default Leads Endpoint URL pointed at dash.progressiodev.com, which has no DNS record — so wp_remote_post() failed to resolve the host and leads silently never reached the dashboard (the call is fire-and-forget, so no error surfaced).

Corrected the default to the live host dashboard.progressiodev.com/api/leads in all three code locations.

⚠️ Existing installs

Updating the plugin alone is not enough — the wrong URL is already saved in the database. On each site, go to Progressio Performance Tracker → Settings → Leads Endpoint URL and set it to:

https://dashboard.progressiodev.com/api/leads

then save.

v1.2.1 — Fix plugin slug & auto-updater path

Choose a tag to compare

@CCDevelopment CCDevelopment released this 06 Jun 19:32

Fixes

  • Plugin slug restored — main file renamed back to progressio-performance-tracker.php (dashes). v1.2.0 shipped as progressioperformancetracker.php, which made WordPress treat the upload as a new plugin instead of an update. Restoring the original slug means client sites recognize this as an update again.
  • Auto-updater path fixed — the update checker (YahnisElsts PUC) was moved from vendor/ to includes/ to match the require path in the main file. Previously file_exists() returned false and the updater silently never loaded.

No functional changes to lead capture or GA4 tracking — the v1.2.0 server-side lead hooks are unchanged.

v1.2.0 — Refactor lead capture to PHP server-side hooks

Choose a tag to compare

@CCDevelopment CCDevelopment released this 06 Jun 19:02
v1.2.0 — Refactor lead capture to PHP server-side hooks

v1.1.1 — WS Form handler updated

Choose a tag to compare

@CCDevelopment CCDevelopment released this 06 Jun 13:39
Fix WS Form lead capture — add jQuery listener and preSubmitCapture

v1.1.0 — Leads Capture + Auto-updater

Choose a tag to compare

@CCDevelopment CCDevelopment released this 04 Jun 21:40
Bump to v1.1.0, wire up auto-updater

v1.0.2

Choose a tag to compare

@CCDevelopment CCDevelopment released this 03 Jun 23:10

Security & performance hardening

Security

  • Coerce sanitize_options() input to array to prevent a TypeError fatal on empty/non-array submissions
  • Use context-appropriate escaping for the GA4 measurement ID output

Performance

  • Consolidate four document-level click listeners into one delegated handler
  • Cache attribution data instead of re-parsing sessionStorage on every event
  • Detach the scroll listener once all depth milestones have fired
  • Gate the generic form handler to prevent double-counting in auto-detect mode