Daniel Iser

@rogererkens – I would need the error messages to troubleshoot the logging issue. Could simply be that your host doesn’t offer direct file writing access. It shouldn’t throw errors though so we need to track that down.

As for pages not loading, we have debugged this a few times, and every time it comes down to some other plugin or them modifying the responses from the WP Rest API when querying for pages.

I’d try the health check & troubleshooting plugin. Run Troubleshooting mode on our plugin and see if the pages load correctly. If so then go back to plugins page and activate the other plugins a few at a time until it breaks again.

PS Troubleshooting mode should be done with a default WP theme installed. So install Twenty Twenty Two or Twenty Twenty-Three theme for example. This eliminates your theme as a possible conflict point as well.

Let us know.

@cbfriend – Ok in that case I’ve been working with WPML on remapping our targeting rules so they can be applied across translations properly. This is probably the correct solution for your needs as well, though its likely a bit off so we can help you craft a custom rule in the mean time.

Your callback would be something like

function custom_rule_callback() {
    return strpos( $_SERVER['REQUEST_URI'], '/url/you/want' ) !== false;
}

You would register it something like this:

add_action( 'content_control/rule_engine/register_rules', function ( $rules ) {
    $rules->register_rule( [
	'name'     => 'custom_rule_1',
	'label'    => __( 'My Custom Rule', 'content-control' ),
	'context'  => [ 'content' ],
	'callback' => 'custom_rule_callback',
    ] );
} );

@havor99 – Not a problem. If your using the block editor there are controls on the sidebar to handle this for each block: https://contentcontrolplugin.com/docs/block-controls/how-to-add-a-restriction-to-a-block/

Otherwise you can use our [content_control] shortcode around the forms shortcode: https://contentcontrolplugin.com/docs/developer-docs/how-to-use-the-content-control-shortcode/

Hope that helps, if so please take a moment to rate & review the plugin and or support to spread the word.

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

@ashishkamaldhari – It should just work, if you don’t see your post type in the rule selection dropdowns, it likely means it is being registered way too late for our code to recognize it and generate rules for it.

Your CPT should be registered during init action, but if it is not by the time admin_enqueue_scripts has run, you won’t get the extra rules.

• https://developer.ww.wp.xz.cn/reference/functions/register_post_type/
• https://codex.ww.wp.xz.cn/Plugin_API/Action_Reference

Otherwise all functionality is built to just work with custom post types & taxnomies the same way it does for the built in ones.

Hope that helps.

Hmm, filter_the_content_if_restricted should theoretically be called from within the_content filter, as such the global $post should be set properly.

I wonder if TEC is doing something different there calling the_content generically without setting global first.

You can do that in code, simply calling apply_filters( 'the_content', $content ) doesn’t care about global states or doing it right.

That would be my guess, they just apply generic content filters, instead of setting globals for per post filtering.

@peter8nss – You might try the following:

function get_current_page_url() {
    global $wp;
    
    // Get base URL without the query string.
    $base_url = home_url( $wp->request );
    
    // Check if it has a trailing slash, if not add one, unless there's a query string.
    if ( empty($_SERVER['QUERY_STRING']) && substr($base_url, -1) !== '/' ) {
        $base_url .= '/';
    }

    return add_query_arg( $_SERVER['QUERY_STRING'], '', $base_url );
}

Or this one

function get_current_page_url() {
    global $wp;
    
    // Get base URL without the query string.
    $base_url = home_url( $wp->request );

    return add_query_arg( $_SERVER['QUERY_STRING'], '', trailingslashit( $base_url ) );
}

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

@peter8nss – Hmm, first get_the_ID() should work, as we do this within the restriction checks there as well,

We can definitely add that, I though we had already done work to add that, remember doing so but don’t see the commit logs, so either I thought it through previously or even coded it but didn’t get it committed for some reason.

Currently I think you have another option too, make multiple restrictions, similar but different based on content, just update the rules on each based on which tag your filtering content on for example.

Future 3rd option, I’ve been working on v2.1 which will likely also allow using presaved block patterns, and since we have block controls that can selectively target based on post info as well, you could also build it that way.

Let me know about get_the_ID().

@pmckane – By far the coolest & most accurate review we’ve got yet. Much appreciated feedback.

I think with this one we focused on making it blend like it belonged there naturally. It definitely seems we hit the mark based on your review.

I highly suggest you check out its companion plugin Content Control.

I will say though, and I hope its not to your disliking, but we do have some premium concepts for this in the early planning. Even so were committed to:

• Make the free version better and more capable, more reliable, more integrated, including support for the new block menus.
• Pro will add additional functionality that not everyone needs, but some will find super valuable, such as ecommerce integrations.
• Pro will not be blasting notices everywhere, probably some subtle (and filter removable) text links in the context of the editor where they actually make since. Such as “Need rules for WooCommerce purchase history, Try Pro ( ! ).” which would likely only appear if we detected WooCommerce was installed at that.

User Menus likely won’t need a full page for settings like other plugins, but your free to check out Content Control v2+ and see how we mention the upgrade paths only where appropriate.