WordPress.org compliance. All admin JavaScript and CSS is now loaded through the standard WordPress enqueue functions instead of being printed inline. The form-editor helper script and the connection-status styling load via wp_enqueue_script / wp_enqueue_style; there is no change to how the plugin behaves.
Hardening. Auto-response and recipient-rejection details returned by Broadcaster are now passed through sanitize_text_field() before being written to a Gravity Forms entry note.
WhatsApp Recipient field now uses natural tab order rather than emitting its own tabindex attribute. On the vast majority of forms this is invisible; forms that set a custom Gravity Forms tab-index start will see this field follow normal source order.
Maintenance: removed the placeholder Screenshots section from the readme until images are bundled, deleted an unused internal helper, and updated the development environment dependency.
1.1.3
Privacy disclosure. Added a Privacy section to this readme spelling out exactly what submission data is sent to Broadcaster, and registered suggested privacy-policy text in WordPress (Settings → Privacy) so site owners can disclose the data flow to their visitors. The plugin’s data handling is unchanged; this surfaces what already happens.
Admin notices are now scoped. The “Gravity Forms not active” and “API key not configured” warnings now appear only on the Plugins list, Dashboard, and Gravity Forms admin pages (where they’re actionable) instead of on every admin screen. Both still disappear automatically once resolved.
Maintenance: pointed the plugin / add-on link at the documentation page (getbroadcaster.com/docs/gravity-forms-addon), inlined output escaping in the form-editor inline script, and documented why the Gravity Forms tab-index attribute is emitted as-is. No functional change.
1.1.2
The auto-response outcome is now visible in Gravity Forms. After Broadcaster accepts a submission, the plugin reads the auto_response block from the response and writes a clearer entry note: “sent auto-response (<template>, slot: <in_hours|out_of_hours>)” when the reply went out, “auto-response failed: <error_code> – <message>” when Broadcaster declined to send it (e.g. a missing template placeholder or an unapproved template), or the existing “received this submission (HTTP 201).” when the feed has no template configured. The full result is also logged under Forms → Settings → Logging with the entry ID for correlation.
Fixed: the API response body was parsed from the wrong path, so the auto_response error code (used by the WhatsApp Recipient field rejection notices) was never actually read. It now reads data.auto_response correctly, so recipient rejections through a WhatsApp Recipient field surface inline as intended.
1.1.1
WhatsApp Recipient field now has a Field Size setting. Like other Gravity Forms fields, it now shows the Small / Medium / Large size control in the form editor’s field settings; previously the size was fixed and could not be changed from the editor. New fields still default to Large.
WhatsApp Recipient field can now be used in conditional logic. It now appears in the “based on” field list when adding conditional logic to other fields, feeds, notifications and confirmations, e.g. show or hide another field depending on whether a WhatsApp recipient was entered. Previously the field was missing from those lists.
National-format phone numbers are now shown (and stored) in international format. When a submitter types a national-format number into a WhatsApp Recipient field and moves to the next field, the value is rewritten to international format (for example 07714681600 becomes +447714681600, using the field’s or plugin’s default country) so the country assumption is visible before submitting. The Gravity Forms entry, exports and the feed’s recipient mapping then carry the international number. WhatsApp usernames (@name) are never altered; they are stored exactly as entered. If JavaScript is unavailable the number is still normalised when the entry is saved.
Fixed: uninstalling the plugin now removes its stored settings. A stale option name meant the connection, phone-country and related settings were previously left in the database after uninstall.
Maintenance: bundled the translation template (.pot), simplified how the add-on menu icon loads, refreshed the plugin home-page link, and added explicit ownership / trademark notes. No functional change.
1.1.0
New WhatsApp Recipient field. A dedicated custom field type, under Advanced Fields in the Gravity Forms editor, that captures the contact’s phone number in a single input and validates the format inline before form submission. Submitters see typos as a “Please enter a valid phone number” error and correct them on the spot, instead of having the form succeed and Broadcaster reject the lead silently downstream. Existing forms with stock Gravity Forms phone / text field mappings keep working exactly as before; the new field is opt-in.
New “Default phone country” plugin setting (Forms → Settings → Broadcaster → Phone normalisation). When a submitter types a national-format number into a WhatsApp Recipient field, this is the country we will assume. ISO-3166 alpha-2 picker covering United Kingdom, United States, Ireland, Australia, India, Indonesia. Each WhatsApp Recipient field also has its own per-field override for forms that target a different country than the rest of the site.
Broadcaster recipient rejections are now visible to administrators. When Broadcaster declines a recipient through a WhatsApp Recipient field (HTTP 422 on dispatch, or recipient_not_deliverable in the response), the rejection is surfaced inline beside the field on the Gravity Forms entry detail view, plus an audit-trail note in the GF notes panel and a one-line log entry under Forms → Settings → Logging. Form submission itself is never blocked; this only affects the diagnostic surface administrators see after the fact.
1.0.2
Critical fix: the v1.0.0 and v1.0.1 release zips were built without the plugin’s vendor/autoload.php, causing a fatal error when opening Forms → Settings → Broadcaster (Class “BroadcasterGFApiClient” not found). The release workflow now runs composer install –no-dev –optimize-autoloader inside the plugin directory before packaging the zip, so the autoloader and namespaced classes ship correctly. Anyone running v1.0.0 or v1.0.1 should upgrade immediately.
1.0.1
Tightened the WordPress.org short description to fit within the 150-character limit.
Release-workflow polish: corrected the vv1.0.0-style title in GitHub Release notes, fixed the boilerplate-leftover settings-path text, bumped actions/checkout and softprops/action-gh-release to versions that run on Node.js 24.
No functional changes to the plugin code itself.
1.0.0
Initial release.
Per-form Gravity Forms feeds that forward submissions into Broadcaster as incoming WhatsApp contact messages.
Optional in-hours / out-of-hours template auto-responses with comma-separated key:value placeholders and merge-tag support in values.
Connection settings under Forms → Settings → Broadcaster with live ✓/✗ feedback against the saved API key.
Production-locked Broadcaster URL (https://getbroadcaster.com); editable on dev/staging/local.
Source-label feed setting that populates the chat-bubble origin shown in Broadcaster.
Failures never block Gravity Forms confirmation or notification emails; diagnostics flow to Forms → Settings → Logging.
