Daniel Iser

@reedus33 – 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 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 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.

So as to the tickets status, the original reported gave no real details for us to go on, never came back, and we can’t replicate he issue, thus it gets closed.

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.

@chouby – This has been merged into dev, will go out with patch shortly this week.

@rbdev – More specifically I’m inclined to ask how our plugin is involved with these transactions. This plugin does not interact with ecommerce or subscriptions currently.

@rbdev – We have it coming for CC but it won’t be ready til late this year or early next depending on dev schedule.

In the mean time, we support using Easy Digital Downloads & WooCommerce, but if you find another payment gateway plugin you’d like to use, let us know and we can probably build integrations with that as well.

Hope that helps.

@brightleafgil, @nobo73 – Thanks for the reports, patch submitted, will go out later tomorrow (or today depending on where you are).

Just to confirm are the users who are able to see the content still, also able to edit it? If so you might try testing a user who can’t edit the post to confirm my findings & fix will handle your case too.

In my debugging I found a check that let authors/editors of a post bypass restrictions outside of “post previews”.

@zvaranka – Thanks will see what I can do.

Curious what happens if you load the files into the wp-content/languages folder instead of the plugins language folder.

@zvaranka – I’ll have to look into why that isn’t working, though we have long left it to WP’s built in LangPacks and community efforts here on the translate.ww.wp.xz.cn page: https://translate.ww.wp.xz.cn/projects/wp-plugins/content-control/

• https://translate.ww.wp.xz.cn/locale/hu/default/wp-plugins/content-control/

Not sure if we have to do something on our end to make it work with that folder, seems it should just work since its all based on WP filters.

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

@hrsms, @juliushg – By chance are either of your menus very large? Like 20+ items?

If so it might simply be the WordPress (too damn much data at once) menu saving bug.

In that case what is happening is you likely have other plugins besides ours also adding custom fields to your nav menus, with all those $extra_fields * $num_men_items it can scale past the wordpress limit of 1000 fields max quickly (i think thats the number).

In these cases there are not a lot of easy 1 click solutions, most will involve either modifying your approach to the nav menus in general, deactivating other plugins that are adding fields there if you don’t need them, or modifying core files to allow higher limits temporarily.