Daniel Iser

Isn’t WP CLI considered to be an “admin” access as it is only available to those with access to the website server not web users.

Yes, and no. Requests are explicitly unauthenticated by default. Yes you can manipulate things and install plugins etc, but querying a list of content on a site with content restrictions should in all likelyhood respect those restrictions unless otherwise specified, less someone will say it isn’t properly restricting things.

So if you didn’t have any content restriction, then yes you should expect full results, but given you have gone through the process of adding access control, it should be respected as well.

Not hugely different than the REST API really when talking about fetching data.

In terms of this plugin’s user base, my guess is less than 0.1% of the users would realistically be using it, and of those how many honestly are using it to fetch content (not a common use case at all really).

So I’m not even sure it warrants a dedicated separate option to bypass restrictions for it, since users who are using it are much more likely to be able to simply add the required filter like you mentioned above.

—

I think there is a bit of confusion about how rule processing is handled. The rules were always applied to terms via archives and the main query. The only addition was processing Term_Query term loops, such as a tag cloud, or list of terms shown in a blog posts meta. The rules were simply adapted to not do anything if they have nothing in common with the given context.

For example rules like Is a Post or Is a page will simply bail early with false when the context is a Term_Query. Rules like Is Post with Term, or Is Term Archive were always there, just only applied to the main query itself.

##

As for the Entire Site rule, that was added for only a couple use cases, but specifically where they do want the entire site locked down. IE I want my entire site protected, but I don’t want to have some convoluted set of rules like “Content is a page OR Content is a post OR content is a tag OR content is a …”.

Without that rule, protecting the entire site requires adding rules for every potential content type.

With it you can add one rule.

If you were to want to protect everything except one type of content, then you could simply use a negative rule of “Content is not a Post”.

As for slowing execution, no that simple rule always returns true, ZERO processing required, thus much faster than … OR … OR … OR … which would process all of them effectively until it found a match.

Overall the rule engine here hasn’t changed the way it works since before CC v1 was released. This same rule engine powers our much larger plugin Popup Maker as well and has been refined and improved mainly.

The key differences now though are context aware rules, if there are any issues this is the only place it could come from given the rest of the functionality has been well tested and perfected over the course of nearly 10 years.

For example Posts with Tax should always return false for a Term_Query, as no Term is a Post.

But for the main query, main query posts, or Post_Query it should be checked consistently.

So my thoughts for your scenario (though I’m not quite sure what your setup should be), is that you likely just need help aligning the rules you set with the expectations of what content you want it to restrict.

Can you tell us exactly what you are trying to do, lots of what aboutisms here but we can chase those for a long time an never really find any issues to solve. If you say you need content x/y/z protected, we can guide you on exactly what rules and combinations of AND/OR/Groups to use.

—

I’m reviewing all of the term query rule context handling today, but I don’t foresee it leading to any bug fixes, more likely simple performance enhancements with bailing early where appropriate, and even that has minimal real world impact given we cache rule processing for the duration of the request (and long term via Object Caching in Content Control Pro).

Hope I didn’t miss anything.

Sorry, reread that and noticed you said

Content: Content Is Not A Page with <taxonomy> = <value>

That said the negative conditions simply check for a false value instead of a true, there is no inherent difference in how they are processed at all.

Checking more on that now, but each context processes conditions differently, IE post query & main query checks rules differently than term queries.

@peter8nss – Appreciate the details, you nailed it. Patched for the next release.

Fix was simply to rename $result -> $intent.

@reedus33 – Posting the same reply I did to your thread comments.

Sorry to hear that. Not gonna say there aren’t potential bottle necks, but often our plugin isn’t the problem, more often a symptom you see from a larger issue, such as bulk use of uncached WP_Query or WP_Term_Query, which of course we have to filter properly or users would report it doesn’t work correctly.

First to touch on code quality, bar none you will not find many with higher code quality in the repo. 15 year veteran WP developer with nearly 1 Million active users. We fully implement WordPress Coding Standards on every commit, as well as PHP Static analysis (phpstan lvl 6), and the plugin’s JavaScript fully typed TypeScript, . I’d wager 80% of plugins on the repo wouldn’t pass WPCS checks alone, and 99% wouldn’t get past phpstan lvl 1). That would include major plugins like WooCommerce, CF7, Ninja Forms, & even Gutenberg.

That said, as I touch on details below consider this, every piece of content rendered on the screen is effectively checked to make sure the user has permission. We try to optimize this, and since v2.0 we have made performance enhancements in every version. Second the only feedback we have at large scales is our own and what you see here in the forums. This thread and one from a week prior are the first “performance” issue threads ever submitted.

Next we also do New Relic monitoring on very large live sites using these same plugins, rarely do CC functions/actions come up in the top 20 slowest calls, reiterating that its likely a compounding of simply having a ton of stuff that might or might not be restricted on a given page. The 2.4.0 updates likely should help drastically if you have a large scale & high traffic site.

v2.4.0 which went out today, was tested extensively with PHP XDebug Profiling, pretty much can’t be reduced any more than that while still providing actual live & real time restriction at the granular level we provide.

1. v2.4.0 already addressed many potential bottlenecks, primarily just more static caching of function calls. A function can be well optimized and take 0.1ms to run, but if you call that function 500 times across a page load checking every post/term/title it stacks up. Static caching in v2.4.0 saves the calculated value where possible and keeps returning it. So now those 500 calls can take pretty much 0.0ms to complete.
2. Along with v2.4.0 of the free version, the pro version offers object caching in a new update coming.

In reality during local host testing, v2.4.0 with CC Pro object caching (using simple file based caching), the page loads were within +/- 1% of without the plugin active, often leaning towards -2% showing it was actually faster than without the plugin active. Not sure I believe that last part but its what the tests showed. The tests were done with term queries on 5 different custom taxonomies, rendered using repeating set of term clouds. In all 25 term clouds, 5 of each.

• Without CC, this page took ~50ms to load.
• With CC v2.3.0, the page took ~130ms to load.
• With v2.4.0 core only, the page took ~60ms to load.
• With v2.4.0 + Pro with Object caching, page load was 45-55ms.

That said there are complex issues that can create weirdness within WP and querying. We do our best to support anything done “The WordPress Way” out of the box, beyond that we’d need to investigate that specific issue.

If your still having issues after v2.4.0, you should really open a dedicated ticket with your full details anyways, performance issues are rarely gonna be 1 size fits all, for example I can’t assume your all on the same host, using same browsers, same apache stack, same plugins & custom code etc. So each should be its own thread unless you are certain the issue is the same.

Hope that helps.

• This reply was modified 1 year, 11 months ago by Daniel Iser.

@mh4press – Haven’t heard back from you in some time. We are gonna close this ticket. There are options to create custom rules with code, but @robin-labadie pointed out it should just work already.

@robin-labadie – Would love you to test that performance penalty against v2.4.0. Should see a 60-90% reduction in that penalty.

Further you can check out Content Control Pro, we are adding this week a new feature for object caching on the heavy processing of restriction calculations that should work with Redis or others. With that enabled we have seen the render times in Query Monitor drop to +/- 1% of when Content Control is not even enabled.

We can see some future optimizations of pre-calculating all of the restrictions into caches where possible, both for content matches and user permission checks. We need to work out how to let some rules bypass cache first though. Don’t want to cache things like WooCommerce Item In Cart etc.

@artemvp, @chouby, @wmcvasily – All patches for this have been released in v2.4.0. This also included tons of performance improvements.

Hey everyone, thanks for your patience, I think it will be well worth it.

v2.4.0 is officially available, should resolve this as well as provide a 60-90% reduction in plugin overhead, meaning it does all the protecting with 1/10th the performance penalty.

This should be resolved in v2.4.0. Thank you all for your continued patience. We were in the middle of optimizing a lot of the plugin for performance improvements, and needed to finish that to ensure it was reliable before we could ship this fix as well.