Jared Atchison

Hi @harryfear,

I really appreciate the insights. We’re going to be adjusting this in an upcoming update to try and avoid these caching conflicts.

Sorry for the hassle here!

Jared

Hi @pollensteyn (and @b3nn0),

Thanks for the report and all the details.

We’ll get this fixed up in our next update.

Sorry for the trouble but I really appreciate the bug report.

Have a good one,

Jared

Hey @generosus,

Appreciate the feedback and the insights – it was very helpful!

The gist of things is that this change was well-intentioned, but we missed the mark a bit.

With the popularity of both plugins, our support team is regularly helping users that are confused or in a bind when using both solutions.

So we know it’s a valid (and growing) concern since we see it firsthand, frequently.

This notice was added as we try to mitigate/help with that.

That said, as you outlined, both plugins can in fact work together with no issues when configured correctly.

So we’ll be releasing a minor update soon that removes this notice.

In the future, we’ll introduce another notice that is more surgical, meaning it only will show if we see that configurations are set in such a way that is likely causing conflict. This notice will be specific to the problem and link to a detailed doc we’ll create that explains the problem with clear steps to address them ??

This way we’re still addressing the problem, but more accurately.

Thanks again for your detailed and honest feedback, it really helped bring this to our attention and plan the next steps.

Jared

As Gregor mentioned, thanks for helping dive deeper into this.

I know in 5.5 WordPress core added better opcache support so that cache is cleared when WP/plugins are installed/updated (https://core.trac.www.ads-software.com/ticket/36455).

Seems that isn’t a part of the plugin uninstall routine, but I don’t see a trac ticket for that either ???♂?

Thanks for the insights, I appreciate it.

We don’t create a wp_mail_smtp table (only the two you mentioned), so that sounds part sounds right.

All connection data (eg Gmail settings) is stored in wp_options table inside a wp_mail_smtp option.

Since post-uninstall it sounds like you have less rows in wp_options related to WP Mail SMTP, that seems like the uninstalled at least partially worked.

We’ll do some digging and testing on our end.

Since you’re not defining anything in the wp-config.php, the uninstaller should be deleting the wp_mail_smtp option from the wp_options table. It houses the vast majority of all plugin settings, so when that gets removed all the configuration data goes with it.

We will follow up with more next week once we have done some investigating.

Thanks!

I mentioned this in the other thread (https://www.ads-software.com/support/topic/is-everything-deleted-from-database-when-app-is-deleted/#post-15686145) but wanted to follow up here just for visibility.

When that plugin setting is enabled, uninstalling the plugin should remove EVERYTHING – including the Gmail settings you mentioned.

We’re going to be investigating this because if this isn’t the case then it’s a bug and we need to fix it.

When you reinstalled the plugin, was all the WP Mail SMTP data/options still present or just the Gmail specific ones?

We store most of our data in a single database option (wp_mail_smtp) which we remove during the full install (see https://github.com/awesomemotive/WP-Mail-SMTP/blob/master/uninstall.php#L179).

My best guess is maybe for some reason the uninstall didn’t run at all, but if that’s the case all the data/settings would have been there when you reinstalled.

Let me know!

Thanks ??

Enabling the “Remove ALL data” option in the plugin settings prior to uninstallation definitely should remove _everything_ from the database.

Sounds like that’s not the case for some reason – sorry about that!

We’ll be investigating this internally early next week to see if we can replicate the issue and if so get that fixed.

This is a long shot, but worth mentioning – settings can be persistent regardless of uninstallation if they are set inside the site’s wp-config.php (see https://wpmailsmtp.com/docs/how-to-secure-smtp-settings-by-using-constants/). So I’d also double check there’s nothing in that file that contains WPMS_GMAIL_.

Thanks!

Hey @bz61vl0p,

We do not load Google fonts anywhere within WPForms. We rely on the fonts that the theme (frontend) and WordPress (backend) define.

If you have any other questions just let us know.

Thanks!

Jared

Hey @barbara133,

I’m sorry to hear that, but I’m confident we can get this turned around for you ??

We don’t provide phone support or a even public phone number, so I promise we’re not specifically ignoring your calls!

Submit a ticket to https://wpforms.com/account/support/ and we’ll get back to you ASAP. All tickets are typically answered within an hour – were your previous emails sent using our support form?

We’ll be on the lookout.

Thanks,

Jared

Hey @seokai,

Unless a form is placed in location that displays globally on your site (such as a footer widget), all WPForms assets and dependencies – including jQuery and reCAPTCHA – are only loaded for pages that contain a form.

Just to triple check this, I spun up a new WordPress install with only the TwentyTwenty theme and WPForms Lite activated. I then created a /contact page which has WPForms embedded on it.

Viewing the home page and looking at the source, there’s no references to jQuery (https://a.cl.ly/DOuxr7mY) or reCAPTCHA (https://a.cl.ly/WnuJDPq4).

However, once I go to the Contact page which contains a form jQuery (https://a.cl.ly/OAuqje80) and reCAPTCHA (https://a.cl.ly/YEuoW0kb) are indeed included.

I know that it’s common theme and plugin functionality to require jQuery, so my best guess is likely the theme or another plugin that is requiring it globally.

With reCAPTCHA, it’s not as common, but we have seen themes that integrate with reCAPTCHA out of the box load the embed script globally. If you look at the reCAPTCHA script tag, if it doesn’t contain wpformsRecaptchaLoad (https://a.cl.ly/xQuLx8N0) then that’s a good indicator it’s loading from a call outside WPForms.

Worth nothing, it IS possible to load WPForms assets on every page, but it’s not enabled by default – it’s a nuclear option we provide to users with theme conflicts and similar. Just to be safe, if you go to your WPForms Settings, you’ll see a checkbox for “Load Assets Globally” (https://a.cl.ly/jkuZWN0k).

As far as jQuery as a dependency in general, I do agree that it would be ideal to not need jQuery at all. The thing with that is many of the libraries we use (validation, time picker, payment validation, etc) are jQuery libraries – so finding adequate replacements for these all while attempting to keep backwards compatibility would be a big under taking. That’s not to say it won’t happen, but it will take careful planning and execution.

The other thing is jQuery provides us with a toolkit of helper functions. The library itself is around 34kb gzipped delivered, but refactoring all functionality with vanilla JS and then transpiling could very well negate any gains ditching the dependency itself.

Lastly, we do very much care and pay attention to page load times and general site overhead, because with over 3M sites using WPForms, it’s our duty. We do frequently profile and benchmark releases, so if you see something that looks “off” to you, please let us know so we can investigate.

Anyways, we do really appreciate all feedback. Hope this helps provide some context to things.

Have a great weekend,

Jared

Hey @minhazul007,

Thanks for reaching out, great question.

We’re constantly reviewing our integrations based on user feedback and our teams’ own experience.

After our recent evaluation we determined that while the Pepipost has served many users well over the past year, other transactional mail services such as SMTP.com or Mailgun are currently able to provide a better experience to our users.

Existing sites using the Pepipost mailer will continue to be supported and will receive mailer updates as needed.

Hope that helps ??

Jared

They existing “Honeypot” anti-spam form setting is being deprecated, because it’s not as effective as it was years ago – spam bots are more clever and they know to ignore the honeypot field.

What we recommend is editing any existing forms and switching from they honeypot feature to the new “Anti-spam protection” feature in the form settings.

We could not auto upgrade existing forms, because the new anti-spam feature relies on/requires JavaScript. So while this will no issue for 99% of existing forms, it could cause issues with some sites which custom code/integrations and we didn’t want to risk breaking backwards compatibility.

As far as reCAPTCHA, it’s still the “golden standard” as far spam protection. So our hope and goal is that the new anti-spam feature is much more effective than the old Honeypot feature, Google’s reCAPTCHA will still be the most effective defense against spam.

Hope that helps ??

Hey @rodeboy – Great questions!

The new anti-spam protection in the 1.6.2 release is a similar approach to WP Zero Spam.

So if you are only using WPZS for spam protection on your forms, you should be able to remove that and enable the new anti-spam protection in your form settings and see no difference (our method is slightly more robust, so there could actually be improvements).

We don’t currently integrate with Akismet, but that is best approach to combating comment spam (we use it ourselves) so I’d recommend keeping that enabled.

Hope that helps. Let me know if you have any other questions ??

It is still supported and maintained. There have been no need to updates as no issues have been reported or discovered ??

We will bump the “tested to” soon though, good catch.

Thanks!

Also, this detection/notice can be disabled entirely if needed.

WP Mail SMTP > Settings > Misc > “Hide Email Delivery Errors” <— check that and save ??