'Slow query' reported by Query Monitor about site-reviews HOT 18 CLOSED

Also, register_activation_hook does not fire when a plugin is updated but only when it's first activated. I think I will leave this for now but can always revisit in the future.

from site-reviews.

Yeah, that's as close to official as can be, given that Jacoby's doing it

from site-reviews.

I'm not sure why it's slow, I'm getting micro-seconds on a local install for this query.

What is your mySQL version and what database engine do your tables use, MyISAM or InnoDB?

from site-reviews.

See also:

https://wordpress.org/support/topic/limit-reviews/#post-13578282

from site-reviews.

Site Reviews checks for the custom database tables and table constraints on every page load, these checks should only take a few micro seconds to perform. I may change this to an option in the database that stores the tables status. My concern however, is when someone manually deletes the tables thinking they are cleaning the database, and then the website breaks.

from site-reviews.

@colinhowells I just noticed you are using a multisite.

Please make sure you perform some tests locally as there has been a report of an issue with Site Reviews v5 on a multisite (particularly when the plugin is network activated).

I have been unable to replicate this issue myself, but I am working on an update to provide better multisite compatibility.

from site-reviews.

Let's see ... MySQL 5.7, InnoDB. This is multisite – network activation or just activating on a single site has the same effect, no problems other than this reported slowness (which obviously isn't even noticeable to the visitor, only to QM).

It might just be due to my local dev setup, WP in Docker generally can get weird (some local-dev apps wrapping Docker I find unusable).

I was holding off upgrading to v5 in production just in case this was going to get addressed; but if you're not concerned, I'm not concerned – I was just curious if i'd run into some edge case that'd be useful for you to know about. When I do upgrade in production I'll let you know how that went.

Here's some screenshots – note I have a custom DB prefix:

from site-reviews.

Also – I'd think storing the DB status in an autoloaded option'd be fine: firstly, if you're deleting DB tables you're already asking for trouble without first checking what is what, and secondly the plugin is kinda 'for WP devs'; you're already assuming people are going to get more involved than checking options in a UI.

from site-reviews.

I recently had a problem with Woocommerce. After deleting the plugin I removed the tables it creates, including the actionscheduler tables.

When I installed Woocommerce again a few weeks later, it brought the site down because those tables no longer existed and they don't check for it on activation.

I can probably also just perform the check on plugin activation however.

from site-reviews.

Ah, yeah, I can see why you built in that check, that makes perfect sense – don't feel compelled to change what you're doing just for me; you've dealt with a lot more of these things than I have.

from site-reviews.

This will be optimised in v5.2. Instead of verifying the tables on each page load, it will simply check for the existence of an option key instead.

from site-reviews.

Just for kicks I looked around to see how most people deal with this, and ran across using get_var() to check; this is also what maybe_create_table() does – I'm not sure how this would be more performant than what you're already doing, though

from site-reviews.

I'm using get_col() instead of get_var() as the "table exists" check runs for each of the four custom tables and this way I can just do a single query for the existence of each of the four tables instead of running a query for each one.

It should take less than a millisecond to run.

from site-reviews.

Right, hence me saying 'not sure how this would be more performant than what you're already doing' – like you say the option check'll be much quicker, if a little more dangerous. Thanks for having a little conversation about it, I only rarely deal with custom tables so I was curious what the common practice was

from site-reviews.

I'm learning about all of this too, particularly how custom tables work with Multisite.

What I've opted to do is perform the tableExists check on plugin activation, and a check for the option key on page load (which will run the table checks again if it does not exist). I think this is fairly safe to do and more performant, as if they deleted the tables but not the option, a simple plugin deactivation (or manually deleting the plugin and reinstalling) and then activating it again will fix everything.

from site-reviews.

If you're interested how Site Reviews creates the custom tables and works with Multisite installs, see:

https://github.com/pryley/site-reviews/blob/develop/plugin/Install.php
https://github.com/pryley/site-reviews/blob/develop/plugin/Database/SqlSchema.php

from site-reviews.

I'll have a look, thanks! I don't know if you're hip to the Berlin ORMish project, I just remembered it now

from site-reviews.

Looks interesting, thanks.

I have some fairly strict coding guidelines that I follow, like maximum class and method size/complexity, etc., but I'll take a look through it at some point and maybe combine some the concepts into my database implementation if needed.

from site-reviews.