[wp-trac] [WordPress Trac] #63836: Use more appropriate HTTP status codes for wp_die

[WordPress Trac]

#63836: Use more appropriate HTTP status codes for wp_die
-------------------------------------+------------------------------
 Reporter:  kkmuffme                 |       Owner:  (none)
     Type:  defect (bug)             |      Status:  new
 Priority:  normal                   |   Milestone:  Awaiting Review
Component:  General                  |     Version:
 Severity:  minor                    |  Resolution:
 Keywords:  needs-patch 2nd-opinion  |     Focuses:
-------------------------------------+------------------------------
Changes (by callumbw95):

 * keywords:  needs-patch => needs-patch 2nd-opinion


Comment:

 Hi @kkmuffme,

 I have just taken a look into this, and it looks as though the `wp_die()`
 function is already equipped to handle an HTTP status code, either as a
 standalone integer or within the `$args` array:

 - `wp_die( 'message', 'title', 404 );`
 - `wp_die( 'message', 'title', [ 'response' => 404 ] );`

 As it stands, wp_die() uses this response value to call `status_header()`
 before the die handler is ever invoked. You can see this in
 [https://github.com/WordPress/wordpress-
 develop/blob/a1d3ddb1d6ba991aaa28ec6534b505009bb8fb72/src/wp-
 includes/functions.php#L3883 src/wp-includes/functions.php:line 4032]. The
 problem isn't that `wp_die()` ignores the code, but rather that the vast
 majority of calls to this function throughout the core codebase don't
 provide a specific code, causing it to fall back to the default 500.

 I propose the following routes to getting this issue resolved. I also
 think that the best solution here may be a combination of the two
 approaches:

 - **Comprehensive Core Audit**: We should systematically review the
 existing calls to wp_die() and update them to include the appropriate HTTP
 status code. As you noted, with nearly 700 instances across the codebase,
 this is a significant undertaking. We could prioritize the most common or
 critical instances first (e.g., those related to permissions, non-existent
 posts, or database errors).

 - **Intelligent Status Code Inference**: As a powerful fallback and for
 backward compatibility, we could enhance `wp_die()` with logic to infer a
 status code from the message string when one isn't explicitly provided.
 For example, checking for "not found" in the passed message and setting
 the status to 404. This would immediately improve responses for countless
 existing calls in core, themes, and plugins without requiring them all to
 be updated.

 Combining these two strategies would give us the best of both worlds:
 precision from the manual audit and broad, immediate improvement from the
 inference logic. This would be a fantastic step toward providing more
 meaningful and logical response codes for developers and site
 administrators.

 I would love to hear feedback from the community on this, and if we are
 happy with this plan of attack, I am happy to do an audit of `wp_die()`
 use across core. 😃

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/63836#comment:2>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform