Barry

If you provide the IP of your VPS we can take a look.

You’re welcome and same to you! If there is anything else I can do to help, please let me know ??

This particular error seems to come from the WP Remote plugin.

> There does not appear to be anything we can do on our end.

It appears your Cloudflare configuration is returning a 403 Forbidden response and captcha challenge when the Jetpack CDN requests the image from your server. Please be sure that you have added all Jetpack IP ranges to your Cloudflare allow list. You can find them here. Specifically, in this case it looks like 195.234.108.0/22 is being blocked. Hope this helps.

It looks like you (or your hosting provider) is blocking some Photon IPs which is causing some requests to fail and return a 400 error as a result.

As an example, I can see from our side that 195.234.109.64 is blocked but 195.234.109.4 is not.

If you have additional questions or need more info it’s probably best to contact our support via https://jetpack.com/contact-support/ to sort out the problem.

Hi @eherman24 ! There is a fatal error in >= PHP 7.1 that is pretty simple to fix:

Cannot unset $this in wp-content/plugins/wp2yt-uploader/classes/class.youtube-for-wordpress.php on line 32

This is because of the “Do not call destructors on incomplete objects” change mentioned here

I think just removing the entire __destruct function should be fine in this case. Do you think you could commit a fix and release an update? Otherwise I would be happy to do it if you grant me commit access.

For anyone experiencing these issues – if you have SSH access to the server where your site is hosted could you ping me on www.remarpro.com Slack to troubleshoot? If not, could you ask your hosting company to contact me directly? Email: barry [at] automattic.com or @barry on Slack.

Sorry about that. Should be fixed now. Please try the latest version (same URL as before).

Hi,

I added support for MYSQL_CLIENT_FLAGS to HyperDB. Can you please try the development version here and let me know if it works for you?

Thanks!

How about this?


if ( preg_match('/^' . $wpdb->base_prefix . '\d+_/i', $wpdb->table ) )
return 'blog';


Any idea why we’d be getting select queries to our master DB?

There are a few reasons this could happen.

1. Whe most obvious one is that the read priority for the master is set to something > 0. What do you have the read priority set to in your configuration?

2. HyperDB sends reads to the master for a given table on a single pageload if there was an update to that table on the same pageload. So for example, if you UPDATE wp_options and then SELECT from wp_options 10 times on the same page, those 10 SELECTs would go to the master, even if the read priority is set to 0. This is because it’s very likely the latest changes haven’t been replicated if you are using asynchronous (the default) replication in MariaDB. If you’re interested how this part of the code works, look for where $this->srtm is set to true in the HyperDB source code.

3. Your code is explicitly setting $this->srtm to true either by calling send_reads_to_masters() or some other way.

Hope this is helpful, let us know what you find after reviewing your configuration and code.

Hey @scollonp – great to hear about how you are using HyperDB and glad that it’s working for you. Your proposal of not installing the plugin to wp-content/plugins/ and just copying it to wp-content/ with your bash script seems reasonable. Since it’s not a normal plugin it shouldn’t ever really be in wp-content/plugins/. That being said, I think the warning message you originally asked about is only shown once when visiting the plugins page for the first time after HyperDB was moved out. Subsequent visits to the page shouldn’t show this message. If you don’t mind the error appearing once, then I think your current process is fine and you can safely ignore the message. Hope this helps! If you have any other questions, please let us know.

HyperDB works will with the latest version of WordPress. I have updated the plugin page to reflect that.

In general, the error message is probably ok, although it sounds like HyperDB may not have been successfully installed previously.

HyperDB isn’t a normal WordPress plugin – it shouldn’t be installed in your plugins directory. It is a special type of plugin called a “drop-in”. From the HyperDB readme –

> 3. Deploy db.php to the /wp-content/ directory. Simply placing this file activates it. To deactivate it, move it from that location or move the config file.

Do you receive this error when moving <code<>db.php out of /wp-content/ or somewhere else?

• This reply was modified 7 years, 4 months ago by Barry.

Yep! Should work fine.