peter8nss

It looks like I can get the functionality back by commenting out the Query Terms functionality. Specifically, by commenting out the add_action in QueryTerms::init().

I was considering doing this using the query_filter_init_hook filter but I can’t because the posts and terms filters use the same name.

In reality, I’m going to have to stick with version 2.1.0 until the new query terms functionality has been properly resolved/tested.

If you replace “wp_send_json( $page )” by “return new FulfilledPromise( $page )” you can defer calling “wp_send_json” until after the “all” aspect of the promise has been evaluated. Then just apply wp_send_json to the first non-null response from “API_Client::execute”.

Doing this for Frontend Page and Gallery classes seems to remove the randomness of the folder verify checks. Unfortunately, that means all shortcut folders then fail the verification.

I think the randomness I’m seeing is because the folder verification and page fetches are both being done asynchronously at the same time. I think the use of “Utils::all” at the end of API_Client::execute is intended to cause an error to be returned if either fails, but I don’t think that will always be reached. If the page fetch returns first, then I think its use of wp_send_json, in the response processing, will effectively stop the processing (by calling “wp_die” or “die”) before that check is reached.

It seems a bit strange to queue the page fetch before you have confirmed the path is valid. And as noted at the start, I’m not sure the path checking works for a google shortcut anyway.

nb: I’m not seeing this behaviour on all shortcut folders. I need to check why some are and some are not.

This has been marked as resolved but I don’t think it has. Problem is still present in version 2.1

I’m no longer seeing that error with these new releases. Thanks.

WordPress 6.3.2

PHP 8.0.29

I think so. I came up with that before I’d fully read your response as it seemed to minimise the code change.

Thanks for fixing this.

I think the reason I’m not getting any post id is because the restriction is triggering from “filter_the_content_if_restricted” rather than “restrict_query_posts” (i.e. filters on “the_content” rather than “the_posts”).

The scenario I’m working on is securing the information sent out in ical messages (from The Event Calendar plugin). However, I think I’m probably better to use the hooks in The Event Calendar for this rather than abuse the design of Content Control.

Thanks again for your help on this.

Tested a variant of the second one which seems to work.

function get_current_page_url() {

    global $wp;

    /* phpcs:disable WordPress.Security.ValidatedSanitizedInput.InputNotValidated, WordPress.Security.ValidatedSanitizedInput.InputNotSanitized, WordPress.Security.ValidatedSanitizedInput.MissingUnslash */

    return add_query_arg( $_SERVER[‘QUERY_STRING’], ”, trailingslashit( home_url( $wp->request )  );

    /* phpcs:enable WordPress.Security.ValidatedSanitizedInput.InputNotValidated, WordPress.Security.ValidatedSanitizedInput.InputNotSanitized, WordPress.Security.ValidatedSanitizedInput.MissingUnslash */

}

Thanks for the prompt response. I’d already tried get_the_ID() and it is returning false. Hence, my question.

This occurs when I’m retrieving calendar data (using plugin The Event Calendar) so it may be some oddity related to how that plugin is working rather than the Content Control plugin.

Passing the post to the filter would be nice and would give me post level granularity for controlling the messaging. However. I appreciate that you may have other developments that are higher priority.

Apologies for not getting back to you sooner. I could have sworn I replied to this a while ago. Maybe I forgot to press Submit.

I did some more digging and traced the problem to the content_is_search_results rule which uses callback function \is_search. The function returns true both for the search page itself and any posts found by the search. So a restriction:

• Is not page with term=xxx AND
• Is not search page

Will

• (correctly) let the search page be displayed because \is_search returns true, so second condition is false, so result is false and the restriction is not applied
• (wrongly) include ALL search results (including page with term=xxx) because \is_search returns true, so NOT search page returns false, so regardless of the first condition the result is false and the restriction is not applied
• (correctly) redirect if you try and access a search result that should not have been there (e.g. a page with term=xxx) because the first condition returns false when accessing it

I suspect the solution is to change the callback function for content_is_search_results rule to an internal one that can distinguish between a search page and the results on it.

Thanks for the suggestion. I think I’ll live with the optional phone number being unvalidated as my workaround until the plugin code fix comes through.

I’ve only used Query Monitor a little, but doesn’t it rely on the you being logged in having the WordPress menu bar available. As such it might be difficult to use it to test the different user cases, e.g. not logged in users.

I think there is scope for a 3rd option “All users” or the ability to select both “Logged in users” and “Logged out users” for a restriction. [The pendant in me wonders if it should be called something like “Everyone”, since it could include people who aren’t registered “users”.]

That would certainly make my scenario simpler, in that no negation would be needed. I think it would become:

• Restriction 1: Logged in Users with particular roles, A few pages marked as sensitive
• Restriction 2: Everyone, Public pages OR Search
• Restriction 3: Logged in users, All content

Which I think is more intuitive.

Fully appreciate there may be a delay in this getting changed. Just keen that this is eventually sorted. I look forward to your feedback in due course.

Please remember my case is an “optional 2nd phone number”. I want a phone number that is either:

• Empty, or
• Valid

So my settings would be

• Require=Optional
• Validation=National

Hence, my suggestion that this might be achieved if the validation patterns were extended to include a blank number as valid. For those who required a valid number, their settings would be:

• Require=Required
• Validation=National

So although blank would be passed by the national validation, it would still be thrown out by the required check.