opt-in checkbox appearing when not selected in admin

Hi @petefuseloft

No known issues around opt-in displaying on all forms when set for only one. It should be a per-form setting, with the enabled status stored as post meta. Do you have some links to where we can see the forms in question and which should vs shouldn’t have the output displayed?

Regarding the second part, have you seen any admin notification in the back regarding the plugin potentially having experienced some issues? There may be information in a hopefully generated error log for our plugin that could shed some light on this.

Hi @constantcontact Thanks for the speedy reply

This is a staging site that’s behind http basic auth. I’m not able to share that information publicly.

Strangely, the opt-in per-form settings were not visible at one point yesterday while I was working on the site. The opt-in started appearing on all of the Constant Contact forms across the site, without my changing anything. The per-form settings are now available again in the admin back-end. The opt-in is visible on the front-end, on every form, regardless of whether the checkbox is checked.

Since you mentioned that the status is stored as post meta, I checked and saw that there is a decent amount of orphaned post meta in this particular database. Could that cause this type of issue?

Where on the server does the plugin generate an error log?

Noted and understood on the staging detail.

I’m curious if there’s some CSS setting/change/selector that is causing the output to show. It’s a little odd, and perhaps should be changed in a future version, but we have the opt-in markup ready to display, but we set display: none; on it if the setting wasn’t checked for the form settings.

Regarding orphaned meta, unless it’s somehow tied to the individual post IDs for the forms, probably not.

For the logs, we try to put them in the uploads folder and ctct-logs directory in that. However, we have a setting in our overall options to toggle debugging, which should reveal a new menu item and a page that reads the contents of the log file, if any. Less need to force users to utilize SFTP to access and provide to support members.

I figured out the checkbox issue. It was a CSS rule on my end causing the problem.

We’re still not getting any of the form submissions in the constant contact lists.

I enabled the debug log, and added a new list in Constant Contact. The new list synced properly, and showed up in the plugin interface. I selected the new list for the form in question and saved the settings. Then I went to the front-end, did a couple test submissions, got the success message on the page. Unfortunately the entries don’t appear in Constant Contact, and there’s nothing showing up in the debug log.

Noted on the checkbox part, good to hear that was pretty straightforward in the end.

Is the textarea showing any messaging at all? or is it just blank?

If blank, then the file has been created and is being read, but may not have anything in it yet. If there is some sort of message, then it may not be on the server yet. Data that would be logged intentionally would start off with a timestamp.

With that said, it has me wondering what part may be failing at this point, and the understandable restricted access makes it more difficult for us to deduce on our end.

Are you at least getting email notifications of the signups? or did you disable those?

The textarea in the admin interface for the log is empty. There are no log files being written to the server — no new directory in the /uploads directory. The entire public html directory is writeable by the server. I watched the server’s error log as well, and there are no errors being logged there.

Yes, the email notifications are working.

I’m also not seeing any front-end errors (in the console), and I’m getting the confirmation message when I submit the form.

It appears like everything is working fine. The submissions just aren’t getting to my client’s Constant Contact account.

I’m not sure if this is normal for the plugin, or if it would cause a problem with submitting the data, but all of the fields appear to have duplicate DOM elements with identical IDs.

[DOM] Found 2 elements with non-unique id #ctct-id: (More info: https://goo.gl/9p2vKq) <input type=?"hidden" name=?"ctct-id" id=?"ctct-id" value=?"11903" placeholder class=?"ctct-hidden ctct-label-">? <input type=?"hidden" name=?"ctct-id" id=?"ctct-id" value=?"11882" placeholder class=?"ctct-hidden ctct-label-">?
(index):1 [DOM] Found 2 elements with non-unique id #ctct-instance: (More info: https://goo.gl/9p2vKq) <input type=?"hidden" name=?"ctct-instance" id=?"ctct-instance" value=?"0" placeholder class=?"ctct-hidden ctct-label-">? <input type=?"hidden" name=?"ctct-instance" id=?"ctct-instance" value=?"1" placeholder class=?"ctct-hidden ctct-label-">?
(index):1 [DOM] Found 2 elements with non-unique id #ctct-opt-in: (More info: https://goo.gl/9p2vKq) <input type=?"checkbox" name=?"ctct-opt-in" id=?"ctct-opt-in" class=?"ctct-checkbox ctct-opt-in" value=?"2023271803">? <input type=?"checkbox" checked name=?"ctct-opt-in" id=?"ctct-opt-in" class=?"ctct-checkbox ctct-opt-in" value=?"1350667618">?
(index):1 [DOM] Found 2 elements with non-unique id #ctct-submitted: (More info: https://goo.gl/9p2vKq) <input type=?"submit" name=?"ctct-submitted" id=?"ctct-submitted" value=?"Submit" placeholder class=?"ctct-submit ctct-label-">? <input type=?"submit" name=?"ctct-submitted" id=?"ctct-submitted" value=?"Sign up" placeholder class=?"ctct-submit ctct-label-">?
(index):1 [DOM] Found 2 elements with non-unique id #ctct-verify: (More info: https://goo.gl/9p2vKq) <input type=?"hidden" name=?"ctct-verify" id=?"ctct-verify" value=?"9w5AvacJ44GYpYCQNEH9plWqg" placeholder class=?"ctct-hidden ctct-label-">? <input type=?"hidden" name=?"ctct-verify" id=?"ctct-verify" value=?"ZW6CwVR2n4I5PSYpqM7AC74Dw" placeholder class=?"ctct-hidden ctct-label-">?
(index):1 [DOM] Found 2 elements with non-unique id #ctct_usage_field: (More info: https://goo.gl/9p2vKq) <input type=?"text" value name=?"ctct_usage_field" id=?"ctct_usage_field">?

@constantcontact I have a constant contact form on the live site that’s not submitting to the account, and appears to be working: https://beezlebrands.com/ – It’s the email signup field (just email address field) about 3/4 way down the page.

I see where the duplicate IDs are coming from now — On the staging site, I have a contact form in the page context, but I also have an exit intent modal, with email address field and submit button.

This duplicate id issue is probably not causing the data to not submit, but the form elements of each form could have unique IDs. Is this something I can submit as an issue in your repo or something?

I’ll file the details around duplicate IDs myself, as we don’t have a public bug tracker location for the plugin here.

Just submitted a test submission to the form and will see if we get any confirmation on my end regarding the signup.

@constantcontact I had a test entry make it from the single-field form on the live site homepage to the constant contact account.

I tried again from the staging URL, and now a 500 error appears in the console. I haven’t made any changes to that site. The only change I made was to restart the server after making some linux updates.

In ctct-plugin-frontend.min.js, all fields pass the validateSubmission function (checkValidity returns ‘true’ for each). Then I put breakpoints on every line in the method submitForm[post], and it doesn’t pause at any of them, after which, the page returns to normal state. There’s no confirmation message, nor an error message. The form fields don’t clear.

Below is the stack trace from the server’s error log – I sent a test email to double-check that the wp-smtp plugin wasn’t the issue. The test was sent successfully.

Stack trace:
#0 /var/www/staging.beezlebrands.com/html/wp-content/plugins/wp-mail-smtp/vendor/guzzlehttp/guzzle/src/Client.php(95): GuzzleHttp\Client->request()
#1 /var/www/staging.beezlebrands.com/html/wp-content/plugins/constant-contact-forms/vendor/constantcontact/constantcontact/src/Ctct/Services/BaseService.php(65): GuzzleHttp\Client->__call()
#2 /var/www/staging.beezlebrands.com/html/wp-content/plugins/constant-contact-forms/vendor/constantcontact/constantcontact/src/Ctct/Services/ContactService.php(36): Ctct\Services\BaseService->createBaseRequest()
#3 /var/www/staging.beezlebrands.com/html/wp-” while reading response header from upstream, client: 71.183.39.170, server: staging.beezlebrands.com, request: “POST /wp-admin/admin-ajax.php HTTP/2.0”, upstream: “fastcgi://unix:/var/run/php/php7.4-fpm.sock:”, host: “staging.beezlebrands.com”, referrer: “https://staging.beezlebrands.com/retailer-inquiry/”

• This reply was modified 4 years, 5 months ago by petefuseloft.
• This reply was modified 4 years, 5 months ago by petefuseloft.

Sadly, we have had a small history of conflict with other plugins using Guzzle as well, and we’re still trying to find a solid way to resolve this.

Based on the stack trace above, an email request ist started in WP-Mail-SMTP using that plugin’s copy of Guzzle, and then it ends up switching to use the version of Guzzle in our copy.

Not quite seeing the exact error encountered with this, if any, but there is a cross use.

Curious if the staging site would work without WP-Mail-SMTP involved, or if anything, email notifications disabled for our plugin.

That said, you mention that a submission reached all the way through in this case? at least once?

I see. I might have a workaround, provided that it doesn’t have the same Guzzle-related issue. I can set this site up to use AWS SES instead of using the WP Mail SMTP plugin. The server doesn’t have sendmail or any other mail server software installed.

I did have a submission reach all the way through, but not from this staging site. It was from the production site, which is also using WP-Mail-SMTP, and it’s on the same server.

*EDIT*
I set the site up to use amazon SES and it resolved the problem. For the record, I used WP Offload SES Lite plugin to set it up.

• This reply was modified 4 years, 5 months ago by petefuseloft.

@constantcontact I marked this as resolved, but it looks like there’s another issue occurring:

The name and email of the user were submitted to the clients Constant Contact account, but the email notification wasn’t sent.

Below is the output in the Constant Contact plugin’s log.

Question: Do the additional text fields (in this case, a textarea field for the user’s message) get stored in Constant Contact anywhere? Or do they just get sent in the email notification?

[2020-06-23 00:51:46] API.INFO: Contact set to be created [“Extra information”,[{“form”:”General Inquiries”}]] []
[2020-06-23 00:51:47] API.INFO: Submitted contact data [“Extra information”,[{“email___3c59495a3edf2d27cd20fc1987544522”:{“key”:”email”,”val”:”***@pete.test”},”email”:”***@pete.test”,”first_name___185b795264e09a98fe0f4e47e70e8e90″:{“key”:”first_name”,”val”:”Pete”},”last_name___7844763b59c9491b69645b716220aad7″:{“key”:”last_name”,”val”:”Thompson”},”custom_text_area___c90cc625c211449ec4500195650d86b8″:{“key”:”custom_text_area”,”val”:”Testing the general inquiry contact form”},”ctct-instance”:{“key”:”ctct-instance”,”val”:”0″},”list”:”2023271803″}]] []

Text fields should be getting saved as custom fields in the constantcontact.com and the first textarea should be getting saved as a note.

They should also be a part of the email notification, when that gets successfully sent out.

Thanks for all your help.

I see. Is there any way to show the title of the custom text fields, in the Constant Contact interface, so the end user (client) can see the label?

For example, if we set up several fields for an inquiry form, and the client sees something like “License Number: 123456767” “Where did you hear about us: Social Media”, it would be a substantially more useful than “Custom Field 1: 123456767” “Custom Field 2: Social Media” – which could turn into a difficult thing to manage over time.