Melhor maneira de finalizar o pedido ajax do WordPress e por quê?

Usar wp_die() é a melhor dessas opções.

Como outros já observaram, há muitas razões para preferir uma função específica do WordPress sobre a planície die ou exit :

• Permite que outros plugins se conectem às ações chamadas por wp_die() .
• Permite que um manipulador especial para sair seja usado com base no contexto (o comportamento de wp_die() é personalizado com base no fato de a solicitação ser ou não uma solicitação Ajax).
• Torna possível testar seu código.

O último é mais importante, e é por isso que adicionei essa nota a o Codex . Se você quiser criar testes de unidade / integração para o seu código, você não poderá testar um função que chama exit ou die diretamente. Ele irá terminar o script, como é suposto. A maneira como os próprios testes do WordPress são configurados para evitar isso (para os retornos de chamada do Ajax para os quais ele tem testes) é ligar as ações acionadas por wp_die() e lançar uma exceção. Isso permite que a exceção seja capturada dentro do teste e a saída do retorno de chamada (se houver) seja analisada.

A única vez que você usaria die ou exit é se você quiser ignorar qualquer manipulação especial de wp_die() e anular a execução imediatamente. Existem alguns lugares onde o WordPress faz isso (e outros lugares onde ele pode usar die diretamente apenas porque a manipulação de wp_die() não é importante, ou ninguém tentou criar testes para um pedaço de código ainda, então foi ignorado ). Lembre-se de que isso também torna seu código mais difícil de testar, de modo que geralmente seria usado apenas em código que não está em um corpo de função (como o WordPress faz em admin-ajax.php ). Portanto, se a manipulação de wp_die() não for especificamente desejada, ou se você estiver matando o script em um determinado ponto como precaução (como admin-ajax.php , esperando que normalmente um retorno de chamada do Ajax já tenha saído corretamente), é possível considerar usando die diretamente.

Em termos de wp_die() vs wp_die( 0 ) , o que você deve usar depende do que está lidando com a resposta da solicitação do Ajax no front end. Se estiver esperando um corpo de resposta específico, você precisará passar essa mensagem (ou inteiro, nesse caso) para wp_die() . Se tudo o que estiver ouvindo for a resposta ser bem-sucedida ( 200 response code ou qualquer outra coisa), não será necessário passar nada para wp_die() . Gostaria de observar, porém, que terminar com wp_die( 0 ) tornaria a resposta indistinguível da resposta admin-ajax.php padrão. Então, terminar com 0 não informa se o seu retorno de chamada foi conectado corretamente e, na verdade, foi executado. Uma mensagem diferente seria melhor.

Como apontado em outras respostas, você encontrará frequentemente wp_send_json() et al. para ser útil se você estiver enviando uma resposta JSON de volta, o que geralmente é uma boa ideia. Isso também é superior a apenas chamar wp_die() com um código, porque você pode passar muito mais informações em um objeto JSON, se necessário. Usar wp_send_json_success() e wp_send_json_error() também enviará a mensagem de sucesso / erro de volta em um formato padrão que qualquer função auxiliar JS Ajax fornecida pelo WordPress entenderá (como wp.ajax ).

TL; DR: Provavelmente você sempre deve usar wp_die() , seja em um retorno de chamada do Ajax ou não. Melhor ainda, envie informações com wp_send_json() e amigos.

Do códice AJAX em plugins

add_action( 'wp_ajax_my_action', 'my_action_callback' );

function my_action_callback() {
    global $wpdb; // this is how you get access to the database

    $whatever = intval( $_POST['whatever'] );

    $whatever += 10;

        echo $whatever;

    wp_die(); // this is required to terminate immediately and return a proper response
}

  

Observe o uso de wp_die() , em vez de die() ou exit() . A maioria dos   hora em que você deve usar wp_die() em sua função de retorno de chamada do Ajax. este   fornece melhor integração com o WordPress e facilita o teste   seu código.

Você também pode usar wp_send_json() descrito no Codex como send a JSON response back to an AJAX request, and die().

Então, se você tiver que devolver um array, você só terminará sua função com wp_send_json($array_with_values); . Não é necessário echo ou die .

Você também recebe duas funções auxiliares de ajuda wp_send_json_success() e wp_send_json_error() que adiciona uma chave chamada success , que será true ou false , respectivamente.

Por exemplo:

$array_val = range( 1,10 );
var_dump( wp_send_json_error( $array_val ) ); # Output: {"success":false,"data":[1,2,3,4,5,6,7,8,9,10]}
echo 'Hey there'; # Not executed because already died.

Isto é apenas em adição ao que os outros disseram. O motivo para preferir wp_die é que o núcleo pode acionar ações lá e os plugins podem concluir adequadamente coisas como rastreamento, monitoramento ou armazenamento em cache.

Em geral, você deve sempre preferir uma chamada de API básica, se disponível, já que é mais provável que adicione algum valor (cache, integração de plug-in ou qualquer outro) que você não recebe da chamada direta do PHP.

Para usar o wordpress ajax / woo commerce, a sintaxe geral do ajax é a seguinte:

add_action( 'wp_ajax_my_action', 'my_action_callback' );
add_action( 'wp_ajax_nopriv_my_action', 'my_action_callback' );
function my_action_callback()
{
// your code goes here

wp_die();

}

Você deve usar wp_die () no final da função. Porque o wordpress usa internamente um filtro durante a função wp_die (). Portanto, qualquer plugin que esteja trabalhando com esse filtro pode não funcionar se não inclua o wp_die (). Também die () e outras funções são imediatamente matar a execução do PHP sem considerar qualquer função wordpress que deva ser considerada durante o término da execução.

Se você estiver usando o wp_send_json () dentro de você, faça uma função como essa

       function my_action_callback()
    {
    // your code goes here

      wp_send_json();

    //wp_die(); not necessary to use wp_die();

    }

Não é necessário usar wp_die () no final se você incluir wp_send_json () dentro da função de retorno de chamada . porque o próprio wordpress usa a função wp_die () com segurança dentro da função wp_send_json ().

Eu não vou aceitar essa resposta, isso não seria justo. Eu só queria criar um esboço e possíveis dicas sobre os itens que considero importantes:

A principal definição de wp-die ()

File: wp-includes/functions.php
2607: /**
2608:  * Kill WordPress execution and display HTML message with error message.
2609:  *
2610:  * This function complements the 'die()' PHP function. The difference is that
2611:  * HTML will be displayed to the user. It is recommended to use this function
2612:  * only when the execution should not continue any further. It is not recommended
2613:  * to call this function very often, and try to handle as many errors as possible
2614:  * silently or more gracefully.
2615:  *
2616:  * As a shorthand, the desired HTTP response code may be passed as an integer to
2617:  * the '$title' parameter (the default title would apply) or the '$args' parameter.
2618:  *
2619:  * @since 2.0.4
2620:  * @since 4.1.0 The '$title' and '$args' parameters were changed to optionally accept
2621:  *              an integer to be used as the response code.
2622:  *
2623:  * @param string|WP_Error  $message Optional. Error message. If this is a WP_Error object,
2624:  *                                  and not an Ajax or XML-RPC request, the error's messages are used.
2625:  *                                  Default empty.
2626:  * @param string|int       $title   Optional. Error title. If '$message' is a 'WP_Error' object,
2627:  *                                  error data with the key 'title' may be used to specify the title.
2628:  *                                  If '$title' is an integer, then it is treated as the response
2629:  *                                  code. Default empty.
2630:  * @param string|array|int $args {
2631:  *     Optional. Arguments to control behavior. If '$args' is an integer, then it is treated
2632:  *     as the response code. Default empty array.
2633:  *
2634:  *     @type int    $response       The HTTP response code. Default 200 for Ajax requests, 500 otherwise.
2635:  *     @type bool   $back_link      Whether to include a link to go back. Default false.
2636:  *     @type string $text_direction The text direction. This is only useful internally, when WordPress
2637:  *                                  is still loading and the site's locale is not set up yet. Accepts 'rtl'.
2638:  *                                  Default is the value of is_rtl().
2639:  * }
2640:  */
2641: function wp_die( $message = '', $title = '', $args = array() ) {
2642: 
2643:   if ( is_int( $args ) ) {
2644:       $args = array( 'response' => $args );
2645:   } elseif ( is_int( $title ) ) {
2646:       $args  = array( 'response' => $title );
2647:       $title = '';
2648:   }
2649: 
2650:   if ( wp_doing_ajax() ) {
2651:       /**
2652:        * Filters the callback for killing WordPress execution for Ajax requests.
2653:        *
2654:        * @since 3.4.0
2655:        *
2656:        * @param callable $function Callback function name.
2657:        */
2658:       $function = apply_filters( 'wp_die_ajax_handler', '_ajax_wp_die_handler' );
2659:   } elseif ( defined( 'XMLRPC_REQUEST' ) && XMLRPC_REQUEST ) {
2660:       /**
2661:        * Filters the callback for killing WordPress execution for XML-RPC requests.
2662:        *
2663:        * @since 3.4.0
2664:        *
2665:        * @param callable $function Callback function name.
2666:        */
2667:       $function = apply_filters( 'wp_die_xmlrpc_handler', '_xmlrpc_wp_die_handler' );
2668:   } else {
2669:       /**
2670:        * Filters the callback for killing WordPress execution for all non-Ajax, non-XML-RPC requests.
2671:        *
2672:        * @since 3.0.0
2673:        *
2674:        * @param callable $function Callback function name.
2675:        */
2676:       $function = apply_filters( 'wp_die_handler', '_default_wp_die_handler' );
2677:   }
2678: 
2679:   call_user_func( $function, $message, $title, $args );
2680: }

wp_send_json

File: wp-includes/functions.php
3144: /**
3145:  * Send a JSON response back to an Ajax request.
3146:  *
3147:  * @since 3.5.0
3148:  * @since 4.7.0 The '$status_code' parameter was added.
3149:  *
3150:  * @param mixed $response    Variable (usually an array or object) to encode as JSON,
3151:  *                           then print and die.
3152:  * @param int   $status_code The HTTP status code to output.
3153:  */
3154: function wp_send_json( $response, $status_code = null ) {
3155:   @header( 'Content-Type: application/json; charset=' . get_option( 'blog_charset' ) );
3156:   if ( null !== $status_code ) {
3157:       status_header( $status_code );
3158:   }
3159:   echo wp_json_encode( $response );
3160: 
3161:   if ( wp_doing_ajax() ) {
3162:       wp_die( '', '', array(
3163:           'response' => null,
3164:       ) );
3165:   } else {
3166:       die;
3167:   }
3168: }

wp_doing_ajax

File: wp-includes/load.php
1044: /**
1045:  * Determines whether the current request is a WordPress Ajax request.
1046:  *
1047:  * @since 4.7.0
1048:  *
1049:  * @return bool True if it's a WordPress Ajax request, false otherwise.
1050:  */
1051: function wp_doing_ajax() {
1052:   /**
1053:    * Filters whether the current request is a WordPress Ajax request.
1054:    *
1055:    * @since 4.7.0
1056:    *
1057:    * @param bool $wp_doing_ajax Whether the current request is a WordPress Ajax request.
1058:    */
1059:   return apply_filters( 'wp_doing_ajax', defined( 'DOING_AJAX' ) && DOING_AJAX );
1060: }

Normalmente, o que recebemos da chamada ajax é algum tipo de resposta. A resposta pode ser codificada em json ou não pode ser codificada em json.

No caso de precisarmos de json outupt wp_send_json ou dois satelites são ótimas ideias.

No entanto, podemos retornar x-www-form-urlencoded ou multipart/form-data ou text/xml ou qualquer outro tipo de codificação. Nesse caso, não usamos wp_send_json .

Podemos retornar todo o html e, nesse caso, é bom usar wp_die() primeiro e segundo parâmetro, senão esses parâmetros devem estar vazios.

 wp_die( '', '', array(
      'response' => null,
 ) );

Mas qual é a vantagem de chamar wp_die() sem parâmetros?

Finalmente, se você verificar o ótimo núcleo do WP você pode encontrar

File: wp-includes/class-wp-ajax-response.php
139:    /**
140:     * Display XML formatted responses.
141:     *
142:     * Sets the content type header to text/xml.
143:     *
144:     * @since 2.1.0
145:     */
146:    public function send() {
147:        header( 'Content-Type: text/xml; charset=' . get_option( 'blog_charset' ) );
148:        echo "<?xml version='1.0' encoding='" . get_option( 'blog_charset' ) . "' standalone='yes'?><wp_ajax>";
149:        foreach ( (array) $this->responses as $response )
150:            echo $response;
151:        echo '</wp_ajax>';
152:        if ( wp_doing_ajax() )
153:            wp_die();
154:        else
155:            die();

Ambos os formatos são usados die() e wp_die() . Você pode explicar por quê?

Finalmente, aqui está o que admin-ajax.php retorna die( '0' );

Por que não wp_die(...) ?

Use wp_die() . É melhor usar as funções do WordPress o máximo que puder.

Se você usar echo , ele será forçado a usar die() ou die(0) ou wp_die() .

Se você não usa echo , o JavaScript pode lidar com isso.

Então você deve usar uma maneira melhor de retornar dados: wp_send_json() .

Para enviar dados em seu retorno de chamada (em json format), você pode usar os seguintes itens:

wp_send_json()

wp_send_json_success()

wp_send_json_error()

Todos eles morrerão por você. Não há necessidade de sair ou morrer depois.

UPDATE

E se você não precisar de json como formato de saída, use:

wp_die($response)

Ele retornará sua resposta antes que ela morra. De acordo com o códice:

  

A função wp_die() foi projetada para fornecer saída antes de morrer   para evitar respostas vazias ou time-outing.

Por favor, leia o artigo completo sobre codex aqui .