Make WordPress Core

Opened 9 years ago

Closed 3 months ago

Last modified 3 months ago

#27671 closed enhancement (wontfix)

wp_die() handler for admin-post.php

Reported by: danielbachhuber's profile danielbachhuber Owned by:
Milestone: Priority: normal
Severity: normal Version:
Component: Administration Keywords:
Focuses: Cc:


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.

Attachments (1)

admin-post.diff (964 bytes) - added by gorantq 7 years ago.

Download all attachments as: .zip

Change History (13)

#1 @nacin
9 years ago

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

#2 @danielbachhuber
9 years ago

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

#3 @paulschreiber
9 years ago

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.

#4 @johnbillion
9 years ago

  • Owner set to whyisjake
  • Status changed from new to assigned

#5 @prasoon2211
8 years ago

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

7 years ago

#6 @gorantq
7 years ago

  • Keywords has-patch needs-testing added; needs-patch removed

#7 @foack
4 years ago

Following the basic tutorial on 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().

#8 follow-up: @desrosj
7 months ago

  • Keywords needs-patch added; has-patch needs-testing removed
  • Milestone set to Awaiting Review
  • Owner whyisjake deleted

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.

This ticket was mentioned in PR #4101 on WordPress/wordpress-develop by @ajfleming.

4 months ago

  • Keywords has-patch added; needs-patch removed

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:

#10 @ajfleming
4 months ago

  • Keywords needs-patch added; has-patch removed

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?

#11 in reply to: ↑ 8 @azaozz
4 months ago

  • Keywords close added; good-first-bug removed

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.

#12 @danielbachhuber
3 months ago

  • Keywords needs-patch close removed
  • Milestone Awaiting Review deleted
  • Resolution set to wontfix
  • Status changed from assigned to closed

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.

Last edited 3 months ago by danielbachhuber (previous) (diff)
Note: See TracTickets for help on using tickets.