Biranit

Gosh I;m an idiot or blind… please ignore this thread (I’d gladly delete it but can’t) – I found the option :0

Thank you @donncha ??

Hi @donncha , Good to see you here ??

I ended up using MobileESP – which is really great and very accurate – in this manner (in my theme’s functions.php):

if (function_exists('add_cacheaction')) {
	function rgb_wp_cache_check_mobile($cache_key) {
		include_once('/path/to/mobile-esp.php');
		$ua = new uagent_info;
		return ( $ua->DetectMobileQuick() ) ? 'mobile' : 'normal';
	}
	add_cacheaction('wp_cache_check_mobile', 'rgb_wp_cache_check_mobile');
}

It works very well and solved all my issues. What do you think? Is this a viable workaround?

Thank you ??

Thank you for fixing this, @methnen!

Hi @methnen I apologize for not responding sooner! I just emailed you back ??

Thank you!

Yes, certainly!

I’ll email you – thank you ??

Thank you ??

@westi I can confirm this fixes the error notice, and everything else seems to work fine. Thank you ??

@inhouse oembed works the same in the admin and the frontend, so it should solve your issue in both places. I am not familiar with ACF, though: perhaps they use a different oembed functionality than the built-in WordPress one. I recommend you contact them on their support forum.

Good luck ??

I can confirm this is the case with every Facebook oEmbed link – the problem is the oEmbed fetch from Facebook takes longer than the default timeout that WordPress has set.

To fix this (until WordPress does at least), put this code in your functions.php:

function my_increase_oembed_timeout($args) {
	$args["timeout"] = 30;
	return $args;
}
add_filter( 'oembed_remote_get_args', 'my_increase_oembed_timeout');

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

I actually tried this, putting it in the theme’s functions.php, but it didn’t work. I suspect because ‘plugins_loaded’ was already parsed by wordpress – so I probably need to put this inside a function that is called on ‘init’.

I don’t mind leaving this, but as I said – you need to look into why it constantly returns a 403 forbidden message…

OK, please ignore this post. The problem had nothing to do with Wordfence. (No way to delete this thread). Apologies.

Thanks, Michael.

I fixed this by editing the plugin js file – for now. I assume this will be fixed permanently in the next release, so when I upgrade next it will overwrite my fix, which is fine ??

Keep up the great work.

Cheers,

Bira

Hi Michael,

I actually no longer think CPT UI is the culprit – but rather one of the custom taxonomies registered via CPT UI (which is why disabling the plugin “solved” the issue). Upgrading to WordPress 4.2 seems to have caused the issue with that taxonomy.

It is a bit of a wonder why that taxonomy had any effect on post type pages at all, but that’s another story altogether and most certainly not for you to worry about ??

Thank you for responding and apologies for the alarm.

Best,

Bira

The bigger issue is that the author of this plugin is using the same key in the email as in the database – which is slightly unsafe, and different to how WordPress does it (the key sent out is hashed). It would be far better if in the next update, the author of this plugin used the native (and more secure) WordPress function. In fact, many of the functions in this plugin should have remained native.