WordPress.org

Make WordPress Core

Opened 3 months ago

Last modified 3 months ago

#46831 assigned enhancement

Warn users when Privacy Policy page is set as 'Homepage' or 'Posts page'

Reported by: garrett-eclipse Owned by: garrett-eclipse
Milestone: 5.3 Priority: normal
Severity: normal Version:
Component: Administration Keywords: has-patch needs-testing
Focuses: ui, privacy Cc:

Description

Hello,

If you set the 'Homepage' and 'Posts page' to the same page you get a warning;
"Warning: these pages should not be the same!"

It would be nice if a similar warning would indicate if the Privacy Policy page was accidentally set as either. Maybe a message along the lines of;
"Warning: these pages should not be the same as your Privacy Policy page!"

Thanks

Attachments (5)

Screen Shot 2019-04-08 at 1.43.15 AM.png (97.3 KB) - added by garrett-eclipse 3 months ago.
The warning when same page is used for 'Homepage' and 'Posts page'
46831.diff (863 bytes) - added by subrataemfluence 3 months ago.
Screen Shot 2019-04-08 at 11.38.39 PM.png (104.7 KB) - added by garrett-eclipse 3 months ago.
Successfully testing the warning
46831.2.diff (1.3 KB) - added by garrett-eclipse 3 months ago.
Minor update to @subrataemfluence's lead
46831.simple.diff (1.1 KB) - added by garrett-eclipse 3 months ago.
Simplified version

Download all attachments as: .zip

Change History (11)

@garrett-eclipse
3 months ago

The warning when same page is used for 'Homepage' and 'Posts page'

#1 @mukesh27
3 months ago

  • Keywords needs-patch added

#2 follow-up: @subrataemfluence
3 months ago

  • Keywords reporter-feedback added

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 your Privacy Policy page!' ); ?></p>
   </div>
<?php endif; ?>

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 custom Privacy policy pages.

Version 0, edited 3 months ago by subrataemfluence (next)

#3 in reply to: ↑ 2 @garrett-eclipse
3 months ago

  • Keywords reporter-feedback removed

Replying to 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 your Privacy Policy page!' ); ?></p>
   </div>
<?php endif; ?>

Although I am not sure how feasible it would be to create another post_type!

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 custom Privacy policy pages.

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 Privacy Policy page, forcing a CPT adds additional load and would require existing pages be converted to the new post type. As well this change would almost hide the Privacy Policy pages on the Menu Editor as Pages are 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;

<?php
$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

#4 @subrataemfluence
3 months ago

@garrett-eclipse I perfectly understand what you said. Thank you for explaining it so nicely. I was not in super favor of adding another CPT, but was thinking if that could be an option so only proposed! :)

And yes, the ID is available and we can easily use it to determine like you mentioned.

I am working on it.

*The example you provided would be unnecessary if privacy was a CPT as the dropdown only calls pages so no check would be needed.

Right! It will not be there in the dropdown any way :) My bad!

Last edited 3 months ago by subrataemfluence (previous) (diff)

#5 @subrataemfluence
3 months ago

  • Keywords has-patch added; needs-patch removed

Hi @garrett-eclipse please let me know if the patch works.

By the way, get_option( 'page_on_front' ) returns the ID while get_option( 'show_on_front' ) returns the CPT type. I know it was nothing but a typo :)

@garrett-eclipse
3 months ago

Successfully testing the warning

@garrett-eclipse
3 months ago

Minor update to @subrataemfluence's lead

@garrett-eclipse
3 months ago

Simplified version

#6 @garrett-eclipse
3 months ago

  • Keywords needs-testing added
  • Milestone changed from Awaiting Review to 5.3
  • Owner set to garrett-eclipse
  • Status changed from new to assigned

Thanks @subrataemfluence I appreciate the patch and like the direction, you're on the ball.

Testing went nicely, screen attached.

I made some minor tweaks in 46831.2.diff making the id unique and adding some spacing, as well as adding the @since to 5.3 as this is an enhancement and 5.2 is already in beta.

While looking at the original front-page warning I was wondering if we should just do a simplified version to match the front-page-warning, so uploaded 46831.simple.diff as an alternate.

I appreciate you moving this forward, all the best

Note: See TracTickets for help on using tickets.