Make WordPress Core

Opened 8 years ago

Closed 8 years ago

#37580 closed enhancement (fixed)

Users who cannot set the Front page or Posts page should not be able to delete these pages

Reported by: jakept's profile JakePT Owned by: johnbillion's profile johnbillion
Milestone: 4.7 Priority: normal
Severity: normal Version:
Component: Role/Capability Keywords: has-patch has-unit-tests
Focuses: administration Cc:

Description

Setting the Posts page and Front page requires the manage_options capability, so by default is restricted to Administrators (and/or Super Administrators? I'm not terribly familiar with Multisite). However users with the Editor role are able to delete these pages, as they have the delete_pages, delete_published_pages and delete_others_pages capabilities.

The problems with this are that, firstly, it means they effectively have the capability to change the values of these settings that should be for users with manage_options to set, and secondly, it means editor users can make a mistake that they cannot undo. A pretty major one as far as a site's content is concerned. This can particularly be a problem for users who are effectively the main administrators of their sites, but are running on lower capabilities because that's how their web developer supports the site.

Here's a support thread where someone's run into this issue:
https://wordpress.org/support/topic/restored-trashed-blog-page-now-previously-published-blog-posts-not-viewable

Attachments (2)

37580.diff (533 bytes) - added by JakePT 8 years ago.
37580-unit-test.diff (1.1 KB) - added by JakePT 8 years ago.

Download all attachments as: .zip

Change History (14)

#1 @Kenshino
8 years ago

  • Focuses administration added
  • Keywords needs-patch dev-feedback added

@JakePT

Does make sense.

How do you propose to solve this conundrum?

#3 @JakePT
8 years ago

@Kenshino In map_meta_cap it seems fairly trivial to just set it to manage_options if the post in question is the front page or posts page:

<?php
case 'delete_page':
...
        if ( get_option( 'page_for_posts' ) == $post->ID ) {
                $caps[] = 'manage_options';
                break;
        }

        if ( get_option( 'page_on_front' ) == $post->ID ) {
                $caps[] = 'manage_options';
                break;
        }

But that doesn't provide any explanation to the user about why, and doesn't account for the ability to unpublish the pages by setting to draft, private etc.

I'm not 100% sure that either are necessary, but worth considering I think.

Last edited 8 years ago by JakePT (previous) (diff)

@JakePT
8 years ago

#4 @JakePT
8 years ago

  • Keywords has-patch added; needs-patch removed

#5 @johnbillion
8 years ago

  • Keywords needs-unit-tests added; dev-feedback removed
  • Milestone changed from Awaiting Review to 4.7
  • Version trunk deleted

Thanks for the ticket and the patch, @JakePT. This makes sense.

Can you provide some unit tests please? Ping me if you need any help.

#6 @johnbillion
8 years ago

Regarding unpublishing or setting to private, etc, these are actions that the editor role can correct themselves. Deleting the page can only be fully corrected by an administrator role creating a new page and then updating the "Front page displays" setting.

#7 @JakePT
8 years ago

  • Keywords has-unit-tests added; needs-unit-tests removed

#8 @JakePT
8 years ago

I think that's right. My first time doing a patch or unit test, so please let me know if I can do anything better!

#9 @johnbillion
8 years ago

  • Owner set to johnbillion
  • Status changed from new to reviewing

#11 @johnbillion
8 years ago

#30352 was marked as a duplicate.

#12 @johnbillion
8 years ago

  • Resolution set to fixed
  • Status changed from reviewing to closed

In 38378:

Role/Capability: Only users who can manage options should be able to trash/delete the page for posts or the front page, as they are the only users who can restore it or subsequently alter the "Front page displays" setting.

Fixes #37580
Props JakePT

Note: See TracTickets for help on using tickets.