Fix: CF7 contacts now created Subscribed by default (driven by the marketing opt-in checkbox), so automation journeys/mailings reach them. Previously hardcoded unsubscribed.
4.6.5
Feature: Contact Form 7 submissions now also flow into the FORTVISION Website-leads board. In addition to the existing contact capture (kept unchanged), every CF7 submission is forwarded to FORTVISION with the form id, form title and ALL submitted fields, so each form becomes a lead source with its own dynamic columns.
Feature: dual-write — submissions are sent to both the production and development FORTVISION environments. The development write can be turned off via the fortvision_dual_write_enabled option (default on) without a code change.
Fix: replaced the non-functional 60s transient deduplication with a per-submission idempotency key (sha1 of form id + timestamp + random), cached per CF7 unit_tag so a same-request double-fire reuses the identical key. Combined with a server-side unique index this reliably prevents duplicate leads end-to-end.
Note: the FORTVISION ingest base URLs are configurable via the fortvision_website_lead_url_prod and fortvision_website_lead_url_dev options.
Fix: corrected the default development ingest base URL to https://api.dev.fortvision.net (was previously pointing at the wrong host); still overridable via the fortvision_website_lead_url_dev option.
Fix: duplicate contacts still occurred in 4.6.3 when Advanced CF7 DB or redirect plugins triggered a second PHP request for the same submission. Replaced static-array dedup (single-process only) with a WP transient (60s TTL) that works across separate PHP processes.
4.6.3
Fix: unit_tag deduplication was not working because WPCF7_Submission::get_meta(‘unit_tag’) returns null in CF7 6.x. Now reads unit_tag directly from get_posted_data()[‘_wpcf7_unit_tag’]. This fully prevents duplicate contacts when Mail 2 is configured.
4.6.2
Fix: CF7 forms with Mail 2 (autoresponder) configured were creating two duplicate contacts per submission because wpcf7_before_send_mail fires once per mail template. Added deduplication by unit_tag so exactly one contact is created per form submission.
4.6.1
Fix: CF7 lead capture now hooks into wpcf7_before_send_mail instead of wpcf7_mail_sent. Sites where SMTP mail sending fails (e.g. WP Mail SMTP misconfiguration) would not capture contacts in 4.6.0 because wpcf7_mail_sent only fires on successful mail delivery. wpcf7_before_send_mail fires for every valid submission regardless of SMTP result.
4.6.0
Feature: Contact Form 7 integration. When a CF7 form is submitted successfully on a site with the FORTVISION plugin installed, the contact (email, name, phone) is automatically captured and sent to FORTVISION. Works without WooCommerce — activates for any WordPress site running Contact Form 7.
4.5.3
Fix: wp_users contacts (added in 4.5.2) were stored at the plugin-aggregator with their raw numeric user id instead of the wpuser_<n> synthetic id collected for them. Because the aggregator uses (id, publisher_id) as primary key, the wp_user row collided with the unrelated wc_customer_lookup row sharing the same numeric id and silently overwrote it. The id is now emitted with the wpuser_ prefix end-to-end.
4.5.2
Fix: historical contact sync was returning only wc_customer_lookup rows on stores that have WooCommerce Analytics enabled. That table only holds customers who placed an order, so registered users who never bought (newsletter subscribers, free signups) were silently excluded — up to half the contacts on a typical store. collect_customer_ids() now unions three sources and deduplicates by email: (a) wc_customer_lookup, (b) all wp_users with an email, (c) DISTINCT _billing_email from guest checkouts in wp_postmeta.
Fix: wp_users.ID and wc_customer_lookup.customer_id are independent auto-increment ids that can collide numerically — previously a wp_users-sourced contact could resolve to the wrong lookup row. v4.5.2 issues synthetic ids wpuser_<n> for the wp_users branch (mirrors the guest_<md5> scheme used for guest checkouts), and getCustomerById() routes each prefix to its dedicated resolver.
4.5.1
New: “Force resync all historical data” button on the Diagnostics page. Re-sends every order, customer, and product to FORTVISION in batches of 100 in the background. Safe to run repeatedly.
Fix: historical contact sync now covers stores that have WooCommerce Analytics disabled AND have guest checkouts (the v4.4.1 fallback only returned registered users; guests whose only address is in _billing_email postmeta were silently dropped).
Fix: getCustomerById() now falls back to wp_users+usermeta when wc_customer_lookup is empty, so historical sync produces a real contact for every registered user even on stores without WC Analytics.
Perf: chunk size for historical sync raised from 20 to 100 records per scheduled batch — 5× fewer cron events for the same dataset.
4.5.0
New: Diagnostics admin page (FORTVISION → Diagnostics) — side-by-side comparison of WooCommerce counts vs. FORTVISION platform counts so the publisher can verify the plugin stays in sync.
New: Catches customer/order paths missed by the previous hook set — woocommerce_created_customer (checkout-only customer creation), profile_update (admin/My Account edits), and woocommerce_order_status_completed (gateways that only fire the dedicated event).
4.4.1
Historical contact sync now works on stores with WooCommerce Analytics disabled. When wp_wc_customer_lookup is empty the plugin falls back to wp_users + guest-checkout _billing_email from wp_postmeta.
