Block settings updates

[jeffpaul]

Is your enhancement related to a problem? Please describe.

1. Remove Header and Sub-header from display and turn into H2 and H3 if present.
2. Allow Submit button to be editable, defaults to “Subscribe”.
3. Move existing Color/Dimensions/Border to a Styles tab in the Block sidebar.
4. Add Appearance, Line Height, Letter Spacing, and Letter Case options to the Typography section.
5. Add Settings tab in the Block sidebar. Add “Audience” dropdown single-select with default to the value in “Update List” from plugin settings.
6. Add “Form Fields” to Settings tab with default toggle enabled of “Show default fields”. If toggled to disabled, then expand to show full list of fields for the Audience selected with each field having its own toggle and each defaulted to enabled (based on the linked Mailchimp’s account Audience fields settings) which relates to enabled===visible and disabled===hidden. There’s also the concept of “Required field” on Mailchimp, so perhaps consider a checkbox for that alongside each field (though I worry that might get too cluttered in the sidebar, so perhaps a note at the bottom like “Update required fields in the Mailchimp.com form builder.”?). Alternatively two checkboxes for each field of “Required” and “Visible”?
7. Add Advanced section (that’s collapsed by default) in the Settings tab of the Block sidebar. Add “Double Opt-In” with toggle defaulted to enabled. Helper text of “Before new your subscribers are added via the plugin, they'll need to confirm their email address.”
8. Add “reCAPTCHA” with toggle defaulted to disabled to the Advanced settings. Helper text of “This helps prevent spambots from adding emails to your audience.”
9. Add “Update existing subscribers” with toggle defaulted to enabled (this feels like the “right” default here?) to the Advanced settings. Helper text of “If an existing subscriber fills out this form, we will update their information with what's provided.”
10. Add “Include Unsubscribe link” with toggle defaulted to disabled to the Advanced settings. Helper text of “We'll automatically add a link to your list's unsubscribe form.”
11. Update existing plugin settings page to change “Your Lists” to “Form Shortcode Settings”. Probably worth noting above that and below the login/logout function something like “Form settings for the Mailchimp List Subscribe Form block are now located in the Block sidebar panel.”

Future: allow form labels to be editable (slight UX consideration here for how we make it clear what field label relates to what field in Mailchimp).
Future: add Groups, Segments, and Tags options to Block sidebar settings.

Designs

Describe alternatives you've considered

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

[jeffpaul]

@dkotter open to any tweaks to this that you'd recommend?

[jeffpaul]

One other item that I'm not certain exists in the WordPress form rendering are Mailchimp's honeypot fields that exist in their platform's form renderings. Do we include any of those as part of the WordPress form renderings (block or shortcode forms) to ensure that if a spambot were to fill out those invisible honeypot fields that related submissions are flagged as spam and discarded?

[dkotter]

Add “reCAPTCHA” with toggle defaulted to disabled to the Advanced settings

I don't believe this is something we support right now, unless I'm forgetting. Is this an option within Mailchimp when creating your list?

Update existing plugin settings page to change “Your Lists” to “Form Shortcode Settings”.

I almost think we can be a little more drastic here and remove most of these settings all together and have these be things that can be manually set in the shortcode (ensuring we take existing settings into account for backwards compat). Easier to leave these in place but also worry about the confusion it creates and would love to push people to the new block based approach.

Or could also keep these settings but set them as "Global Settings" and use those as the defaults, then allow each individual piece to be overridden at both the block and shortcode level.

One other item that I'm not certain exists in the WordPress form rendering are Mailchimp's honeypot fields that exist in their platform's form renderings. Do we include any of those as part of the WordPress form renderings (block or shortcode forms) to ensure that if a spambot were to fill out those invisible honeypot fields that related submissions are flagged as spam and discarded?

As far as I'm aware, we don't include these right now

[jeffpaul]

I don't believe this is something we support right now, unless I'm forgetting. Is this an option within Mailchimp when creating your list?

Correct we do not support this right now but its an option on the Mailchimp side, so assuming its something that can be set via their API and then pulled in to render on the WP frontend then it seems helpful to add it to help limit spambot form fills.

I almost think we can be a little more drastic here and remove most of these settings all together and have these be things that can be manually set in the shortcode (ensuring we take existing settings into account for backwards compat). Easier to leave these in place but also worry about the confusion it creates and would love to push people to the new block based approach.

Happy to be more drastic with the updates here. Did you have things you'd think would still exist within the settings page then?

As far as I'm aware, we don't include these right now

If the reCAPTCHA isn't feasible, then I'd really like to get these added to help prevent spambot form fills.

[dkotter]

Happy to be more drastic with the updates here. Did you have things you'd think would still exist within the settings page then?

I don't see anything in the current settings page that is needed if we make all the changes suggested in this issue, as all those settings could then be handled at the block level. Does mean that page wouldn't be used for anything other than connecting your account.

As mentioned, I could see benefit in leaving most of the settings and using those as our defaults, though I think if we do that, I'd still suggest getting rid of some of the settings:

• Custom styling options
• Javascript support
• Javascript datepicker
• CSS cheat sheet

[jeffpaul]

    Custom styling options
    Javascript support
    Javascript datepicker
    CSS cheat sheet

Some of that could also be off-loaded to the readme/FAQ perhaps?