Sorry I didn’t see your messages earlier. I just saw an update, and after checking the changelog, I came back here and found your messages. So, by just updating to the latest version without doing anything else, it should resolve the issue, right?
Thanks for responding. Let me clarify the issue with more technical detail.
The warning: The browser console shows [Violation] Forced reflow while executing JavaScript or [Violation] 'requestAnimationFrame' handler took Xms warnings — these appear when style recalculations block the main thread for too long.
The specific CSS causing it:
.tablepress>.row-hover>tr:has(+.child:hover)>*
Why it’s problematic in certain contexts:
The CSS is syntactically valid, but the combination of :has() with :hover creates a performance-sensitive selector. Here’s why:
:has() is a “live” relational selector — the browser must continuously re-evaluate whether the condition (+ .child:hover) is true
:hover state changes frequently, especially when the mouse moves near animated elements
When an infinite/continuously-animating slider is on the same page, DOM mutations happen constantly
Each DOM change + hover event forces the browser to recalculate styles for all matching .tablepress>.row-hover>tr elements
This creates a cascade of style recalculations that can exceed the browser’s 50ms threshold, triggering violations and visible stuttering.
Why most users don’t see this:
The issue only manifests when both conditions are present:
TablePress with row-hover feature active
An infinite slider or heavily animated content on the same page
Without both, the recalculation cost stays within acceptable limits.
Browser: Chrome 131 (Chromium-based browsers are most vocal about these violations in the console)
Possible solutions:
Use content-visibility or contain properties to limit recalculation scope
Consider a JS-based hover approach with debouncing for the child-row highlighting specifically
Add a class to disable the :has() hover effect on pages with known animation conflicts
Happy to provide a screen recording if that helps demonstrate the stuttering.
Why starting another topic? The issue is still the same with WP Grid Builder, and it wasn’t resolved yet, did you saw my previous message? As I didn’t receive any news about that.
We have more than 500 users and it will grow even more
It’s not happening and when a new users is added, it’s not found after a refresh on a blog post page, due to caching or something like that, I don’t know? I can provide login detail if needed and show you a video instruction on how to reproduce this use case.
Thanks for the quick reply. I talked with Loïc from WP Grid Builder and here’s what he answered: “If you intend to utilize object caching, it is advisable not to concurrently utilize the caching add-on from WP Grid Builder. This concurrent use will compromise the caching mechanism of the add-on. It is recommended to employ only one caching solution, either object caching or our plugin, but not both simultaneously.”
So I deactivated WP Grid Builder cache and activated SQLite Object Cache with APCu enabled, but my facets aren’t working with it.
Can I send you an email with login details so you can take a look as to why my WPGridBuilder facets aren’t working when SQLite Object Cache is enabled?
I’m looking forward to using your solution on all my websites, but unfortunately I’m using WPGridBuilder on nearly all of them, so a fix needs to be found.
I think it’s not doing that unfortunately, I’m using Cloudflare Pro plan and LiteSpeed Cache plugin and Perfmatters, I don’t know if that can help you understand.
It’s just one of the account with user role “client” that I created, that create some “author” account, but after the creation, and even after refreshing the blog post, the user is not showing, it’s like it’s cached somehow or the index wasn’t rebuild, I don’t know exactly which one but only doing a manual re-index solve the issue for me.
We have like around 30 accounts with user role “client” and around 110 accounts with user role “author” which they are using to modify blog post author.
Yeah you are right I can see the post with /?s=total&post_type=franchise, good catch.
So I have the setting “Partial words if no hits for whole words”, I’ve switched to “Partial words” and now it’s working great, thanks for the fast support Mikko!
You said “(or if you force the search to only return franchise posts)”, but no, I don’t have the “franchise” entry “TotalEnergies” whatever I do.
I need to type the full name but that’s normal. I want to find this CPT entry with partial string from complete string, so if I type “Total” I want to find the franchise post name “TotalEnergies”.
People will type “Total” and expect to find “TotalEnergies”, it’s quite common for this company to just type “Total”.
So it’s not a curious case, and yeah I have the same result when I try to search “total” in the Relevanssi admin search.
