Daniel Iser

@dkurapati – Can you share your restriction protection method and content rules?

Further if google is showing chinese content for your site, it likely means your site was compromised with malware some weeks ago as search results take time to update and we only pushed our plugin update this week. I can assure you these issues are not coming from our code, there are only latin based characters (english) in it.

You might install a security scanner plugin like WP Vuln or Securi or Ithemes security or all of them one at a time and run scans.

@dkurapati – Can you try installing v2.0.6 or later. I made some patches to try and address these situations.

There are 2 possibilities if that doesn’t work:

1. The plugin that creates that content type epkb_post_type_1 doesn’t register post types before the WP init action. We try to address this with a patch to prevent our code from checking until as late as possible which should have fixed this.
2. You have another plugin/theme on your site querying posts before all the post types are registered (earlier than they probably should be, though that is out of our control ultimately). In this case we can give you some code to add that will help identify which plugin/theme/code is doing it, and hopefully then help set our plugin to ignore those queries. That should cause it to work correctly.

@kionae, @joroabv – Thanks for the testing and insights.

Yeah, I think so, but if that’s the case – it is an issue for the “Pages with category and tag” plugin, I think. I somewhat raised the question here : Doesn’t play well with Content Control 2.0 plugin | ww.wp.xz.cn 

So I’m not gonna lay the blame there. We need our plugin to “just work” on any commercialized site for it to succeed. As such this is likely not the only scenario where early calls and late registered hooks are gonna be a problem.

Though they could solve it for their one use case, from our perspective we need to focus on a solution that will work properly solve it for any user case.

Can confirm that dropping the priority to 9 when adding categories/tags to pages did fix the issue for me. Removing/re-adding your filters (with no changes to aforementioned priority) did nothing on my install.

@kionae – Great, I patched ours to run the registration as late as possible by default. We use them in the_posts, template_redirect & wp_enqueue_scripts.

What i’ve deduced is that there are 2 scenarios where issues will arise:

1. Post types or other things that generate dynamic rules get registered after our first use (the_posts). But I’ve patched it so that in normal circumstances if they do it by or duringinit they are good to go.
2. Some other plugin/theme makes queries long before init , BuddyBoss is one I came across for example that prequeries lots of data for the logged in user at plugins_loaded or similar
   • I have a debug snippet that tries to detect when this occurs and log it when I come across it.
   • We also built in mechanisms to filter whether we try to apply restrictions to any given query, we may need to simply exclude queries before specific actions like init or with specific parameters (CPT names for example).

I just thought you’re using it, since you mentioned pages tags. But anyway – it is the same principle and I think the plugin I use has the same problem.

Her code was near identical to what the plugin you mentioned uses. Tested both pretty extensively, even filtered the order plugins were loaded which did seem to work (when you load their init action on the same priority before ours). But now that doesn’t matter as we do it even later.

Only concern now is plugins making post queries before init, because I can’t control all the other plugins & custom code that do things properly and register their changes by init, I have to develop the WP way, and make adjustments to compensate for those that don’t.

Let me know if your still having trouble after the latest changes, if so I’ll give you the debug code to find the plugin that is making early queries so we can at least get it on the list.

Otherwise if its solved, please take a moment to rate & review the plugin and or support to spread the word.

<span style=”color: rgb(50, 55, 60); font-family: “Open Sans”, sans-serif; font-size: 14.4px; white-space-collapse: collapse;”>@willemb2</span> – Thanks for the heads up, so that was intentional on my part. I decided to make a site with 0 restrictions say its complete with errors. Mainly this is to get your attention and check the logs. If you see 0 restrictions migrated but you had a dozen, you would know something went wrong.

I also added an automated backup of data prior to the upgrades processing now which you would also see in the logs and be able to verify or restore if needed.

I’m open to suggestions on how we might improve that process to both be smooth & intuitive in these scenarios. But your all good to go I believe.

Also please take a moment to rate & review the plugin and or support to spread the word if don’t mind.

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

@gerold1968 Ok I have this patched I believe, it will be in v2.0.7 in a few hours time (maybe sooner but I see at least 7 other tickets I need to try and solve asap as well).

If your so inclined to test the fix before then, that would be great too and help confirm we fully solved it before another update.

@joroabv Ok so by your description it’s not the restrictions causing the issue, but a side effect of just being installed essentially?

Can you tell me if your using other features like

• [content_control] shortcode
• widget controls
• block controls [new]

Can either of you share temporary access to your site or take a few minutes to try and recreate the issue on one of your demo sites?

• Grant support access and you can submit it securely via the support page there.
• Create a demo site – the plug-in may need updated there to the latest version first, but you can install any other plugins you need to duplicate it and we can debug it that way.

@rogererkens – Sorry to hear that. Backwards isn’t the way to go so let’s see if we can’t help you work out any kinks in the new version.

1. Our new editor uses react and the Rest api. Because of this when editing a restriction, at first it might only show numbers for your selected items, but that is because it has to load the page/post titles from the Rest API. They should replace with text as soon as that happens. If not it would generally mean those items either no longer exist or there was an error of some kind fetching them from the Rest API
2. Rules were always done by ID, so that shouldn’t break functionality.
   

Can you tell me in detail how you have it set up, what you expect to happen and what is actually happening?

@guy101 – Awesome, Please take a moment to rate & review the plugin and or support to spread the word.