[wp-trac] [WordPress Trac] #19073: wp_die() can be a wrapper for WP_Error objects, but also triggers if no error is present

[WordPress Trac]

#19073: wp_die() can be a wrapper for WP_Error objects, but also triggers if no
error is present
--------------------------+------------------------------
 Reporter:  F J Kaiser    |       Owner:
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  General       |     Version:  3.3
 Severity:  normal        |  Resolution:
 Keywords:  has-patch     |
--------------------------+------------------------------

Comment (by OoroonBai):

 Replying to [comment:4 F J Kaiser]:
 > First, I'd say if you translate errors, you should also translate the
 error titles.

 In an example some things are different from things you do in practice,
 just to point out the problem. Here we talk about the error-message, not
 the error-title.

 > If you got an incomplete translation and bundle it with your theme, then
 it's your fault as theme developer. You should never bundle unfinished
 parts, else you're before RC, even [...]

 There are many ways why the message can be empty. Translatipon is one way,
 bad written plugins an other.
 Imaging following code in a plugin:

 {{{
 <?php
 /* collecting the vars */
 $e_title = 'Where is it Error';
 $e_message = '';               // Oops!!! Missing something...
 $e_code = 'four-o-four';
 $e_respond = 404;

 /* some other code */

 $error = new WP_error( $e_code, $e_message, array( 'title' => $e_title,
 'respond' => $e_respond ) );

 $some_important_var = false;

 /* some other code */

 if( 'yes, do it' != $some_important_var )
         wp_die( $error );

 /* do some wired things like deleting tables, posts and so on */
 ?>
 }}}
 That's a terrible code. But there are many plugins with terrible code out
 there. Imaging what happend if you simply return if $e_message is not set.
 The plugin would not die without a message, it would delete tables, post
 or something else.
 With the actual code, wp_die() stop the script whether $e_message is set
 or not.

 If wp_die() needs a patch, than set $message to something like "No
 message". But never ever change the expected behavior (stopping the
 script) of wp_die().
 Your actual patch returns nothing. Not true or false or something that can
 be checked. Not even an error is triggered. The script will be continued
 as nothing was happend. Try to debug such a situation, this will be hell
 on earth.

 > Sidenote: You don't have to offer the empty second argument for
 {{{wp_die()}}} and you also don't need to call the error data as 3rd.
 That's the reason why I'm after this: Just drop your error object in and
 you're fine. The rest will be done by wp_die() automatically.

 Try it ;) If you want to send a respond-header, you have to set this with
 the 3rd argument. And you can only set a 3rd argument if you have set an
 (empty) second argument.
 I used the following code to test it (added to the end of my theme
 functions.php). Try the first and the second wp_die(), you will see the
 different output (missing back-link). With firebug you can check the
 respond-header (correct 403/404 with the first, 500 with the second wp-
 die).
 {{{
 $error  = new WP_Error();
 $error->add( 'forbidden', 'Forbidden', array( 'title' => 'Forbidden
 Error', 'response' => '403', 'back_link' => true ) );
 $error->add( 'not_found', 'Not found', array( 'title' => 'Not-Found
 Error', 'response' => '404', 'back_link' => true ) );

  if( is_wp_error( $error ) ){

         //wp_die( $error, '', $error->get_error_data() );
         wp_die( $error );

  }
 }}}
 If you need respond-header which are set in WP_Error(), you have to set
 them explicitly in wp_die() with the 3rd argument.

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/19073#comment:5>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software