webaware

Those are your best options, I believe. You probably don’t have to have Cloudflare proxy your main domain, but you will need to add it to their DNS so that you can manage the subdomain. If that’s a problem, then look at how you can purchase and load a TLS certificate for GCS. I imagine they have some doco on that.

cheers,
Ross

It won’t have any impact on the plugin, but you might still get mixed content warnings. Please let me know what happens, I’m unsure what the current browsers do with this now.

cheers,
Ross

G’day painlessseo,

No changes are made to the system, it only makes changes to content on-the-fly. Deactivating the plugin stops it having any effect.

For your videos, did you mean that they do use HTTPS, or don’t use HTTPS? If they can’t be loaded over HTTPS, they will likely not work due to mixed content.

cheers,
Ross

Use the recommended setting. It’s based on the headers sent by your proxy. WordPress apparently can already detect when the page is requested over HTTPS, so no need to change from that.

G’day,

I know nothing about QUIC.cloud, but the detected recommended setting is usually the best. It indicates that your website is already aware of the state of HTTPS in connections.

cheers,
Ross

Disable Emails can only disable all emails. It is not selective, it blocks emails from being sent.

You can’t have to email handling plugins run at the same time. Disable Emails is replacing the wp_mail() function, so ElasticEmailSender can’t. Only activate one of these plugins at a time.

G’day Rob,

Thanks, I can see it now and have determined why I’m not seeing this in testing. I’ll get that sorted next week sometime. Thanks for your help with this.

cheers,
Ross

G’day Rob,

I test on PHP 8.1 and 8.2 with no deprecation warnings. Can you provide samples of the warnings please? It’s likely that something else is modifying a value in a filter hook that is triggering the warnings.

cheers,
Ross

G’day @psylee,

The only way I can replicate this error is if I deliberately remove the Client Side Encryption key. Have you correctly configured your Eway details with all three of API key, API password, Client Side Encryption key? All three are required for the integration method used by this plugin.

Please read the FAQ topic Do I need to set the Client-Side Encryption Key?

Eway have an article on setting up your Client Side Encryption key.

cheers,
Ross

@cklosows duh! Of course, I forgot that (it was a while ago!) I can confirm that not doing the dumb thing stops breaking it in the dumb way, thanks for spotting that. Will remove the fix, and the bork, from the live site now. I guess I’m not doing that on the other site that isn’t breaking (and will remove the fix from there too now).

cheers,
Ross

@specialk when I tested, it only happened on the checkout. It happens because the checkout rendering function calls checkout_has_blocks() to see whether it should continue or not. Not defined unless EDD core blocks have been initialised. It used to check whether that function exists before calling it, but no longer checks since v3.2.0

@cklosows will do.

Maybe worth mentioning, my site that requires this fix is a multisite non-primary site running the Classic Editor plugin set to Classic editor by default and allowing switch editors — I edit posts in Classic editor, pages in Block editor.

I got this too, but only with one custom theme that uses Timber/Twig. I tested on a couple of other sites in Twentytwelve, Themedd, and another custom Timber theme, without error. I resolved on my breaking site with this snippet:

use function EDD\Blocks\init_core_blocks as edd_init_core_blocks;

/**
 * ensure that EDD core blocks are loaded for checkout page, since EDD 3.2.0
 */
add_action('wp', function() : void {
	if (edd_is_checkout() && !defined('EDD_BLOCKS_DIR')) {
		edd_init_core_blocks();
	}
});

Yes. I run my local systems on PHP 8.1, and this plugin only uses WordPress API calls to access data so it is compatible with MySQL 8.