noreply at wordpress.org
Mon Apr 8 17:25:21 UTC 2019
Reporter: garrett-eclipse | Owner: (none)
Type: enhancement | Status: new
Priority: normal | Milestone: Awaiting Review
Component: Administration | Version:
Severity: normal | Resolution:
Keywords: needs-patch | Focuses: ui, privacy
Changes (by garrett-eclipse):
* keywords: needs-patch reporter-feedback => needs-patch
Replying to [comment:2 subrataemfluence]:
> It would be a good addition since WordPress is looking at Privacy page a
bit differently. However, the problem is the `post_type` being used by
this page is `page`.
> What I have understood so far is if we can incorporate an additional
native post_type called `Privacy` and that gets associated with the
Privacy page created from `Settings -> Privacy` menu, it would be easier
to handle things associated with this page.
> In the context of this ticket we can then put a check like:
> <?php if ( 'privacy' == get_option( 'show_on_front' ) || 'privacy' ==
get_option( 'page_for_posts' ) ) : ?>
> <div id="front-page-warning" class="error inline"><p><?php _e(
'<strong>Warning:</strong> Warning: these pages should not be the same as
> <?php endif; ?>
> Although I am not sure how feasible it would be to create another
> However, one can create his own Privacy page without using
`Settings->Privacy` menu and that is always treated as `page` post_type.
> In this scenario, the above approach will not work. Even an additional
post_type `privacy` is introduced (?), the problem will still remain for
Thanks @subrataemfluence I appreciate the feedback. However, I would
strongly suggest against a CPT for privacy pages as it would unnecessarily
complicate the content creation and association processes. Currently,
admins can create a page or use an existing page to associate it as the
existing pages be converted to the new post type. As well this change
default expanded for selection so if a new CPT was introduced it would
become hidden like posts and custom link settings. As well as a CPT it
would additional load to site owners and theme developers as they'd need
to provide default template for it whereas now the page.php is being used,
and any styling done for pages would need to be replicated.
IMHO using a CPT for privacy pages unnecessarily complicates things and
forces replication of existing functionality already available for pages.
As well with all the helpers being introduced in #44005 in 5.2 developers
can more easily customize their privacy page and menu items separate from
their standard pages if they so desire.
Sidenote: The `show_on_front` and `page_for_posts` options return page IDs
so would need to compare those against the `wp_page_for_privacy_policy `
page ID as follows;
$privacy_policy_page = get_option( 'wp_page_for_privacy_policy' );
if ( $privacy_policy_page == get_option( 'show_on_front' ) ||
$privacy_policy_page == get_option( 'page_for_posts' ) ) : ?>
*The example you provided would be unnecessary if privacy was a CPT as the
dropdown only calls pages so no check would be needed.
I appreciate the feedback and discussion but feel we should avoid
complicating things with a drastic change such as switching to a CPT.
All the best
Ticket URL: <https://core.trac.wordpress.org/ticket/46831#comment:3>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac