Daniel Iser
Forum Replies Created
-
@peter8nss – We are already moving to disable that as a generic feature, enabling it only where its safe for now (rest API).
That said we need to know where the conflict is coming from, it has to be conflicting with another plugin/theme/block that is calling those queries, and duplicating that issue on our test sites will go a long way to working out how to resolve it properly. Otherwise will just be guessing as to why and solutions.
That said all of our code that accepts both WP_Query or WP_Term_Query, do type checking, and our rules checks also do contextual checking, meaning it knows if its checking Term queries or posts, and subsequently applies the correct logic with that ID.
Agree its not ideal, but having to duplicate all our functions for 1-2 changes under the hood was not ideal, especially as we already had context based methodology there from v2.0.
IE rules know if they are checking the main query, rest query, main post loop, secondary post loops, term loops etc.@robin-labadie, @darrylr – Since this feature was really introduced as part of the REST API protections, I may just back it off to only run there until we learn more about how these queries are being used in the wild.
My thinking is that we are checking term queries too early in the process, but not sure why that is causing issues other than just not protecting those early queries like posts query handling does.
It indicates there must be some recursive nature to things were not accounting for. Then our code runs recursively as well making things compound.If anyone can clone to staging and narrow to a specific plugin/theme/block/etc it would be helpful, otherwise look for another update later today to disable that for now.
Thanks all for the rapid reports and confirmations, goes a long way to minimizing the impacts for everyone else. We all appreciate it greatly.
@reteinformatica, @momo-fr – Sounds like your system upated to the previous release 1.18.3 unfortunately, not the 1.18.4 which has that file (now confirmed, thanks @buondioz).
@talaios, @hospvetsantamarinha, @profielgau, @alex_yx,@jonnyss,@buondioz, @morgan71 – Thank you all for the report, looking for someone to confirm 1.18.4 resolved that.
Fixed, sorry about that, SVN commit failed to add a new file for some reason using same commands I’ve used for years.
1.18.4 should resolve that..
Any error logs would be super helpful, looking into it ASAP, setting the stable back one version til I get logs.
Do you have any taxonomy queries on the front end? List of tags or categories?
We added query filtering for terms, but it seems on your site its triggering an infinite loop of some kind.
Can you test any changes for me on your site?
If so maybe try editing this file:
wp-content/plugins/content-control/classes/Controllers/Frontend/Restrictions/QueryTerms.php
Either comment out the filter on like 81, or try adding this before it:if ( ! is_rest() ) { return; }@nobo73 – Much appreciate the quick reports of errors, better to fix them right away when less people have had them 🙂
Glad to hear that resolved it.
Fix pushed already, you should see 2.2.1 available as soon as github actions finish.
That should have addressed all errors in this thread with type enforcement & checks.
That said can anyone tell me how your triggering this error? Is it on specific urls or something?
The only way this should occur typically is if the main query was for a taxonomy archive, which I didn’t know even existed.
I’m marking this resolved, if you see anything new lets start a new thread to keep it clear what errors remain unsolved.I wasn’t able to replicate it myself, but I’ve added some type checks there that should prevent that specific error/warning.
@nobo73 – Same, patched with type check there.
@nobo73, @robin-labadie – Confirmed, fix coming shortly.
@therus – Just a quick though as you didn’t mention it specifically.
When you tested, did you try a different theme by chance? Often theme issues are overlooked when “deactivating all plugins”.
That said I highly suggest you install the Health Check & Troubleshooting plugin, then use the “Troubleshooting” mode via the Plugins page on our plugin.
This will safely and temporarily deactivate all other plugins & enable a default theme (you must have 2023 or other WP default theme installed too).
This way none of your other visitors/users will be affected while you test.Also i have patched (not released) an issue that was causing the upgrade notice to be shown with no upgrades to process, but that doesn’t look like the issue here as your not even getting the page to load with those JS issues.
 load files in parts that are not used. wp-content/plugins/paid-memberships-pro/js/pmpro-admin.js is loaded in /wp-admin/plugins.php and in the header, slowing down the entire list of plugins
Just want to add, that is not at all how it works.
If your plugins page is loading slow, its likely due to WP scanning X number of plugin folders header files to get plugin details.
In fact the page is already completely loaded for you in the browser before the browser even knows to make a request for a JavaScript file.
Thus even though your initial point has some validity, your example is not indicative of their plugin causing a problem.
Further there are ample use cases for including a JS file on the plugins page, detecting deactivations of your plugin for example and asking if you would rather enable a “Safe Mode” instead of deactivating is one that comes to and many plugins of this nature offer.
All of that said performance of a plugin is important, but in general no ecommerce/membership plugin is “performant” by any measure, this is simply due to the enormously dynamic environment that can’t benefit from page or full query caching.
Your better off throwing more resources as hosting than squeezing out 1% more performance from a single plugin’s JS files or 1 extra query etc.
The reason is mainly because of diminishing returns, that 1% of 1% means nothing when you later install Plugin X & code snippet Y, or even update Z to existing plugins/themes/core, but permanently faster hosting doesn’t care about that.
Just my 2 cents.
@dimai – Thanks for the heads up, will try to get that patched soon for you.