feat: support other newsletter signup forms

[dkoo]

All Submissions:

• Have you followed the Newspack Contributing guideline?
• Does your code follow the WordPress' coding standards and VIP Go coding standards?
• Have you checked to ensure there aren't other open Pull Requests for the same update/change?

Changes proposed in this Pull Request:

The plugin currently fully tracks only Jetpack Mailchimp block forms as newsletter subscribe form submissions. This PR adds handling for MC4WP forms, Gravity Forms, and arbitrary forms, the latter two via a .newspack-subscribe-form class name. The class name and the name of the field containing the user's email address are now filterable via the following filters:

• newspack_campaigns_form_class - The class name of the subscribe form.
• newspack_campaigns_form_selector - The CSS selector used to target the form for tracking submit events. If the form being tracked is a Jetpack Mailchimp or MC4WP form, it will be the selector for those form types (which generate consistent markup). Otherwise it will use the result of newspack_campaigns_form_class to build a selector.
• newspack_campaigns_email_form_field_name - The value of the name attribute of the input field containing the user's email address. The value of this field will be reported as the user's email address upon form submission. This filter also reports the value of the selector as the second argument so you have an idea of whether a form in each prompt is a Jetpack block, MC4WP block, a Gravity Form, or a custom form.

Note: The Gravity Forms UI does not allow for customization of input name attribute values, so the default implementation assumes that the first field in any Gravity Form block is the email address. You can use the newspack_campaigns_email_form_field_name filter to alter this assumption if your Gravity Form has a different field structure. Because of this behavior, any Gravity Form inside a prompt will be assumed to be a newsletter subscribe form unless the newspack_campaigns_email_form_field_name filter returns a falsy value. 7a53a80 fixes this issue by requiring Gravity Forms forms to have the newspack-subscribe-form (specifically the filtered result of newspack_campaigns_form_class) class name applied via form settings, as well as a field of type email. This is to prevent false positives from tracking Gravity Forms forms that may not be intended as subscribe forms.

Closes #791.

How to test the changes in this Pull Request:

Make sure you test with a site that's fully connected to Jetpack, Mailchimp, and Google Analytics via Site Kit. Note that you may need to test this with a live staging site rather than a local environment. ngrok environments in particular may not be able to connect to GA and therefore may not print all of the event config needed to test.

1. Create a prompt and insert a Jetpack Mailchimp form block.
2. View the prompt in an incognito session and view source. Search for "on":"amp-form-submit" and confirm there are two event config objects in source: one should have an event name of Form Submission and the other should have an extraUrlParams property containing the client ID, email address input name, and other data.
3. Install Gravity Forms (DM me for a license key) and create a "newsletter subscribe" form with an email address input field. In form settings, apply the newspack-subscribe-form class name to the form. Replace the Jetpack Mailchimp block in your prompt with a Gravity Forms block pointing to your newsletter form.
4. Repeat step 2 and confirm that there are still two event config objects in source with selectors matching the form markup.
5. Install the MC4WP plugin and set it up with a Mailchimp API key (DM me if you need one). Create a form pointing to your Mailchimp list and containing at least one input field with a name="email" attribute. Replace the form in your prompt with a "Mailchimp for WordPress Form" block pointing to your MC4WP form.
6. Repeat step 2 again and confirm that there are still two event config objects with selectors matching the form markup.
7. Edit your prompt and replace the form block with an HTML block containing the following HTML:

<form class="newspack-subscribe-form">
	<input type="email" name="email" placeholder="Email address" />
	<button>Submit</button>
</form>

8. Repeat step 2 again and confirm that there are still two event config objects with selectors matching the form markup.

Other information:

• Have you added an explanation of what your changes do and why you'd like us to include them?
• Have you written new tests for your changes, as applicable?
• Have you successfully ran tests with your changes locally?

[adekbadek]

the default implementation assumes that the first field in any Gravity Form block is the email address

That feels like casting a much wider net than expected. Any submission of a GF form would mark the reader as a subscriber. And even if the form is a newsletter signup form, the assumption that the email input is the first input is not very reliable IMO. I think this implementation would result in a high rate of false positives for subscriber segmentation.

It might be possible to use DOMXpath to find the name attribute of a type="email" input inside a form. If that's not possible, I'd rather opt for dropping the direct GF integration and instruct users to add newspack-subscribe-form class to any email-signup form:

[dkoo]

That feels like casting a much wider net than expected. Any submission of a GF form would mark the reader as a subscriber. And even if the form is a newsletter signup form, the assumption that the email input is the first input is not very reliable IMO. I think this implementation would result in a high rate of false positives for subscriber segmentation.

@adekbadek That's a good point. 7a53a80 avoids false positives by requiring the following for a Gravity Forms form to be tracked as a subscribe form within a prompt:

1. The form must have the newspack-subscribe-form class name applied in the form's settings. This makes the feature opt-in so that admins must intentionally add tracking to Gravity Forms forms they want to track.
2. The form must also have an email-type input. This field's value will be reported as the user's email address upon submit. I also thought about tying this to a second class name in case a subscribe form might have more than one email field for different purposes, but I think that's probably unlikely—WDYT?

[adekbadek]

🙌

[matticbot]

🎉 This PR is included in version 1.52.0-alpha.1 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀

[matticbot]

🎉 This PR is included in version 1.52.0 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀