Paid Addons Support Forum Only
Please note, that here we only support Paid Addons issues and questions.
gVectors Support staff works from 6am to 6pm (GMT+0)
All questions related to wpForo and wpDiscuz free plugins should be asked in the corresponding plugin support forum:
Admin section timeout?
We've recently moved our site to a new hosting provider, and since the migration the Wordpress admin section takes a very long time to navigate between pages. The issue is resolved by disabling the wpdiscuz plugin. There is no issue client-side - the nested comments and voting system are fine.
I wonder if it might be a timeout because the delay between page loads is very consistent - about 30 seconds between each page load - so I'm wondering if there's something in the code that makes a network call somewhere and that call needs to timeout before we get a response. Is that a possibility?
I appreciate a slowdown navigating between WP admin pages doesn't sound like an issue with wpdiscuz, but given disabling the plugin resolves the issue, I hoped someone here might able to help. There's no problem client-side - the plugin works as expected, and only WP admin is affected.
Any suggestions very welcome.
Please let me know, have you migrated all tables? Have you repaired and optimized database tables after migration? If not, please do that.
Please navigate to Dashboard > Comments > Cache Tab and click on these buttons.
- [Purge expired caches]
- [Purge all caches]
- [Purge statistics caches]
Then deactivate wpDiscuz and activate it back.
Hey Tom, thanks for your reply.
Yeah, we did a lift-and-shift of each database on the server - mysqldump to SQL then an import. There are another couple of WP instances on the MySQL server, and they all came across. We're using InnoDB and as far as I can tell, repair only works on MyISAM. I did an optimize a while ago on the old hosting, but I think the act of dumping out the old database and then importing basically does the same thing as optimize anyway (it just recreates the table on disk, I believe). I'll certainly give it another go though.
We already tried purging all the caches in wpDiscuz. We're behind Cloudflare, and I've been careful to purge its cache too.
I'll post back if I find out what the error is. It's a fairly serious problem - 30 seconds between each page refresh in admin is a bit of a hassle, especially when we post three or four stories a day: login to admin, 30 seconds, navigate to new post, 30 seconds, each preview before posting, 30 seconds, adding media, 30 seconds, publish, 30 seconds - it adds up to a fairly unpleasant experience. It's very frustrating too, since as soon as the 30 seconds are up, it loads really quickly.
I'm not too good on how plugins integrate with WP. Can you think of any reason why it'd only be a problem in admin and not client-side? Are there any APIs that plugins hook into admin-side?
Thanks again for getting back to me.
Possible progress figuring out what's going on - would be very grateful for any input.
I turned on debugging in Wordpress, and I'm seeing a lot of these in the log that it wrote:
[25-Jan-2020 19:16:57 UTC] PHP Notice: Trying to access array offset on value of type null in /var/www/html/wp-content/plugins/wpdiscuz/class.WpdiscuzCore.php on line 942
[25-Jan-2020 19:16:57 UTC] PHP Notice: Trying to access array offset on value of type null in /var/www/html/wp-content/plugins/wpdiscuz/class.WpdiscuzCore.php on line 975
I'm also seeing these, though it's obviously a different plugin (but perhaps it's causing wpDiscuz the problem?):
[25-Jan-2020 19:17:05 UTC] PHP Notice: Trying to access array offset on value of type null in /var/www/html/wp-content/plugins/js_composer/include/autoload/vc-shortcode-autoloader.php on line 64
$this->commentsArgs['caller'] === 'wpdiscuz-'
So I think that means the 'caller' key is missing from commentsArgs. Anyone have any idea why that might be?
Thanks again for any input.
Thank you for the information. We're currently checking this issue.
I think this issue is related to PHP version. Please use PHP from 7.0 to 7.2. wpDiscuz will be compatible with 7.4 very soon with the 7.0.0 stable version. Currently, the wpDiscuz 7 is released but it's in beta stage, you can try it too: https://beta.wpdiscuz.com/
For further support we'll need admin login details. Please send it to info[at]gvectors.com email address.
Many thanks for looking into that for me.
You're absolutely right that it's PHP 7.4.1. It's relatively easy for me to give an earlier version a try, so I'll have a go with 7.2 when I can, and let you know how I get on.
Thanks ever so much for your help! 🙂
I think I've found the cause of the issue.
When you navigate between screens in the admin, it appears this query is executed:
SELECT wp_comments.* FROM wp_comments JOIN wp_posts ON ( wp_comments.comment_post_ID = wp_posts.ID )
This gets back every comment in the database, which for us is just over 760k rows. What I think is happening with the timeout is that the query exceeds PHP's query execution time of 30 seconds, and then the page comes back without the data.
Can you let me know whether I've correctly understood the plugin's behaviour in this way, in that it executes that query on each admin page load? I'm guessing that we're not the first user of the plugin to have a high volume of comments, so is this something you've seen before? If so, do you have any recommendations for dealing with it? We don't want to delete all the comments, though I guess emptying the table would probably solve the issue until they built up again.
Also, assuming I have correctly understood what's going on, is this something that's resolved in the beta? We love the plugin and want to keep using it, so if it's resolved in the next version we'd be happy to move onto that.
Ok, let us check this...
In the meantime please navigate to cPanle > phpMyAdmin database manager, check wp_posts and wp_comemnts table structures and make sure all indexes of these tables exist. You could lose those accidentally:
Ok, we just checked. This is not wpDiscuz SQL, wpDiscuz only initiated and do some SQLs in wpDiscuz Settings pages, nowhere else. wpDiscuz doesn't even call any function which could initiate this SQL. You should find the real initiator of this SQL. I recommend install Query Monitor plugin and find the problem maker.
Thanks again for your help looking into it.
I don't have PHPMyAdmin installed, but I can use the MySQL tools to recreate the indexes on the table.
Ah, okay. I wonder what's causing it then. Perhaps some combination of wpdiscuz and some other plugin we use, or the theme we use. While I appreciate what you're saying that it's not wpdiscuz that's making those calls, when we disabled it the issue definitely stopped. We tried disabling it a few times to be sure.
Regardless, I'm pleased to report that it looks like we have a solution. We tried the beta version of the plugin this morning, and the long waits in admin have gone away. I also don't see that query being executed while we browse the admin pages anymore.
Thanks so much for all your help - we really appreciate the time you and your team put into assisting us, and we're really pleased to have a solution that includes the plugin. We'll see how it goes for a couple of days.
I appreciate this isn't the issue we've been discussing, but when we click any of the options in the attached image, we get a timeout. I guess it's because whatever query is executed in the background takes too long because we have a large number of comments in the database.
Are you able to tell me the queries I need to run in MySQL to do what these messages ask me to? I had a look at the FAQ for the beta, but I don't see anything that might help.
These processes are being done through AJAX requests partially. So they should not overload your server.
Oh, well it's definitely giving us a timeout when we click any of them.
I don't think they're overloading the server. I just think they're taking longer than the max time the server will allow. Definitely confusing if they're run asynchronously though.
Are you able to help me with the queries? It's no problem at all to run them manually.