WordPress.org

Make WordPress Core

Opened 5 years ago

Closed 12 months ago

#17253 closed feature request (wontfix)

Author role should be able to make/edit pages (a.k.a. let's get with the times)

Reported by: jane Owned by: johnbillion
Milestone: Priority: normal
Severity: normal Version: 3.1
Component: Role/Capability Keywords: has-patch needs-refresh dev-feedback
Focuses: Cc:

Description

More and more sites are using WordPress to run the whole site, not just a blog. Pages are quickly eclipsing blog posts as the default content type, and we should start moving to address this. Currently authors have no rights to pages. Someone with higher rights can set the author as someone with the author role, but the author can't actually get to it. This is super lame, because the "just create and manage your own stuff" role doesn't apply to a major form of content.

I understand this will have implications re backwards compatibility, but we've talked about revisiting the roles system at some point, so I wanted this ticket to be on record. We have to make roles more reasonable for CMS use.

Attachments (5)

17253.diff (745 bytes) - added by knutsp 17 months ago.
Patch to add capabilities for authors vs. pages
capabilities.php (27.9 KB) - added by knutsp 17 months ago.
Test that new authors get new capabilities
capabilities.2.php (27.9 KB) - added by knutsp 17 months ago.
Test that new authors get new capabilities
test-author-capabilities.diff (811 bytes) - added by knutsp 17 months ago.
Test that new authors get new capabilities
17253-2.diff (3.4 KB) - added by knutsp 17 months ago.
Patch to add capabilities for authors vs. pages, including tests

Download all attachments as: .zip

Change History (28)

#1 @jane
5 years ago

  • Milestone changed from Awaiting Review to Future Release

Bump... I forgot we never got to this.

#2 @bootsz
4 years ago

  • Cc sbutze@… added

+1

#3 @chriscct7
17 months ago

  • Keywords dev-feedback added

Any of the other devs have thoughts on this?

#4 follow-up: @helen
17 months ago

I am not sure that this is really doable at this point. What would then separate an author from an editor? Surprisingly, there's not much activity here, so should we really bother?

#5 @voldemortensen
17 months ago

+1 for closing. If some is important enough to create pages on a site, they should also be competent enough to be trusted with the other caps that come with being promoted to editor. i.e. moderate_comments and unfiltered_html.

#6 follow-up: @johnbillion
17 months ago

  • Milestone Future Release deleted
  • Resolution set to wontfix
  • Status changed from new to closed

Yeah the gain here is very little, and we'd run into issues with sites which need strict control over which users can access what when suddenly authors can edit pages.

#7 in reply to: ↑ 4 @knutsp
17 months ago

Replying to helen:

I am not sure that this is really doable at this point. What would then separate an author from an editor?

Remember: An editor may edit and publish any content, at least any post or page, even those not created by the actual editor. An author may only create, edit and publish own content. Even if authors are made able to create, edit and publish own pages, they will not have the ability to touch others pages. That's a huge difference.

#8 in reply to: ↑ 6 @knutsp
17 months ago

  • Resolution wontfix deleted
  • Status changed from closed to reopened

Replying to johnbillion:

we'd run into issues with sites which need strict control over which users can access what when suddenly authors can edit pages.

That will not happen. Since authors will not have authored any pages they will not be able to edit any, until they create one themselves.

edit_others_pages, edit_private_pages, delete_others_pages, read_private_pages, delete_private_pages caps should still be off for authors, while edit_pages, publish_pages, edit_published_pages, delete_pages, delete_published_pages caps should be on, the way it is for posts.

I have client's sites where I have made these changes using a caps/role manager plugin, to let the site admin avoid upgrading authors to editors, while letting them mange their own pages. There is no sudden access for the authors to edit anything else.

I'm for this change.

As I feel this ticket was closed on reasons not addressing what this ticket actually suggests, I would like it to stay open until reconsidered.

#9 @johnbillion
17 months ago

  • Keywords needs-patch needs-unit-tests added; dev-feedback removed
  • Milestone set to Awaiting Review

Fair point. Willing to consider it. Needs a patch and tests.

@knutsp
17 months ago

Patch to add capabilities for authors vs. pages

#10 @knutsp
17 months ago

  • Keywords has-patch added; needs-patch removed

@johnbillion: Thank you.

Will it be sufficient just to extend tests/user/capabilities.php with checks that show a new author user gets the right caps added, or do we need further testing on an author manipulating actual pages?

@knutsp
17 months ago

Test that new authors get new capabilities

@knutsp
17 months ago

Test that new authors get new capabilities

#11 @knutsp
17 months ago

Disregard the first capabilities.php.

Is this (capabilities-2.php) even close to be sufficient testing?

#12 @johnbillion
17 months ago

Those cap checks are fine. You should be able to extend the existing test_user_author() method though, rather than introducing a new method. I've just opened #32394 after seeing the state of these tests, so there'll be some overlap there.

Also you can create a patch file for the unit test files in the same way you create a normal patch (no need to upload the whole modified file).

#13 follow-up: @johnbillion
17 months ago

You'll need to update the author assertions in test_page_meta_caps() too.

@knutsp
17 months ago

Test that new authors get new capabilities

#14 @knutsp
17 months ago

  • Keywords needs-unit-tests removed

Ok.

@knutsp
17 months ago

Patch to add capabilities for authors vs. pages, including tests

#15 in reply to: ↑ 13 @knutsp
17 months ago

Replying to johnbillion:

You'll need to update the author assertions in test_page_meta_caps() too.

Done.

Note to self: An author can publish any non-private post, and after this also any non-private page. Private posts/pages may be used to hide them from non-admins/non-editors.

#16 @wonderboymusic
13 months ago

  • Keywords needs-refresh added
  • Milestone changed from Awaiting Review to 4.4
  • Owner set to johnbillion
  • Status changed from reopened to assigned

I'd be willing to look at a version of this

#17 @johnbillion
12 months ago

  • Status changed from assigned to reviewing

#18 follow-up: @helen
12 months ago

Is this going to cause side effects for custom post types that have a capability_type of page?

#19 in reply to: ↑ 18 @johnbillion
12 months ago

Replying to helen:

Is this going to cause side effects for custom post types that have a capability_type of page?

Yes.

#20 @johnbillion
12 months ago

In 34447:

Implement a test for capabilities for a custom post type that uses capability_type => page.

See #17253

#21 @johnbillion
12 months ago

  • Keywords dev-feedback added

[34447] adds a test for the above. I think that probably blocks this change from happening. Thoughts?

#22 @jorbin
12 months ago

I have to say I really don't like the idea of adding existing capabilities to existing roles as a part of the upgrade. The roles API is documented well and there are multiple plugins for adding a UI to the api. Sites that want authors to edit pages, can do that. The side effect of affecting custom post types with capability_type => page is an additional reason not to make this change.

The default roles are in some ways a contract with our users. Users expect that Authors have X capabilities and Editors have Y capabilities (which includes all of X). We would break user trust by moving capabilities into a role that users don't expect. Even if the role should have had this capability, this is one of those things we are kind of stuck with.

#23 @helen
12 months ago

  • Milestone 4.4 deleted
  • Resolution set to wontfix
  • Status changed from reviewing to closed

Pretty much stuck at this point as far as I can see. We were probably already stuck when this ticket was opened, since the CPT API had been around for a year and a half at the time (came in 2.9, not 3.0 like is oft-repeated).

Note: See TracTickets for help on using tickets.