Make WordPress Core

Opened 3 months ago

Last modified 3 months ago

#54327 new feature request

Support wp_die from array print

Reported by: myousefi08 Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version: 5.8.1
Component: General Keywords: has-patch needs-testing
Focuses: Cc:

Description

I think wp_die() function is very used in wordpress plugin and theme developement and that is better to support array when pass an array to this and prevent from array to string notice.

in wp-includes/functions.php
line ~3800

before:

echo $message;

after:

if(is_array($message)) {
    print_r($message);
}else {
    echo $message;
}

tanx.

Attachments (2)

54327.diff (524 bytes) - added by sabbirshouvo 3 months ago.
Sounds like a valid proposal to me. Adding a patch.
54327.2.diff (1.5 KB) - added by sabbirshouvo 3 months ago.
update: Added support for all available error handlers

Download all attachments as: .zip

Change History (6)

@sabbirshouvo
3 months ago

Sounds like a valid proposal to me. Adding a patch.

#1 @sabbirshouvo
3 months ago

  • Keywords has-patch needs-testing added

#2 @SergeyBiryukov
3 months ago

Hi there, welcome to WordPress Trac! Thanks for the ticket.

I think the patch might have to be a bit more complex than that, to support all the current wp_die() handlers in core:

  • _default_wp_die_handler()
  • _ajax_wp_die_handler()
  • _json_wp_die_handler()
  • _jsonp_wp_die_handler()
  • _xmlrpc_wp_die_handler()
  • _xml_wp_die_handler()
  • _scalar_wp_die_handler()

I also think we'd want to avoid using print_r() as its output is a bit too technical, and instead update _wp_die_process_input() to use the first item of the array as the main message, and add the rest to $args['additional_errors'], like we already do if $message is a WP_Error object, see lines 4076 and 4088.

#3 @myousefi08
3 months ago

tnx @SergeyBiryukov

Of course, I mean using this method for the developers in plugin or theme development. Because of this, the technicality of the output is not a problem. Rather, my goal in printing arrays or objects is to see their content very quickly. (first element does not help)

Otherwise, I know that from the user's point of view, and for items that are used in printing errors, such as wp_error object, it may create restrictions.

tanx again.

Last edited 3 months ago by myousefi08 (previous) (diff)

#4 @sabbirshouvo
3 months ago

@SergeyBiryukov I took a look into _wp_die_process_input(). I think there is nothing to modify to achieve the proposed result. that mentioned method nicely handling the $message returning as an array. In order to display the user input array, we must print it in some way. I think print_r() is a decent way to print the array. _wp_die_process_input() already checking if it's an error object coming from WordPress itself or not and the $message is always a string unless the user inputs an array as $message.

I agree with you regarding modifying all error handlers.

  • _default_wp_die_handler() : Current patch should work fine. But output can be nicer with <pre></pre>
  • _ajax_wp_die_handler() : Same as _default_wp_die_handler but without <pre></pre>
  • _json_wp_die_handler() : Current code should work just fine
  • _jsonp_wp_die_handler() : Current code should work just fine
  • _xmlrpc_wp_die_handler() : As error output is always string for IXR_Error we can json_encode the $message if is an array.
  • _xml_wp_die_handler() : same solution as _xmlrpc_wp_die_handler
  • _scalar_wp_die_handler() : I couldn't find any use of this handler. I think it's possible to skip this or remove this.

I'll be adding a patch with my update across all handlers.

Last edited 3 months ago by sabbirshouvo (previous) (diff)

@sabbirshouvo
3 months ago

update: Added support for all available error handlers

Note: See TracTickets for help on using tickets.