Make WordPress Core

Opened 3 years ago

Closed 3 months ago

#56686 closed defect (bug) (wontfix)

"internal" post status practical usage?

Reported by: malthert's profile malthert Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version:
Component: Posts, Post Types Keywords:
Focuses: Cc:

Description

https://developer.wordpress.org/reference/functions/register_post_status/

has an "internal" param, however I couldn't find what practical use/meaning this has. What happens if we set "internal" true in practical terms when doing a WP_Query? Does it affect anything else besides WP_Query?

It seems this is legacy and without any practical use? (maybe deprecate and remove?)

Change History (4)

This ticket was mentioned in Slack in #core-test by ironprogrammer. View the logs.


3 years ago

#2 @ironprogrammer
3 years ago

  • Keywords dev-feedback added

Thanks for the ticket, @malthert!

Marking dev-feedback for component/committer input.

#3 @callumbw95
5 months ago

Hi @malthert,
I have done a bit of digging into the code to investigate whether or not this is still in use, and it appears that whilst it is not that useful when developing extended functionality within WordPress, it is still in use in regards to core functionality. For example the internal argument is used for a variety of the out the box statuses including; trash, auto-draft, inherit, request-pending, etc. As of such I don't believe that this argument needs to be deprecated as it is still in use today.
However, past the fact that this is in use within core, I am not actually sure of what benefit this argument has in regards to post statuses. But it might be that it is kept in for parity with other register functions within WordPress?

#4 @mindctrl
3 months ago

  • Keywords dev-feedback removed
  • Resolution set to wontfix
  • Status changed from new to closed

As Callum pointed out, the internal bit is still used internally by WordPress. The is_post_status_viewable() function is but one example. As such, we can't deprecate or remove it without a broader refactor. I'm proposing we close this ticket to help clean up Trac, but feel free to reopen if you disagree.

Note: See TracTickets for help on using tickets.