web-dev-qa-db-fra.com

Actions, fonctions et conditions

Lors du développement de thèmes et de plug-ins, il est parfois nécessaire d'ajouter des fonctionnalités à certains points d'ancrage à l'aide d'instructions conditionnelles.

Exemple:

function my_custom_function() {
    if( is_home()) {
       <---what should the function do--->
    }
}

 add_action( 'some_hook', 'my_custom_function' );

À ma connaissance, chaque fois qu'une autre condition existe (is_home return false), le contenu de la fonction n'est pas exécuté, mais la fonction est exécutée bien qu'elle soit "vide". Cela signifie qu'une fonction vide est transmise au hook. C’est ainsi que tous les exemples sont présentés dans le codex à l’aide de balises conditionnelles.

Je comprends que cela est sécuritaire de le faire et que cela ne devrait pas avoir d’impact significatif sur les temps de chargement (s’il ya un impact quelconque sur le temps de chargement).

Je pensais, le même morceau de code, comme dans l'exemple, peut être écrit comme suit

if( is_home()) {
   function my_custom_function() {
     <---what the function should do--->
   }

  add_action( 'some_hook', 'my_custom_funtion' );

}

Cela permettra de tout ignorer si is_home renvoie false.

Cela ne me dérange pas d'utiliser l'une de ces deux méthodes. Mais ce que je veux savoir, en raison du premier exemple largement utilisé, existe-t-il une norme de codage indiquant que c’est la méthode correcte à utiliser, ou est-ce plutôt la méthode recommandée par les développeurs de wordpress, ou tout simplement une préférence personnelle.

conditional-tagscoding-standards
7
Pieter Goosen

Les normes de codage WordPress pour PHP ne stipulent rien à ce sujet, et il n’existe aucune autre norme, il appartient donc aux développeurs de choisir d’une manière ou d’une autre.

Je dois dire que les 2 méthodes ont des approches différentes; alors que le premier contient une logique conditionnelle, le second est une déclaration de fonction conditionnelle, ce qui signifie que si vous essayez d'appeler la fonction, vous obtenez une erreur fatale.

Même si vous utilisez la première méthode, où la fonction est exécutée (avec un impact très minime sur les performances qui ne sont pas pertinentes et lost dans la charge de l'application), il est préférable de l'utiliser, car méthode, la logique applicative de votre application est déplacée des fonctions vers l'analyse de fichier.

De plus, vous devriez considérer qu'il y a une troisième manière que vous n'avez pas mentionnée:

function my_custom_function() {
    // what the function should do
}

if ( is_home() ) {
    add_action( 'some_hook', 'my_custom_function' );
}

L'avantage de cette approche est plus perceptible lorsque vous utilisez la programmation OOP: dans ce cas, la déclaration conditionnelle de classe n'a pas de sens (et la déclaration conditionnelle de méthode n'est pas possible du tout), mais cela a beaucoup de sens de fonctionner tâches uniquement dans des conditions spécifiques (tir des crochets).

8
gmazzap

Ne créez pas de fonctions à la volée. C'est difficile à lire et à déboguer. Implémentez séparez les problèmes à la place, et séparez le enregistrement des rappels de leur exécution (logique applicative). La définition logique des vérifications conditionnelles devant l’enregistrement de rappel est désormais extrêmement simple.
Attendez pour que l’action template_redirect instancie ce gestionnaire d’enregistrement, car c’est le moment où vous savez si is_home() peut être coché.

Exemple

class Theme_Hooks
{ 
    public function setup()
    {
        if ( ! is_404() ) {
            add_action(
                get_stylesheet() . '_breadcrumb',
                [ new Breadcrumb, 'render' ]
            );
        }

        if ( is_home() ) {
            add_action(
                get_stylesheet() . '_home_widget',
                [ new Home_Widget, 'render' ]
            );
        }
    }
}

add_action( 'template_redirect', [ new Theme_Hooks, 'setup' ] );
7
fuxia

Je veux juste ajouter qu'en général, il faut faire attention en utilisant des balises conditionnelles comme:

if( is_*() )
{
    // stuff
}

dans la portée globale de functions.php, car il sera exécuté avant que tout filtre ou action ne soit déclenché avec do_action() ou apply_filters().

4
birgire

Je veux juste ajouter une autre option. Le cadre Hybrid Core a mis en œuvre une méthode appelée "crochets intelligents" qui reconnaît le contexte.

La source complète peut être consultée ici:

https://github.com/justintadlock/hybrid-core/blob/master/functions/core.php

Idéalement, il peut être utilisé comme ceci:

Un exemple de hook de base serait 'hybrid_header'. La fonction do_atomic () étend cela pour donner des points supplémentaires tels que 'hybrid_singular_header', 'hybrid_singular-post_header' et 'hybrid_singular-post-ID_header'.

0
Anh Tran

Je dirais préférence personnelle.

De plus, il est préférable de prendre l'appel de fonction en dehors de l'instruction if et l'action à l'intérieur de celle-ci. De cette façon, la fonction ne sera toujours appelée par l'action que si l'instruction if retourne true.

Garder toujours les définitions de fonction en dehors de l'instruction if garantit que vous ne finirez jamais par appeler une fonction piégée et non appelable.

0
Berend