wp_die() status code global updates (parent ticket)

[callumbw95]

Just detailing an issue that was originally raised back in #12529 where across the code base there are multiple instances of the wp_die() function not including a status code. This causes all of these function calls to be logged as a 500 error. However as this is not always the case, this ticket aims to resolve this historical issue within the codebase by suggesting updated status codes for each request. As there are multiple areas that this will cover, I have broken this down into multiple tickets covering the various components here on trac. As of such I will create tickets covering each of the following areas:

• Media: 4 files - 12 changes
• Menus: 3 files - 4 changes
• Network and Sites: 15 files - 42 changes
• Options: 9 files - 10 changes
• Plugins: 4 files - 14 changes
• Posts, Post Types: 6 files - 20 changes
• REST API: 2 files - 133 changes
• Themes: 3 files - 5 changes
• Upgrade/Install: 3 files - 26 changes
• Users: 4 files - 8 changes

There are also other files I have taken a look through, and I have not categorised into components yet, so will update this ticket once I have them ready.

In regards to each of the tickets created I will be going into a more thorough breakdown of the function usage across each of the files. Also please note this work does not try to change every instance of wp_die(), but those that could benefit from a more apprioriate response code.

Historical tickets related to this issue:

• #12529 - (16 years) Specify a response for more wp_die calls
• #47393 - (6 years) Comment form submission with invalid fields incorrectly returns 200 OK response
• #63836 - (4 weeks) Use more appropriate HTTP status codes for wp_die() calls in wp-admin/post.php

[callumbw95]

Media Component Ticket: 64010

[johnbillion]

I'm generally in favour of these changes.

One thing to note is that if any of the wp_die() calls relate to a private item that exists but is not accessible to the user then the status code must not expose its existence. For example private posts, archived sites on a network, or non-public post types must not return a 403.

[johnjamesjacoby]

+1, agree with @johnbillion

[callumbw95]

Hey all,

Please find an updated list of the child tickets, and their PR's to make this easier to find across Trac. 😃

Component	Trac Ticket	PR
Media	#64010	​9966
Menus	#64011	​9967
Network and Sites	#64021	​9993
Options	#64023	​9994
Plugins	#64024	​9996
Posts, Post Types	#64025	​9997
REST API	#64032	​10015
Themes	#64057	​10096
Upgrade/Install	#64058	​10097
Users	#64059	​10098

I believe I have managed to not expose anything with the status codes as mentioned by @johnbillion but I will need another set of eyes to double check each of these tickets please.

[callumbw95]

Hey all,

In last weeks Core Dev Chat (8th October) it was mentioned that it would be nice to get some of these into the current milestone for 6.9. Slack link ​here.

I believe we are in a good place now with all of the tickets, except the REST API component ticket (#64032) as myself and others are still finalising testing here. Is there anyone who can run through this, perhaps component maintainers, and see if this is something that is ready to be included in the coming release?