Affichage des erreurs du crochet Save_Post dans WordPress

Manipulation et affichage des erreurs du wordpress save_post crochet: trois approches

WordPress n'a pas une méthode unique et standardisée pour gérer et afficher des erreurs provenant du crochet save_post. Cependant, plusieurs stratégies efficaces existent, chacune avec ses propres forces et faiblesses. Cet article explore trois approches proéminentes: en utilisant les transitoires WordPress $_SESSION Global, en tirant parti des transitoires et en utilisant des paramètres dans les redirections.

La complexité découle de la redirection post-sauvage de WordPress. Après l'exécution du crochet save_post, l'utilisateur est redirigé, brisant le thread d'exécution et perdant l'accès aux variables globales. Par conséquent, un mécanisme est nécessaire pour transférer les informations d'erreur de l'action de sauvegarde vers la page redirigée.

Méthode 1: Utilisation du $_SESSION global

Cette méthode simple stocke le message d'erreur dans la variable globale $_SESSION. Il est simple d'implémenter et d'éviter l'interaction de la base de données.

• Implémentation:

if ( !session_id() ) {
    session_start();
}

if ($error) {
    $_SESSION['my_plugin_errors'] = $error->get_error_message();
}

// ...in admin_notices hook...
add_action( 'admin_notices', 'my_error_message' );
function my_error_message() {
    if ( isset( $_SESSION['my_plugin_errors'] ) ) {
        ?>
        <div class="error">
            <p><?php echo $_SESSION['my_plugin_errors']; ?></p>
        </div>
        <?php
        unset( $_SESSION['my_plugin_errors'] );
    }
}

• PROS: Implémentation facile, pas de surcharge de base de données.
• contre: pas une pratique WordPress standard; s'appuie sur la gestion de la session, qui peut ne pas être systématiquement activée sur toutes les configurations.

Méthode 2: Utilisation des transitoires WordPress

Les transitoires

fournissent un mécanisme de mise en cache-wordpress-natif. Ils stockent des données avec un temps d'expiration, en utilisant le cache d'objet s'ils sont disponibles, ou se retournant dans la base de données.

• Implémentation:

if ($error) {
    set_transient("my_save_post_errors_{$post_id}_{$user_id}", $error, 45);
}

// ...in admin_notices hook...
add_action( 'admin_notices', 'my_error_message' );
function my_error_message() {
    if ( $error = get_transient( "my_save_post_errors_{$post_id}_{$user_id}" ) ) {
        ?>
        <div class="error">
            <p><?php echo $error->get_error_message(); ?></p>
        </div>
        <?php
        delete_transient("my_save_post_errors_{$post_id}_{$user_id}");
    }
}

• PROS: WordPress, nettoyage automatique des données expirées.
• CONS: Interaction de la base de données Si un cache d'objet n'est pas configuré; Perte de données potentielle dans les cas de bord.

Méthode 3: Ajouter un paramètre Get à l'URL de redirection

Cela reflète la propre approche de WordPress pour afficher les messages de mise à jour. Le code d'erreur est ajouté en tant que paramètre de requête à l'URL de redirection

• Implémentation:

if ($error) {
    add_filter('redirect_post_location', function( $location ) use ( $error ) {
        return add_query_arg( 'my-plugin-error', $error->get_error_code(), $location );
    });
}

// ...in admin_notices hook...
add_action( 'admin_notices', 'my_error_message' );
function my_error_message() {
    if ( isset( $_GET['my-plugin-error'] ) ) {
        // Handle error based on error code (switch statement)
        ?>
        <div class="error">
            <p><?php  // Display error message based on $_GET['my-plugin-error'] ?></p>
        </div>
        <?php
    }
}

• PROS: hautes performances, pas d'accès à la base de données.
• contre: nécessite des messages d'erreur de duplication; Les frais généraux de maintenance peuvent augmenter avec un grand nombre de codes d'erreur.

Conclusion

La méthode optimale dépend du contexte spécifique. Les transitoires offrent un bon équilibre entre l'intégration WordPress et les performances, tandis que l'approche de paramètre GET offre les meilleures performances mais nécessite une gestion plus minutieuse des messages d'erreur. La méthode $_SESSION est la plus simple mais moins fiable dans divers environnements WordPress. Choisissez la méthode qui convient le mieux à vos besoins et à l'échelle du projet.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!