Daniel Iser

@peter8nss – Ok I’ve been trying to figure out exactly what your trying to describe happening. Came back to this and reread it completely several times over the past week while resolving various issues.

Just to confirm, in your setup your logged in users SHOULD NOT have access to search pages? Seems a bit unrealistic but I’ll go with it to see if there is a solvable issue here.

First let me preface this with I made a bunch of patches this week that improved 3rd party plugin compatibility, but also how we process rules & render content. I’m not certain but this may have an impact on my results versus using an older version.

OK, so I tried your setup and it did in fact not do either of the things it should have. BUT then:

1. I unchecked the Exclude administrators from being restricted, which was skewing my initial tests of the search page being blocked.
2. I changed the priority to enforce the main priority, blocking of posts from logged out users, search restriction for logged in users is secondary concern (assuming OPSEC style priorities).

This worked and logged out users don’t see posts, logged in users get redirected to login when trying to search.

What that tells me is that priority is being properly respected, but might need fine-tuning and be context-aware as to not bypass a redirect rule for a hide rule, and to also possibly consider login/role status checks at the same time, rather than in separate processes.

That might require some refactoring and testing that will take longer than a quick patch, but I’m making lots of notes as we want it to intuitively just work in these scenarios, or at least as close as possible.

I’m still not sure of how the original issue connects exactly, I think seeing that one laid out more completely might be helpful in defining the goals of this refactor.

@bcourcet – We pushed an update earlier today. Can you check and see if that helped resolve the issue. We made quite a few changes to improve general compatibility, 2 changes might have an impact on your issue.

That said I haven’t seen any responses from you in the past week, so given that we have patched 🤞 related issues I’m gonna mark this resolved for now.

If your still having trouble, please change it back to unresolved and update us with the requested info so we can troubleshoot properly.

If your issue is resolved, please take a moment to rate & review the plugin and or support to spread the word.

@chezterman – Hmm so just to be absolutely certain, your saying these errors occur pretty much all the time (every page load).

That’s definitely not ideal, hopefully I can work it out quickly for you.

That said the file in question content-control/classes/Base/Stream.php is only called, or at least should be, during a single AJAX request over the rest API after you click the “Start Upgrades” button.

It shouldn’t at all run without your interaction, much less on every page load.

Would it be possible to get temporary secure access to the site in question so I can investigate further?

You can follow this guide and submit the token via our support form.

@davecarpenter – Did you want to keep troubleshooting this, looking to clean up any remaining issues before we move on to other stuff.

@rogererkens – Any news, have any of the recent updates helped with being able to select or load page names?

1. Are the restrictions working? Again by default we store the IDs, the names are just rendered for easy readability.
2. Can you search for them in the field or do no results appear? If no results you may have a PHP error preventing the return of results which we would need to track down.

You can also install the Health Check & Troubleshooting plugin, with that you can enable Troubleshooting mode on our plugin. This will deactivate (only for you) all the other plugins.

Then you can follow the following to narrow down the conflict:

1. Activate other plugins a few at a time.
2. Test if it works. If so, return to step #1.
3. If it breaks, deactivate each plugin you just enabled one at a time.
4. Test if it works. If not, return to step #3.
5. If it works, the last plugin deactivated is a conflict.
6. Deactivate that one, return to step #1 skipping known conflicts.
7. Follow this until you have a list of all the conflicting plugins.

Want to get these issues closed up so we can move on to future enhancements 🙂

@junxiu6 – Can you confirm your using WP 6.1.x or lower? IE Your not on WP 6.2+

I just did some digging and tested on WP 6.1.13 and worked out 2 bugs, can both confirm your findings and that it is fixed in v2.0.10.

Please update and confirm you don’t see any further issues.

If not please take a moment to rate & review the plugin and or support to spread the word.

@lukiano880 – Just retested and verified some issues, patches incoming (v2.0.10) later today.

You can test the fix now by adding the following:

remove_filter( 'the_posts', [ \ContentControl\plugin('Frontend\Restrictions\QueryPosts'), 'restrict_query_posts' ], 10, 2 );

add_action( 'init', function () {
	add_filter( 'the_posts', [ \ContentControl\plugin('Frontend\Restrictions\QueryPosts'), 'restrict_query_posts' ], 10, 2 );
}, 999 );

If that solves it for you as well, please take a moment to rate & review the plugin and or support to spread the word.

PS after the update I’d remove that to ensure your using the latest & most reliable setup.

• This reply was modified 2 years, 8 months ago by Daniel Iser. Reason: Add testable code solution
• This reply was modified 2 years, 8 months ago by Daniel Iser.