wp_die() handler for admin-post.php

[danielbachhuber]

Similar to how admin-ajax.php has _ajax_wp_die_handler, it would be nice if admin-post.phphad a custom wp_die() handler for errors.

[nacin]

This was done specifically so our AJAX methods would become testable. What would be the benefit to admin-post.php? Same?

[danielbachhuber]

For me, use wp_die() as an error handler with admin-post.

[paulschreiber]

I looked in admin-ajax.php but couldn't find any handlers. The only place I found _ajax_wp_die_handler was in class-wp-customize-manager.php.

[prasoon2211]

I was taking a look at this ticket and found out that the _ajax_wp_die_handler has moved to wp-includes/functions.php.

[foack]

Following the basic tutorial on ​https://codex.wordpress.org/Plugin_API/Action_Reference/admin_post_(action) and replacing the die() in the example with wp_die(), the wp_die() function triggers _ajax_wp_die_handler located in wp-includes/functions.php.

I'm new in contributing to WP Core but from my perspective, it would not be necessary to extend admin_post.php. If we were to, we'd at least need to avoid redeclaring _ajax_wp_die_handler().

[desrosj]

It's been 8 years since an owner was assigned to this one.

I'm going to reset that field to encourage new folks to take lead.

admin-post.diff​ does not look like the correct solution as it seems to copy _ajax_wp_die_handler() over to admin-post.php. The correct "die handler" to use is determined within wp_die() beased on the type of request being made.

Adds a condition to wp_die() to identify when it is being called in response to an admin-post.php request and a filter for hooking a custom handler.

Trac ticket: https://core.trac.wordpress.org/ticket/27671

[ajfleming]

I edited wp_die() to add a condition for admin-post.php requests and a filter to hook a custom handler. PR ​#4101 contains the changes.

I reused the existing _default_wp_die_handler as the filter value because it seemed an appropriate default response in this situation. Is there a specific response we need in this situation that means we should also write a handler?

We could also argue that a similar outcome could be achieved without this change by hooking _default_wp_die_handler and identifying the admin-post.php requests in the callback. Is the use case for this strong enough to make this change to WordPress core?

[azaozz]

Replying to desrosj:

It's been 8 years since...

Old tickets are old usually for a good reason. Many seem fixed elsewhere or not relevant any more. Others seem to fall into the category of "perhaps maybe probably a good idea, but... too little interest for too many years".

similar outcome could be achieved without this change by hooking _default_wp_die_handler and identifying the admin-post.php requests in the callback.

Yep, think this is the expected use of that filter, and it solves this case too.

[danielbachhuber]

Lesson to self: it's useful to share context when you open a ticket. Otherwise, you may have no idea why it was opened when you look at it again 9 years later.

I don't think this is worth fixing without a explicit need for it.