Opened 8 years ago
Last modified 3 months ago
#40197 reviewing defect (bug)
meta cap 'publish_post' is not being used
Reported by: |
|
Owned by: |
|
---|---|---|---|
Milestone: | Awaiting Review | Priority: | normal |
Severity: | normal | Version: | 3.5 |
Component: | Role/Capability | Keywords: | good-first-bug has-patch needs-refresh |
Focuses: | administration | Cc: |
Description
#21288 adds publish_post to meta cap but it is not being called anywhere. I tried to log it using map_meta_cap at the post edit page. There is only publish_posts called but not publish_post
Change History (11)
#3
@
8 years ago
Hi @swissspidy
I am suggesting that core should implement publish_post where possible since all other meta cap variables are used correctly.
I was working on an advanced role/capability system that allow specific group of users to have edit/publish access based on page's root ancestor. I still cannot find any workaround on this. Advices are thankfully welcomed.
This ticket was mentioned in PR #810 on WordPress/wordpress-develop by carlomanf.
4 years ago
#6
- Keywords has-patch added; needs-patch removed
Trac ticket: https://core.trac.wordpress.org/ticket/40197
#7
follow-up:
↓ 8
@
4 years ago
Here is a patch. All four post type meta capabilities are now handled through the same code block, since there was a lot of code being duplicated verbatim between them. The patch moves this to the bottom of the switch block, purely to avoid a messy diff.
The patch attempts to preserve the existing behaviour as much as possible, with two exceptions:
- Fixed an error that was accessing non-existent
edit_page
,delete_page
andread_page
properties on the post type capabilities object, nowedit_post
,delete_post
,read_post
andpublish_post
are accessed instead.
- The
publish_post
meta capability now respects$args['map_meta_cap'] = false
and does not map, previously it was mapping anyway.
As far as changing publish_posts
to publish_post
, the patch changes it wherever there is a readily available post reference. I verified that this successfully changes the behaviour on the post editor. Some cases, however, (such as the Quick Edit) appear to require a deeper re-tooling to support this meta capability, which this patch does not attempt.
#8
in reply to:
↑ 7
@
4 years ago
- The
publish_post
meta capability now respects$args['map_meta_cap'] = false
and does not map, previously it was mapping anyway.
I would guess that last unit test is failing because of this? If a post type has $args['map_meta_cap'] = false
then it should be responsible to map publish_post
. Obviously this risks breaking many post types, but I would say they are taking on that risk by setting $args['map_meta_cap'] = false
.
This ticket was mentioned in Slack in #meta by joyously. View the logs.
4 years ago
#11
@
3 months ago
- Keywords needs-refresh added
One big benefit of changing this would be that you can filter the meta cap, and conditionally allow/deny publication based on the post's content - e.g. you could block publish at the caps level if a condition isn't met. This isn't possible with the generic publish_posts
cap, which is missing the context.
I suspect this patch probably needs refreshing, and we need to check that there haven't been any new uses introduced (e.g. for Gutenberg).
Hey there,
Would you suggest using the publish_post meta cap where possible or removing it? Because just because core isn't using this capability doesn't mean plugins won't.