Address and Phone Number Form Fields Missing on Frontend

[qasumitbagthariya]

Describe the bug

The address and phone number form fields are configured and available in the backend settings, but they do not appear on the frontend.

Expected Behavior:
Upon enabling the address and phone number fields in the Mailchimp setup under Merge Fields Included, these fields should be visible and accessible on the frontend.

Steps to Reproduce

1. Navigate to the WordPress Admin Dashboard.
2. Go to "Settings" and select "Mailchimp Setup" from the dropdown menu.
3. Inside the Mailchimp setup, locate and click on "Merge Fields Included".
4. Enable the fields for "Address" and "Phone Number".
5. Save the settings
6. Visit the frontend of the website.
7. Observe that the address and phone number fields do not appear on the subscription form.

Screenshots, screen recording, code snippet

Screen.Recording.2024-06-19.at.3.23.25.PM.mov

Environment information

Testing Environment

WordPress: 6.5.4
Theme: Twenty Twenty-Four 1.1
PHP: 8.1.23
Web Server: Nginx 1.20.2
Browser: Chrome
OS: macOS Ventura 13.3

WordPress information

No response

Code of Conduct

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

[dkotter]

I tested this myself on the latest release of the plugin, as I was curious if this was something newly introduced in our cleanup or an existing issue. I was able to reproduce the same problem there so confirmed it's not a new issue.

But after giving this more thought, I realized there's two sides to these settings. Within your Mailchimp account you can choose which fields are supported. I logged into our test account and find out that both the Address fields and Phone Number fields were not enabled, which is why they weren't showing in the plugin.

I've enabled those now and if you click the Update List button, it should pull in those new settings:

Once you do that, you should now see the Address and Phone Number fields on the frontend:

So this doesn't appear to be a bug, though there's certainly additional information that could be added to the readme explaining this or even better, making it clear in the settings that turning a field on will only work if that field is turned on within Mailchimp (or removing that setting all together if it isn't supported).

[jeffpaul]

Is there any way to validate via a Mc API what fields are available and either showing ONLY those in the form in the plugin or at least showing a warning next to disabled Mc fields that they need to enable on the Mc side to use in a form on their WP site (potentially trying to deeplink into where that would be in their account)?

[dkotter]

Is there any way to validate via a Mc API what fields are available and either showing ONLY those in the form in the plugin or at least showing a warning next to disabled Mc fields that they need to enable on the Mc side to use in a form on their WP site

Without getting to far into the code, it seems like we already make an API request to get this information, both when the account is first connected and when that Update List button is clicked. It just doesn't seem like we use this information to impact the settings we show.

I think this is definitely a great enhancement but I would mark that as a Future release item, not something needed for 1.6.0 (and I think there's other settings/admin UI changes we could do at the same time).

I do think for 1.6.0 it would be nice to update the readme with more details on how to set up a list on the Mailchimp side and how this impacts what actually renders on the WordPress side, as right now that isn't detailed at all and I just had to stumble around until I figured it out.

[jeffpaul]

I'll work on adding that into the readme, we can otherwise punt this to 1.7.0.

[jeffpaul]

and I think there's other settings/admin UI changes we could do at the same time

@dkotter what were the additional changes you had in mind to group with this issue?

[dkotter]

I honestly don't recall specifics at this point but I think it was just around updating the UI of that settings page to match better with WordPress (still looks/feels outdated) as well as looking to move most of the display settings into the block and shortcode, rather than controlling those globally (though may be nice to do both, set some global defaults and then have full control at the block level)