Daniel Iser
Forum Replies Created
-
@rogererkens – Sorry to hear that. Hope you feel well soon.
@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:
- I unchecked the Exclude administrators from being restricted, which was skewing my initial tests of the search page being blocked.
- 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.
@rogererkens – One final follow up before I mark this closed.
I troubleshot another users setup where their page/post search fields were not working great (seems related).
I found that due to either slow hosting or some un-performant plugins on their site that the requests for that data were just very slow, like 1.5s-3.5s as opposed to what we’ve normally seen which is 100-600ms.
I’ve. made a few small adjustments to help improve things:
- We now show a
Searching...message in the dropdown instead ofNo results founduntil the request completes. That way you know its doing something at least. - We optimized so that it tries to load more by default, so that most are just there. (all if possible, but REST API might have its own limits).
- We reduced the number of calls to the server by ~50% on initial load of those fields data, which should make the others complete faster.
Without further input from you on the issue, this might be where we have to leave this for now and mark it resolved.
I’ll leave this open another day or so, if you come back and its already closed, feel free to mark it unresolved and update us with as much of the requested info as possible so we can help you to find a resolution.
Hope that helps.
@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.
@lewisburgess79 – Ok so I just set up a test using the following simple but effective blob of shortcode:
[content_control logged_out=1]Login[/content_control][content_control]Logout[/content_control][content_control logged_out=1]Login[/content_control][content_control]Logout[/content_control][content_control logged_out=1]Login[/content_control][content_control]Logout[/content_control][content_control logged_out=1]Login[/content_control][content_control]Logout[/content_control]This results in
Logout
Logout
Logout
Logout
When I expect LogoutLogoutLogoutLogout etc.That said I also tested this same code on v1.10.2, with the exact same results.
So it wasn’t different before, but I do see the need for this to work as intended.
We might have to add aninlineparameter to it.I do think you can get there today using the following.
[content_control logged_out=1 class="inline"]Content[/content_control]Then add some CSS to your site of
.content-control-container.inline { display: inline; }I have added this to our issue tracker. Gonna mark this resolved for now as its not a new bug and we need to think out a long term solution.
Please take a moment to rate & review the plugin and or support to spread the word.
- This reply was modified 2 years, 8 months ago by Daniel Iser.
@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.phpis 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.
Ok the only errors I saw related to our plugin were from months ago on the older version.
That said I’m pushing some updates that help with general compatibility with other plugins, would be useful to have you retest with v2.0.10 when it releases later today.
@davecarpenter – Did you want to keep troubleshooting this, looking to clean up any remaining issues before we move on to other stuff.
@gerold1968 – Ok so in v2.0.10 that code you added to fix it will be the default and no longer needed.
That should also resolve conflicts with the WooCommerce plugin you uncovered.
Hope that helps. Please take a moment to rate & review the plugin and or support to spread the word.
@rogererkens – Any news, have any of the recent updates helped with being able to select or load page names?
- Are the restrictions working? Again by default we store the IDs, the names are just rendered for easy readability.
- 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:- Activate other plugins a few at a time.
- Test if it works. If so, return to step #1.
- If it breaks, deactivate each plugin you just enabled one at a time.
- Test if it works. If not, return to step #3.
- If it works, the last plugin deactivated is a conflict.
- Deactivate that one, return to step #1 skipping known conflicts.
- 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 🙂
@bcourcet – I think I misunderstood a bit the first time. Ok so you can choose the Video Tag rule, but none appear in the tag chooser?
If so can you check your console (F12key usually, then console tab), for errors during this process.The only thing that makes since is if there was an error from the REST API when searching those items, this could be a PHP error on the server preventing the response from being sent.
Maybe check PHP error logs on your hosting dashboard as well, anything that might be helpful at narrowing down the cuplrit.
Last option would be to 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:- Activate other plugins a few at a time.
- Test if it works. If so, return to step #1.
- If it breaks, deactivate each plugin you just enabled one at a time.
- Test if it works. If not, return to step #3.
- If it works, the last plugin deactivated is a conflict.
- Deactivate that one, return to step #1 skipping known conflicts.
- Follow this until you have a list of all the conflicting plugins.
@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.
@chrisoaten – Good catch, I think I know what is going on with it not working in theme files, I think its running too early for your themes functions.php to hook in.
I think i’ll move our calling of the filter to
initorafter_setup_themewhich is described as firing immediately after loading of functions.php.Thanks for pointing this out, will be patched in v2.0.10.
Also by moving the call to
initwe might just avoid needing to add filters or hacks in the first place.- This reply was modified 2 years, 8 months ago by Daniel Iser.
@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.
@thomascharbit As I have both confirmed this and resolved it in the next update gonna go ahead and mark this resolved, this will help in tracking which issues are still persisting.
If you’d like to test the fix yourself, these are the ones I think are relevant:
- https://github.com/code-atlantic/content-control/commit/2649578288f0c561d8109b72c9c96978a1fd79e9
- https://github.com/code-atlantic/content-control/commit/043184e43272b449c0ef4bb6301dd61cf5e2d5ec
- https://github.com/code-atlantic/content-control/commit/44df4534d9f028eaaffa996ffb1f1258c227365c
If this fixes it for you as well, please take a moment to rate & review the plugin and or support to spread the word.