After upgrading to CRED 2.1.2, my email notifications are longer being sent. The same is happening on two test sites. Emails outside the website are working, my smtp plugin (Easy WP SMTP) hasn't changed nor have any Google settings and I've tried deactivating/reactivating mail & CRED plugins.
I've rolled back to CRED 2.1.1.2 and the notifications are now working again.
Can you report this to the developers please. Thanks
I'll be glad to take a look. Can you export the Types and Forms data from this site using Toolset > Export? I will try adding those on a local site to reproduce the problem in Forms 2.1.2. The private field here will accept any download URL. Let me know which specific notification I should test.
Okay thank you, I was able to download the Forms and Types information and run some tests locally. I added my own valid recaptcha key and inserted the Message_Create Form on a new custom Page. I submitted the Form successfully when logged in as my administrator account. The mail log reflects that the User notification was sent correctly but the Admin notification was not. It turns out that the Admin notification was configured to send to a User from the original site that obviously doesn't exist on my local site, so this failure can be explained by the missing User account. I modified the "to" setting to point to my admin user instead, and saved the Form. The next Form submission triggered both Admin and User notifications, with Forms 2.1.2 active. So there must be something else going on, and I'm not sure exactly how to proceed.
I don't have the ability to replicate a LiteSpeed server to test Litespeed Caching, and I don't have SMTP testing capability. Heartbeat Control is another variable to consider here. Is there a staging environment available where we can run tests to try to pin down the problem?
Hi Christian
Thank you for doing your tests. I do have a dev/test site but I keep it completely locked down with access only to my IP address. The live site doesn't receive heavy traffic so I'm not too worried about you running some tests on it but I'd like to know what you would intend doing before I provide access.
Before we go down that road though, I used my test site this morning with just toolset plugins activated (Easy WP SMTP plugin is installed but not activated). The site is hosted on the same server as the live one but without Litespeed Cache plugin or Heartbeat. Using CRED 2.1.2 and native wordpress mailer, the email notifications are sent successfully. When Easy WP SMTP plugin is activated, they became erratic. I then deactivated Easy WP SMTP plugin and installed WP Mail SMTP. The 'test email' was successful but I experienced exactly the same issues with this one too with CRED 2.1.2 activated.
I think it's clear that the issue here is that the change/s in CRED 2.1.2 have rendered Toolset forms incompatible with SMTP mail plugins. I think the developers have no choice but to address this. WP Mail SMTP has over 1 million installs and Easy WP SMTP over 300,000; they are the top two in the wordpress plugin arsenal for managing emails. Not using an SMTP plugin these days is not an option; there are security and performance benefits that simply can't be ignored.
If you still want to run tests on my live site, let me know what you would want to do (if you wanted to test WP Mail SMTP I'd need to set this up for you beforehand).
When Easy WP SMTP plugin is activated, they became erratic.
Okay thanks for that analysis. If the SMTP plugin is the only variable in those cases then I probably don't need to run tests on your environment. If it's possible for me to replicate the problem locally with only Forms and an SMTP setup, I'll have what I need to make a report. I need to investigate more, and I'll update you soon.
Okay I was able to set up a live site with access to an SMTP server and run some tests. The Form submissions were successful and the email notifications were sent as expected. I'm using Forms 2.1.2 and Easy WP SMTP on this site. So I'm not sure what could be causing the problem on your side. I think the next step is for me to clone the whole site and test the whole clone instead of just the Forms and Types information. If you agree, I'll need a full Duplicator clone or access to wp-admin so I can create one.
Hi Christian
Sorry for checking but have you submitted the form more than just once? (the behaviour is different each time).
As this is a live site, it contains other people's data. I tried following Toolset's instructions for anonimising this in the database but the update queries remove the ability to then sign in as Admin and create the Duplicator clone. I also recall having issues with Duplicator in the past; it was something to do with my wp-config file being located outside public_html and Duplicator consequently perceiving there either isn't such a file or it's invalid (presumably because the contents aren't as expected).
I created my own dump files for you as I've done in the past (database and website files) with other people's data removed but you haven't provided a field for me to give you the download link. Can you provide this please? Thanks
...have you submitted the form more than just once? (the behaviour is different each time).
Yes, today I ran 6 additional tests with the same results.
Private reply fields are enabled here.
Okay I've uploaded the site clone to my staging site with SMTP capabilities, and I'm still not able to reproduce the problem. I sent 4 tests today using the create-message Form. All 4 tests were sent and received successfully. The only things I have changed are:
1. The Admin email notification is set to send to a specific email address (mine).
2. I have disabled Wordfence and LiteSpeed Cache
3. I have updated to the latest version of all Toolset plugins
4. All the usual database updates for migrating the site to a different URL.
I'm stumped, and without being able to replicate the error I'm not sure how to move forward. I will attach the log file in my next private message.
Hi Christian
Thank you for testing even though this is so not what I wanted to hear 🙁
Thinking about the possible differences between your & my installs, I've concluded it's either down to google's 2-factor authentication or the server environment. So, I turned 2-factor authentication off and tried the contact form again and the emails sent. But as I've done so much testing with this on, that off and back again, I thought I'd better check which version of CRED I had installed before I got too excited. I was logged into cPanel at the time so checked the changelog file in cred and it said:-
2.1.2
- Added a filter to extend the list of status values supported when trying to edit a post using edit links.
2.1.1.2
- Fixed a problem that blocked frontend javascrpt validation.
- Fixed a problem with legacy edit links producing forms not totally initialized.
on the first few lines but when I looked in wp-admin it showed version 2.1.1.2 and was prompting me to upgrade. So I upgraded to cred 2.1.2 and checked the changelog again and now the first few lines in the changelog say this:-
2.1.2
- Added a setting for the Media button on WYSIWYG editors in user forms.
- Added a setting for hiding comments on pages rendering an user forms.
- Added a separated setting for controlling Toolset buttons over WYSIWYG editors in forms.
- Added validation to usernames in user forms, following the WordPress rules.
- Added a filter to extend the list of status values supported when trying to edit a post using edit links.
- Fixed the context of the message that can be displayed after submitting a form, to set the right global post or user.
- Fixed an issue with frontend validation when submitting a form affecting all forms in the current page.
- Fixed the management of the default category on forms creating or editing native posts.
- Fixed an issue with notifications on user forms not being sent to the user set by a generic field.
- Fixed an issue with notifications not being sent when forms are used inside some page builders.
- Fixed an issue with non Toolset fields under Forms control not applying default values.
- Fixed an issue with non-Toolset fields under Forms control as checkbox fields that were always rendered as checked.
Notice the 2.1.2 at the top of both? Well that prompted me to double check which version of CRED was in the site dump files I sent to you and sure enough it was 2.1.1.2 but I thought it was 2.1.2 because that's what the changelog said (& was obviously wrong).
I'm going to approach my hosting provider as they're the last piece in the puzzle but before I do, can you confirm whether or not you upgraded CRED to 2.1.2 before doing your testing please?
I so hope you're going to tell me you didn't (so you can upgrade and re-test) because if this issue can't be solved, my sites are dead in the water (and so am I)
I just double-checked on my staging server and I am definitely running Forms 2.1.2. That was one of the few changes I did make to the duplicate site before testing, along with the updated SMTP information and email notification destination changes.
Maybe it would be a good idea to start a dialog with the SMTP plugin developers and see if they have any advice. It's possible they recognize these error codes and have experience troubleshooting them? If there is anything I can offer to help facilitate that discussion, please let me know and I will be glad to provide any necessary information.
Yes, I will be approaching Easy WP SMTP and my hosting provider despite the fact that CRED has changed, not my plugin. If you told anyone in the wordpress community that you were having problems after upgrading a plugin and those problems went away when the plugin was rolled back, you'd be saying the plugin was at fault.
Regardless of you not being able to replicate this issue, do you not find it strange that I'm having email problems after the last update of CRED which included some changes relating to email notifications:-
- Fixed an issue with notifications on user forms not being sent to the user set by a generic field.
- Fixed an issue with notifications not being sent when forms are used inside some page builders.
Given the severity of the consequences here, I really think a discussion with the Toolset developers is called for.
I contacted both google and my hosting provider yesterday. The checks with google conclude there's no issue with my gmail setup and my hosting provider hasn't made any changes that would affect email traffic.
So, I've carried out a further 12 hours testing using a brand new multi site install (with the main and a sub site) on my test site to try to really nail this thing down.
Initially I only installed Easy WP SMTP and another developer's contact form. I set up a temporary mailbox in cPanel using an address that doesn't exist in gmail. I added settings to Easy SMTP to use this temporary mailbox and my hosting provider's server. I set up a form on both sites to email me and the sender. All emails were sent successfully. I then changed Easy SMTP settings to use gmail & my gmail account. All emails were sent successfully. I believe this ascertains there is neither a problem with Gmail nor Easy SMTP.
I then deactivated the contact form plugin and installed Types & Forms (2.1.2). I repeated the exercise and all emails were sent successfully.
I then added Access to the mix, repeated the exercise and again all emails were sent successfully.
I then added Views to the mix, repeated the exercise and started having issues with emails not being sent when using gmail's server and my gmail account.
I then downgraded CRED to 2.1.1.2, repeated the exercise and all emails were sent successfully.
It would seem then that there is an issue when CRED 2.1.2 and Views 2.6.4.2 are activated.
On my CRED forms I added several custom fields so I could record at the time of form submission whether I was using gmail or the temporary mailbox and whether View or Access were activated. I then followed up in wp-admin to record the emails received. The overall results can then be seen in wp-admin. I've included a screenshot of part of it from the main site so you can see what I mean.
My test site is completely locked down to only me as I don't want any chance of it being indexed. I'm happy to give you FTP access so you can add your own IP address temporarily to my htaccess file and you can have a poke around as Administrator or I can send you dump files.
I don't understand why you weren't able to replicate this issue with the dump files from my other site. I'm not imagining this issue; it's very real and it only started when I upgraded to CRED 2.1.2.
sorry forgot the screenshot
