Delicious Brains

Hi again,

Thanks for your updates along the way.

I hope disabling current plugin, and setting a new one, doesn’t break anything in the email configuration.

This is perfectly safe, the configuration format in the DB has not changed.

-et

Hi Zeigel,

Many thanks for reporting this issue. From an initial look, this seems to be an issue with PHP 8.2 rather than a conflict with another plugin.

Side note: We place all external libraries in our own namespace to avoid conflicts with other plugins.

The root cause of this seems to be that In PHP 8.2, the default return value of DateTime::getLastErrors() changed. Before 8.2, it always returns an array even when there are no warnings or errors. In 8.2, it will return boolean false in this case. That’s what breaking Carbon’s constructor under PHP 8.2.

The latest release of WP SES (1.6.3) actually downgraded from Carbon V2 back to 1.x. The reason for this is that Carbon V2 is not compatible with PHP 7 unless there are polyfills for the new string functions that were introduced in PHP 8. WordPress has these polyfills in place from 5.9 and later, but that PHP7 incompatibility meant that Carbon made WP SES stop working on a large set of sites with older versions of PHP and WordPress.

Since that was the only real upgrade in v1.6.3, my best advice here is to downgrade to WP SES 1.6.2. It uses Carbon V2 which should work better on your site. If you give that a try, we will appreciate it if you report back.

Very sorry for the inconvenience and thanks again for your detailed reporting!

-et

Hi,

Can you tell us which storage provider you are using and if you are using a CDN for delivery, which one you are using? Did you see any error messages in the debug log that could provide more details?

The settings notice for delivery generally works like this:

1. Upload a file to the storage provider and set it to public access (default) and if that succeeds, try to access that file via the configured delivery provider.
2. Upload a file to the storage provider and set it to private access and if that succeeds, try to access that file via the configured delivery provider.

Sounds like the tests detected a problem on step 1 above. Would be great if you also can copy the exact message and share it here.

-et

Hey @yuehlia,

That error you’re seeing means another plugin is also trying to catch new emails to be sent and handle them, and due to the order of loading plugins has already created the wp_mail function before WP Offload SES can.

Please check your other plugins to see if any might be trying to send emails and see if you can either deactivate that plugin if not needed, or turn off the email sending feature.

-IJ

WP Offload Media uses the Amazon S3 API via HTTPS, using the server’s PHP libraries to do so. In particular cURL with OpenSSL is usually what is used to make those API calls.

As long as your server is using OpenSSL version 1.0.1 or later, released in March 2012, TLS 1.2 is supported.

You can check what version of OpenSSL WP Offload Media will likely use by looking at the Diagnostic Info in its Support tab.

For the vast majority of sites, it is very unlikely that it is WP Offload Media’s Amazon S3 API usage that is causing this notice from Amazon S3 regarding enforcing a minimum of TLS 1.2.

The most likely cause of these notices is using raw bucket URLs for delivery.

If you are not using a CDN such as CloudFront or Cloudflare for delivering your media, then if a very old browser that does not support TLS 1.2, or a search engine crawler bot or any other kind of bot access the site, their access of those bucket URLs are considered as S3 API requests using a soon to be unsupported version of TLS.

The best way to fix this is by using a CDN such as CloudFront or Cloudflare for delivery.

-IJ

@kwebdesign when you dismiss that notice about the unverified email address, does it return straight away, or after another email using that address is sent?

@tedstur that’s a very different error notice to the one being discussed in this thread. Please create a new support topic with details of the problem you’re seeing, including any debug.log entries that include “WP Offload SES #” at the beginning, and diagnostic info.

-IJ

Thanks for the kind words @ogdennews, much appreciated.

It was your detailed support request that helped us determine what the issue was.

In WP Offload Media 3.2.0 we fixed a bug by using a filter that had a parameter needed for the fix added in WP 5.5. We didn’t realize at the time that the filter had been changed in WP 5.5.

As a result, we’ve updated the required version of WP to v5.5+ for WP Offload Media Lite 3.2.0+. This means anyone else using a version of WP earlier than v5.5 will not run into this issue.

Thanks for your help.

-IJ

Hi?@janwoostendorp!

We just released version 1.6.2 with updated instructions for getting started. Again, thanks for pointing this out to us.

-et

@ogdennews don’t suppose you’re using a version of WordPress earlier than v5.5?

-IJ

@i2dau thanks for the info.

Looks like the Uncode theme has some compatibility code for WP Offload Media that reaches inside the plugin and tries to use an old function that no longer exists.

Please ask the Uncode theme authors to use the global as3cf_get_attachment_url() function instead.

-IJ

With SVG Support plugin active, and WP Offload Media Lite set to offload media, does a *newly added* SVG file get offloaded?

If not, are you using WP Offload Media Lite 3.2? (a bug with offloading SVGs was fixed in 3.2)

Anything written to debug.log when adding a new SVG file to the Media Library?

https://deliciousbrains.com/why-use-wp-debug-log-wordpress-development/

-IJ

Please ensure debug.log is being used:

https://deliciousbrains.com/why-use-wp-debug-log-wordpress-development/

Then hit the “Check again” link on Delivery Settings notice.

Hopefully something will be written to the debug.log that will help debug the problem.

-IJ

Fixed in v1.6.1

-IJ

If you’re sending a large number of emails per day, and previously had the log retention set to a higher level such as 2 years, then it could take quite a while for WP Offload SES to work its way through that backlog of items to remove.

It may also be a case that it’s unable to remove anything because it is hitting a problem.

If you’re not seeing anything being removed, please ensure you have debug logging turned on and look for errors that might indicate problems with removing items from the log.

-IJ

Hey @pineros,

Unfortunately this little bug crept into v1.6.0.

It does not affect email sending, it’s just an annoying incorrect message.

We’ll be releasing a bug fix soon.

-IJ