WordPress.org

Make WordPress Core

Opened 6 years ago

Last modified 7 weeks ago

#24722 reopened defect (bug)

get_post_statuses() and get_page_statuses() are hardcoded

Reported by: rmccue Owned by: chriscct7
Milestone: Awaiting Review Priority: normal
Severity: normal Version:
Component: Posts, Post Types Keywords: has-patch, needs-refresh, bulk-reopened
Focuses: Cc:

Description

Despite the support for registering custom post/page statuses in core, both get_post_statuses() and get_page_statuses() are hardcoded.

Both of these functions are only used in the XML-RPC API in core, however this may affect plugins.

(Somewhat related to the editorial-flow component, although that's on hiatus at the moment.)

Attachments (2)

24722-full.diff (1.8 KB) - added by nerrad 6 years ago.
make sure get_post_statuses() includes registered post stati
24722.diff (717 bytes) - added by wonderboymusic 4 years ago.

Download all attachments as: .zip

Change History (13)

@nerrad
6 years ago

make sure get_post_statuses() includes registered post stati

#1 follow-up: @sillybean
6 years ago

Would it make sense to turn these into wrappers for get_post_stati()?

#2 @nerrad
6 years ago

See patch above. I didn't do the same thing for get_page_statuses() because it looked like from the code that page statuses are supposed to be a different list from post_statuses and currently there is no way to filter the post status by post_type because post type is NOT considered in registering post status.

#3 in reply to: ↑ 1 @nerrad
6 years ago

Replying to sillybean:

Would it make sense to turn these into wrappers for get_post_stati()?

No, because get_post_stati() return a filtered list of objects. right now get_post_statuses() returns an array indexed in status->name/status->label pairs and any client code using the function would expect the same. I still use the $wp_post_statuses global however, and created a helper function to spit out an array setup in the format using get_post_statuses() currently expects.

#4 @nerrad
6 years ago

  • Keywords has-patch added

#5 @nofearinc
6 years ago

  • Cc mario@… added

#6 @sillybean
6 years ago

  • Cc steph@… added

#8 @chriscct7
4 years ago

  • Keywords needs-refresh added; editorial-flow removed
  • Milestone changed from Future Release to 4.4
  • Owner set to chriscct7
  • Severity changed from minor to normal
  • Status changed from new to assigned

@wonderboymusic
4 years ago

#9 @wonderboymusic
4 years ago

  • Milestone changed from 4.4 to Future Release

24722.diff returns a map of non-internal statuses, but I'm not sure how useful this is. Without being able to associate object types to statuses, this is a very incomplete API.

#10 @iseulde
4 months ago

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

This ticket has not seen any activity in over *two* years, so I'm closing it as "wontfix".

The ticket may lack decisiveness, may have become irrelevant, or may not have gathered enough interest.

If you think this ticket does deserve some attention again, feel free to reopen.

For bugs, it would be great if you could provide updated steps to reproduce against the latest version of WordPress (5.0.2 at the time of writing). Remember images or a video can be superior to explain a problem. At the very least, quickly test again to make sure the bug still exists.

If it’s an enhancement or feature, some extra motivation may help.

Thank you for your contributions to WordPress! <3

#11 @JeffPaul
7 weeks ago

  • Keywords bulk-reopened added
  • Milestone set to Awaiting Review
  • Resolution wontfix deleted
  • Status changed from closed to reopened

A decision was made to reopen tickets that were closed in the bulk edit that this ticket was affected by. This ticket is being placed back into the Awaiting Review milestone so it can be individually evaluated and verified to determine if it is still relevant/valid or reproducible.

Note: See TracTickets for help on using tickets.