tmwnn

@gvectorssupportmember, I understand these words syntacticly: “This is something specific on our website.” But I do not understand what those words mean in this context.

I have three questions:

1. Do you understand that the EasyPrivacy list, which is a very popular blocklist used by many ad-blocking browser extensions has specifically blocked any URI that contains the segment /wpdcookiejs/?

2. Do you understand that you can’t just install uBlock and test that WPDiscuz is working still because if your browser has already cached the blocked .js file(s) from that directory, it will still work for you even though those resources are in fact blocked?

3. Do you have a plan for either convincing EasyList to take that component off their blocklist, or either renaming or replacing the functionality that WPDiscuz needs from that third party code so that it will work reliably for people who are using ad blockers that make use of the EasyPrivacy list?

You can see that /wpdcookiejs/* has been added to the EasyPrivacy list here:

https://easylist.to/easylist/easyprivacy.txt

Any ad blocking extension that uses that list is going to break WPDiscuz.

Yup, same here. 5.2.2 looks good on my box. I am running the plugin’s (not WP’s) ajax code.

Marking this issue resolved.

@suprim No, I’ve just downgraded indefinitely to version 5.1.7. I hope that at some point the developers will address it and update the plugin.

@jb510 that’s no hijacking, that’s adding valuable information. Thank you.

I also saw on my server that 5.2.1 was hitting the DB hard and that most of the increase in CPU usage was tied to I/O, but I didn’t have time to look up the query.

The release notes for version 5.2.X of wpDiscuz specifically mention:

• Boosted: Revolutionary changes in core made for rocket speed.
• Boosted: Database queries with custom AJAX processor (disabled by default)

I’m assuming that what we are seeing is some unintended side effect of the second one.

Edit: …though I also still got high CPU usage when I switched the plugin setting to wordpress native ajax, so maybe it’s the first one?

2. I do not have the option “Display only parent comments and view replies” enabled.

You do have it. Please navigate to Comments >Settings > Comments List Tab and find there.

I did not write that I don’t have it. I wrote that I do not have it ENABLED. In other words, it is DISABLED. Not sure how to communicate that better.

The host has 8 GB of ram and 4 CPU cores.

6. Right now (on version 5.1.7), I have the wpDiscuz set to use its own ajax. As I wrote in my initial post, just a few inches above these words, when I tried version 5.2.1, I tried it both ways and saw the same high CPU usage either way. I cleared all caches between settings changes.

To be as clear as I can: version 5.1.7 does not have any problem. Version 5.2.1 uses a lot of the CPU resources on the server.

Sorry about the broken link: Here it is again.

1. I do not understand the words of your number 1. I see no preference anywhere, either in native wordpress settings or in WPdiscuz that has anything to do with “how many comment threads are enabled to be loaded at once”.

The setting that you have pictured beneath those words, which to me appears to have to do with pagination, is identical on my server to your screenshot. In other words, the option is unchecked and the default value of 50 is in the box you have outlined in red.

If you are actually asking about the threading levels depth (the setting above the one you have outlined in red in your screenshot), we have that set at 7.

2. I do not have the option “Display only parent comments and view replies” enabled.

3. We have a large range of numbers of comments so it would be hard to know the average with any accuracy. I would say that the range is from about a dozen on the low end up to about 500 on the high end. This site has a very active community of commenters.

4. I don’t know what specifically you are asking about the “hosting plan,” but this site is running on a custom configured VPN with plenty of resources available. The stack is nginx with php 7.2. All software is quite up to date.

5. We have your premium wpDiscuz – Media Uploader addon installed.

I have downgraded back to version 5.1.7 of wpDiscuz, so I’m not sure what use you would make of a link to the site, but it’s here.

Hi @gvectorssupport,

As mentioned in my original post, I also can’t reproduce it. But it consistently happens to some people on our site.

Since the people who are affected can post top-level comments, but not replies and since the problem is related specifically to WPBruiser spam protection and gives either an “Invalid Token” or “Browser Info Invalid” error, can you tell me what the differences are between the main comment form and the reply comment form that could be related to those errors? What token is WPBruiser looking for? How is that token injected into the POST request when a comment or reply comment is sent?

I am a WP plugin developer. Tell me where to look in your plugin and I will audit it and see if I can find anything useful to add.

I see that you just posted a test comment on the site. For user’s convenience, I have turned off WPBruiser comment protection temporarily so you will not have seen whatever the problem is. I will turn it back on and clear caches. Please wait a few minutes and try again.

EDIT: Ok, WPBruiser comment protection is turned back on.

Testing, 1,2,3…

@gvectorssupport are you around here somewhere?

marking resolved.

it’s working again.

seems like maybe it would be worthwhile to do some extremely intensive testing before rolling out changes to your production server (if that’s what happened) given how many people’s sites are dependent on them as a SaaS.

Sorry, when I wrote “widget” I didn’t really mean “widget”. We are using the plugin for comment like/dislike and it is beneath the comments where it is not working.

You can test yourself on any post at https://theburningplatform.com

Marking as resolved.

Yup – that one did it.

Thanks for your help.