-
-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Restrict access to pages based on cookies/form submissions #162
base: staging
Are you sure you want to change the base?
Conversation
// but wait, what if this is a child page? | ||
// we need to see if a cookie has been set to grant access to the parent page | ||
// first, grab the top-level parent of this page | ||
if( $post->post_parent ) { | ||
|
||
$ancestors = get_post_ancestors( $post->ID ); | ||
$root = count( $ancestors ) - 1; | ||
$parent = $ancestors[$root]; | ||
|
||
} else { | ||
|
||
$parent = $post->ID; | ||
|
||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Rather than checking the immediate parent, should we check instead whether the cookie's ID is in the array of ancestors?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We could do that. In your opinion, what would make that more beneficial than this way?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The possibility of a metered page having a grandchild or great-grandchild page. They're already using great-grandchild pages: https://learn.inn.org/startup-introduction/chapter-1-where-to-start-in-nonprofit-news/creating-a-business-model/idea-generation/
Two implementation-detail questions:
|
That's a great question that I'm not sure about until we put it up on a WPE environment and test it out. We may possibly need to add some cachebusting into it.
I'm torn between yes and no here. Yes, the ID would be better in a lot of ways. But then we'll have users looking through x amount of forms trying to find the correct one because they don't know the actual ID of the page/post form they're looking for, and I'm not sure if it's a reasonable ask to expect them to know the ID. |
We could add to the meta box a link to the appropriate form. In pseudocode:
There doesn't appear to be a way to prefill the form title in the create-new-form form, unfortunately. I was hoping |
@benlk I like this idea, but the inability to populate the form title with the post ID makes me weary because then we're back at the question of whether or not its a reasonable ask to expect the user to know how to find the post ID :/ |
Changes
This pull request makes the following changes:
set_cookie_on_form_submission
function that sets a cookie for 365 days in the users browser once they submit a form if the form contains a hidden field withaccess_ID
as its labelrestrict_access_to_pages_by_cookie
function that restricts access to a page if the aforementioned checkbox is checked. However, if the user has a cookie set namedunrestrict_POST_ID
(POST_ID will be an actual post id) and it's value is set to true, the page will show.Notes:
access_ID
Restrict access metabox:
Top level page with form:
Page with no matching form but that is restricted:
Why
For #161
Testing/Questions
Features that this PR affects:
Restrict Access
checkboxQuestions that need to be answered before merging:
Steps to test this PR:
access_ID