web-dev-qa-db-fra.com

Meilleure façon d’initier une classe dans un WP brancher?

J'ai créé un plugin, et bien sûr, étant moi-même, je voulais utiliser l'approche Nice OO. Maintenant, ce que j'ai fait est de créer cette classe puis juste en dessous de créer une instance de cette classe:

class ClassName {

    public function __construct(){

    }
}

$class_instance = new ClassName();

Je suppose qu'il y a plus de WP façons de lancer cette classe, puis j'ai rencontré des personnes disant qu'elles préféraient une fonction init() à une fonction __construct(). Et de même, j'ai trouvé quelques personnes utilisant le crochet suivant:

class ClassName {

    public function init(){

    }
}
add_action( 'load-plugins.php', array( 'ClassName', 'init' ) );

Qu'est-ce qui est généralement considéré comme le meilleur moyen de créer une instance de classe WP lors du chargement et de le définir comme une variable accessible de manière globale?

NOTE: Comme point intéressant, j'ai remarqué que, bien que register_activation_hook() puisse être appelé à partir du __construct, il ne peut pas être appelé à partir de la init() à l'aide du deuxième exemple. Peut-être que quelqu'un pourrait m'éclairer sur ce point.

Edit: / Merci pour toutes les réponses, il y a clairement pas mal de débats sur la manière de gérer l'initialisation au sein de la classe elle-même, mais je pense qu'il y a en général un assez bon consensus sur le fait que add_action( 'plugins_loaded', ...); est le meilleur moyen de la lancer. de...

Edit: Juste pour embrouiller les choses, j'ai aussi vu ceci utilisé (bien que je n'utiliserais pas cette méthode moi-même, car transformer une classe joliment OO en une fonction semble aller à l'encontre du but recherché ):

// Start up this plugin
add_action( 'init', 'ClassName' );
function ClassName() {
    global $class_name;
    $class_name = new ClassName();
}
pluginsplugin-developmentdevelopment-strategy
85
kalpaitch

Bonne question, il existe un certain nombre d'approches et cela dépend de ce que vous voulez réaliser.

Je fais souvent;

add_action( 'plugins_loaded', array( 'someClassy', 'init' ));

class someClassy {

    public static function init() {
        $class = __CLASS__;
        new $class;
    }

    public function __construct() {
           //construct what you see fit here...
    }

    //etc...
}

Vous trouverez un exemple plus complet, approfondi, à la suite de discussions récentes sur ce sujet dans la salle de discussion, dans this Gist de membre de WPSE toscho .

L'approche constructeur vide.

Voici un extrait des avantages/inconvénients de Gist ci-dessus, qui illustre parfaitement l'approche constructeur vide.

  • Avantages:

    • Les tests unitaires peuvent créer de nouvelles instances sans activer aucun hook automatiquement. Pas de Singleton.

    • Aucune variable globale nécessaire.

    • Quiconque veut travailler avec l'instance du plugin peut simplement appeler T5_Plugin_Class_Demo :: get_instance ().

    • Facile à désactiver.

    • OO toujours réel: aucune méthode de travail n'est statique.

  • Désavantage:

    • Peut-être plus difficile à lire?

À mon avis, l’inconvénient est faible, c’est pourquoi il faudrait que ce soit mon approche privilégiée, même si ce n’est pas la seule que j’utilise. En fait, plusieurs autres poids lourds vont sans aucun doute entrer dans le vif du sujet, car ils le feront sous peu car il y a de bonnes opinions sur ce sujet qui méritent d'être exprimées.

remarque: je dois trouver l'exemple Gist de toscho qui a fait l'objet de 3 ou 4 comparaisons sur la façon d'instancier une classe dans un plugin qui examine le pour et le contre de chaque classe, le lien ci-dessus étant le moyen privilégié de faites-le, mais les autres exemples offrent un bon contraste avec ce sujet. Espérons que toscho l’a toujours dans son dossier.

Remarque: Le Réponse de WPSE à ce sujet avec exemples et comparaisons pertinents. Aussi la meilleure solution par exemple une classe dans WordPress.

add_shortcode( 'baztag', array( My_Plugin::get_instance(), 'foo' ) );
class My_Plugin {

    private $var = 'foo';

    protected static $instance = NULL;

    public static function get_instance() {

        // create an object
        NULL === self::$instance and self::$instance = new self;

        return self::$instance; // return the object
    }

    public function foo() {

        return $this->var; // never echo or print in a shortcode!
    }
}
57
userabuser

J'utilise la structure suivante:

Prefix_Example_Plugin::on_load();

/**
 * Example of initial class-based plugin load.
 */
class Prefix_Example_Plugin {

    /**
     * Hooks init (nothing else) and calls things that need to run right away.
     */
    static function on_load() {

        // if needed kill switch goes here (if disable constant defined then return)

        add_action( 'init', array( __CLASS__, 'init' ) );
    }

    /**
     * Further hooks setup, loading files, etc.
     *
     * Note that for hooked methods name equals hook (when possible).
     */
    static function init(  ) {


    }
}

Remarques:

  • a défini un lieu pour les choses qui doivent fonctionner tout de suite
  • désactiver/remplacer pour les réglages est facile (décrocher une méthode init)
  • Je ne pense pas avoir déjà utilisé/eu besoin d'un objet de la classe plugin - nécessite de garder une trace de celui-ci, etc. c'est vraiment un faux espacement de noms par but, pas OOP (la plupart du temps)

Clause de non-responsabilité Je n’utilise pas encore de tests unitaires ( tant de choses sur myplate ) et j’entends dire que statique peut être moins préférable. Faites vos recherches à ce sujet si vous devez le tester à l'unité.

10
Rarst

Tout dépend de la fonctionnalité.

Une fois, j’ai créé un plugin qui enregistrait les scripts lors de l’appel du constructeur, il a donc fallu l’accrocher au crochet wp_enqueue_scripts.

Si vous souhaitez l'appeler lorsque votre fichier functions.php est chargé, vous pouvez également créer vous-même une instance $class_instance = new ClassName();, comme vous l'avez mentionné.

Vous voudrez peut-être prendre en compte la vitesse et l'utilisation de la mémoire. Je ne suis au courant d'aucun, mais je peux imaginer qu'il y a des hooks non appelés dans certains cas. En créant votre instance à ce raccordement, vous économiserez peut-être certaines ressources du serveur.

3
Tim S.

Je sais que cela a quelques années, mais entre temps, php 5.3 prend en charge les méthodes anonymes , alors j’ai eu ceci:

add_action( 'plugins_loaded', function() { new My_Plugin(); } );

et de toute façon je l'aime le plus. Je peux utiliser des constructeurs normaux et je n'ai pas besoin de définir de méthode "init" ou "on_load" qui gâche mes structures OOP.

0
Basti