Daniel Iser

@robin-labadie – Or anyone else, if you can test this really quick and confirm it resolves the issue It would be very helpful.

I’m trying to keep it as generic as possible, rather than a WooCommerce specific solution, I made it simply check if the current query is same as the last

Edit file: wp-content/plugins/content-control/inc/functions/restrictions.php

Around line 148 you should see this if ( $query instanceof \WP_Term_Query ) {

Copy the section below and add it after the foreach loop near the bottom of that section.

	if ( $query instanceof \WP_Term_Query ) {
		...
		foreach ( (array) $taxonomies_to_ignore as $taxonomy ) {
			if ( in_array( $taxonomy, $query_taxonomies, true ) ) {
				return true;
			}
		}

----- COPY BELOW HERE
		static $last_term_query = null;

		if ( $last_term_query && doing_filter( 'get_terms' ) &&
		(
			$query === $last_term_query ||
			wp_json_encode( $query->query_vars ) === wp_json_encode( $last_term_query->query_vars )
		)
		) {
			return true;
		}

		$last_term_query = $query;
------- COPY ABOVE HERE
	}

• This reply was modified 2 years, 2 months ago by Daniel Iser.

@tbob21 – Are you confirming this filter was still running outside the rest API in v2.2.2?

Its neccessary for properly handling restricted terms in the REST API, and I’m struggling to duplicate the errors on a test site.

I’m gonna try your suggestion for WooCommerce pages and gutenberg next to see if that triggers it.

Hate patching any more but feel I want to try and stop the bleed for anyone newly updating. I really need to nail down the cause though so I can properly address it and re-enable it for everything else.

Look for a patch shortly for 2.2.3. I’m probably not gonna comment that out, but rather run some more specific checks inside the query filter itself to only apply to taxonomy archives in the REST API.

If anyone is able to test that solution before I waste another version patch I’d love your assistance.

@dingdang – Sorry to hear your running into trouble.

Couple things from the top:

1. If you need boolean based user targeting, Pro offers “Custom” which expands to a full boolean editor, along with more user rules such as ecommerce based rules for purchase history or subscriptions etc.
   
   With that you can mix & match use of AND/OR, Groups & Negative rules, no limits.
   
   
2. “Who can see this content” is pretty specific already we thought, but heres a quick breakdown in order of how things are processed on the front end:
   
   a. The “Who” specifies which users the restriction applies to. We check this first, as if they are allowed, no reason to waste performance checking content matches.
   
   b. Content rules: or the “What”, specify what content the restriction is applied to, if its not applied to a specific content, you should expect nothing to happen from our plugin.
   
   c. Protection Method: or the “How” determines how the content will be protected if both the user check failed & content rules matched.
   
   
3. Rulesets are applied in priority sort order, or via a filter all at once.
   
   Default: Prioritized handling, works for 99% of use cases, simply put highest priority groups up top, lowest at the bottom. Once we find a restriction that matches we don’t check the others.
   
   For sites with membership levels etc, Gold first, Silver second etc. This ensures highest teir always wins out once matched.
   
   In your case this may or may not work because you really need to know whether they fit into either group or both.
   
   Collective: Runs all restrictions, still in order, but applies them all every time, no bailing early.
   
   This one currently is only enabled with a filter as it requires understanding the nuance issue your actually trying to solve and opting to do this sitewide, otherwise its extremely heavy for most users to enable by accident for sites with 10 levels where Default works great with no performance hits.
   
   Its in our troubleshooting doc here: https://contentcontrolplugin.com/docs/troubleshooting/basic-troubleshooting-guide/#h-my-restriction-isn-t-working-the-way-i-want
   

Let me know if I missed anything.

• This reply was modified 2 years, 2 months ago by Daniel Iser. Reason: fix aweful formatting of lists

Looking further I don’t think this was explicitly patched, though I don’t think it should still be occuring in v2.2.2 as we disabled those entirely outside the API.

In any case I’ll put another patch out explicitly checking that its not an int later today, simple enough to enforce the variable is the right type.

That said, you likely have another plugin causing this. I just dug through the code that WP uses for WP_Term_Query before the filter we tap into there. If ->terms is an array of integers, another plugin has modified it already inappropriately. WP core always sets it to an array of $term_objects. This likely has other side effects you might not even be seeing.

You can use the Health & Troubleshooting plugin to troubleshoot our plugin, then activate other plugins you think could be interacting with taxonomy queries until it breaks again. PS Troubleshooting mode only works for your account via a cookie, so nobody else will be affected during your tests.

For reference we use this library to auto prefix everything https://github.com/BrianHenryIE/strauss

@bearstar – Ahh, scared me for a minute there that we somehow committed an update without all the build files, but I can see them in SVN just now

https://plugins.trac.ww.wp.xz.cn/browser/content-control/tags/2.2.2/vendor-prefixed/pimple/pimple/src/Pimple/Container.php

I also find it strange 2.2.1 worked, as nothing changed in our vendor classes between those 2 versions.

I wonder if your 2.2.2 zip somehow didn’t fully unzip somehow leaving it partially there, except the error indicates ours loaded, but there was an issue finding files from the other plugin.

Might just be worth reinstalling both from fresh zips to the latest.

Not sure how there could be a namespace issue as the class loaders are usually generated with long strings of random chars in their names too.

Interesting concept indeed, please let us know what plugin your using for translations.

We will revisit this entirely and refine it in v2.3.

v2.2.2 has this query filter disabled outside the rest api.