Si nous nous appuyons sur l'exemple simple hellodolly.php fournies par WordPress , ou encore les mêmes documents officiels, ne vient jamais à l'écriture d'un plug-in de bonne et efficace. Nous voulons ici pour analyser une structure possible, alors un squelette qui peut être utilisée plusieurs fois.
Les bases
Nous devons d'abord comprendre comment et quand un plugin WordPress est chargé dans le système. Quand il est activé par un plugin, le fichier qui contient le code principal, reconnu par les lignes classiques du commentaire:
1 2 3 4 5 6 7 8 | / * Nom Plugin: mes plugins Plugin URI: http://wordpress.org/extend/plugins/mioplugin/ Description: Description de mes plugins Version: 1.0.0 Auteur: Giovambattista Fazioli URI Auteur: http://labs.saidmade.com * / |
est chargé ou s'il ya dans le front-end et si nous nous trouvons dans l'administration (back-end):
Ce comportement est, en soi correct, et probablement dans de nombreux cas ne sont pas pris en compte par le développeur. En outre, certains plugins ont une structure (comme les paramètres, puis n'ont pas besoin d'une administration) qui rendrait inutile d'insister sur ce point.
Cependant il est évident que certains plugins ont une administration cohérente, qui est, ils apportent avec eux beaucoup de code utilisé uniquement dans le backend de WordPress. Dans ces cas, si vous ne prenez pas les précautions que vous pouvez télécharger à l'extrémité avant, la partie visible pour les navigateurs, le code totalement inutile qui ne fait rien, mais alourdissent la charge du blog.
Les conflits possibles: namespace
De ce qui précède il suit un autre fait important, tous les plugins WordPress sont chargés dans la même zone d'opération, ce qui entraîne la conséquence malheureuse que si deux différents plugins ont une fonction (une variable ou constante) a le même nom, ces entreront en conflit les uns avec les autres!
Idéalement, alors, serait en mesure de:
- Séparée de charger le code pour le front-end et back-end
- Protégez les "namespace" pour éviter d'éventuels conflits avec d'autres plugins chargés dans le système
Front-end ou back-end?
La meilleure façon de déterminer si elle est dans l'administration (back-end) est d'appeler la fonction is_admin() :
1 2 | is_admin ( ) ) // includi il codice lato back-end if (is_admin ()) / / Inclure le code de l'extrémité arrière else / / code incluent frontal |
En pratique, schématique, nous pouvons réaliser:
ou:
1 2 3 4 5 | is_admin ( ) ) { if (is_admin ()) { 'admin.php' ) ; require_once ('admin.php'); { Else {} 'client.php' ) ; require_once ('client.php'); } |
Utilisation des classes pour protéger l'espace de noms
Afin d'éviter les chevauchements désagréables un bon moyen consiste à «envelopper» de nos fonctions et nos variables dans des récipients appropriés: des objets. En définissant une classe, nous avons plus de possibilités pour protéger les noms de nos fonctions, nous pouvons obtenir comme un avantage supplémentaire de réutilisation du code dans le plugin avenir. Cette technique permet d'avoir deux plugins différents, donc deux objets différents avec la même méthode (fonction). Le conflit est éliminée grâce à la nomenclature des différentes classes et leurs instances.
Plugin Sketch
Ayant dit tout cela, nous voyons comment faire un croquis (que vous pouvez trouver jusqu'à ce jour dans une Saidmade Google référentiel de code ), un squelette, vous pouvez réutiliser à chaque fois nous avons besoin d'écrire un plugin. Tout d'abord les objets de la nouvelle organisation pour nous rendre compte que s'il est vrai qu'il ya une séparation des «net» entre le back-end et l'extrémité avant est également vrai que certaines "caractéristiques" sont et seront partagés! Ceci, au niveau de la programmation orientée objet, il ouvre la voie à suivre le long d'une organisation de code possible. Par exemple, l'intuition suggère que la création d'une classe "mère", c'est à dire une classe à partir de laquelle dérivent les classes de nos «clients» (front-end) et "admin" (back-end), ce serait une bonne chose!
Cette classe "mère" contient toutes les propriétés (variables) et méthodes (fonctions) des environnements partagés par front-end et back-end:
Donc, nous aurons notre classe "mère" et deux classes pour le front-end et back-end:
1 2 3 | sketch_class.php-WP / / parent de classe sketch_admin.php-WP / / classe pour le back-end sketch_client.php-WP / / classe pour le front-end |
Le fichier principal ( wp-sketch.php ) ne seront incluses dans une manière opportune, et d'instancier ces classes correctement:
1 2 3 4 5 6 7 8 9 10 | 'wp-sketch_class.php' ) ; // load the core class require_once ('wp-sketch_class.php') / / chargement de la classe de base is_admin ( ) ) { // check admin if (is_admin ()) {/ / Vérifier administrateur 'wp-sketch_admin.php' ) ; // load admin class require_once ('wp-sketch_admin.php') / / Classe administrateur de charge / / new WPSKETCH_ADMIN ( ) ; // create object Wp_sketch_admin WPSKETCH_ADMIN $ = new () / / créer l'objet { Else {} 'wp-sketch_client.php' ) ; // load client front-end class require_once ('wp-sketch_client.php') / client / charge frontal de classe new WPSKETCH_CLIENT ( ) ; // create object Wp_sketch_client WPSKETCH_CLIENT $ = new () / / créer l'objet } |
) ei nomi delle classi stesse ( WPSKETCH_ADMIN e WPSKETCH_CLIENT ), ma non i metodi e le proprietà in esse presenti. Ce «contexte» que vous venez de faire attention à définir de manière unique les variables qui contiennent des instances de classes ( $wp_sketch_admin et $wp_sketch_client ) et les noms des classes elles-mêmes ( WPSKETCH_ADMIN et WPSKETCH_CLIENT ), mais les méthodes et les propriétés qu'ils contiennent .
sono “sottoclassi” (figli) di WPSKETCH_CLASS , definita nel file wp-sketch_class.php . Les deux classes WPSKETCH_ADMIN et WPSKETCH_CLIENT sont «sous-classes" (enfants) de WPSKETCH_CLASS , défini dans le fichier wp-sketch_class.php . Ceci, comme mentionné plus haut, ne contient que les éléments partagés (variables et fonctions), car il est toujours chargé indépendamment du fait que nous sommes dans le back-end ou front-end.
En conclusion ...
Vous pouvez télécharger l'ensemble du squelette à partir du référentiel de code Saidmade Google . . En cela, vous trouverez également un fichier wp-sketch_functions.php , utilisé pour prévenir les appels à des fonctions dans un front-end pour traduire un appel oggetto->metodo() . En fait, il est un fichier facultatif n'est pas toujours nécessaire.
Les évolutions possibles de cette approche sont toujours une meilleure identification de la section sur lequel nous opérons et WordPress, et en ce sens, un large éventail d'actions d'optimisation pour être réalisée, afin de ne charger que le code nécessaire et quand nous avons vraiment besoin. Exemples Ulteiori de ce côté nous les verrons bientôt.
[...] Une technique de rapidement écrire un plugin WordPress peut être pour préparer un squelette (croquis) pour commencer. Spécifications WordPress, en fait, conduit souvent à avoir des plugins structurellement très similaire, en fait, sont les noms de fonctions et de leur contenu change. Cependant, dans la préparation d'un squelette, gardez à l'esprit de ne pas dupliquer les noms, constantes ou des fonctions utilisées par d'autres (dont la nôtre) plugin, sinon obtenir un plugins errore.Tutti actifs partager la même zone d'opération. Donc, si un plugin a une fonction qui est appelée abc_normalize () sans autres plugins peuvent avoir une fonction avec un nom de identico.Caso à distance? Coïncidence? Bien qu'à première vue il semble une affaire entièrement négligeable, il est extrêmement gênant quand ça arrive, surtout pour l'utilisateur final qui se retrouve incapable d'utiliser un plugin. Toujours dans la définition des constantes (comme TABLE_NAME, WP_MAIN_PATH, etc ...) est beaucoup plus fréquent d'obtenir des doublons. Pour plus de détails: Sur la structure des objets d'un plugin Wordpress [...]
[...] Sur la structure d'un plugin WordPress objet Comment structurer les classes d'un plugin WordPress pour le chargement optimal et la réutilisation du code. [...]
[...] Cette série avec le prolongement naturel de l'article de Napolux, la structure ou un objet avec un blog plugin wordpress [...]
[...] Sur la structure des objets d'un plugin Wordpress [...]
Bonjour, j'ai lu cet excellent article et je voulais vous poser une question: j'ai créé un plugin pour la gestion des produits classés par catégories et par les autres catégories de wp créé par moi à l'aide d'autres tables dans la plguin back-end travaille dur pour faire fonctionner parfaitement situé dans le front-end que je ne sais pas comment afficher la liste des produits de détail pour les deux ... ie nn sais comment le faire fonctionner avec le mod rewrite permaliens agirait très bien.
laissez-moi savoir
Dominic
@ Serdominik: Bonjour Dominique, pouvez-vous m'en dire plus en détail ce que vous avez besoin?
@ Giovambattista Fazioli:
Bonjour, merci de m'avoir donné une réponse.
Ma question est assez difficile de comprendre en quelques lignes de texte et l'écriture est difficile de vous faire comprendre (désolé si je vous donne le vous) alors difficile de suivre les commentaires par le biais des questions et des réponses pour moi aussi bien parmi les nombreuses choses que j'ai oublié d'aller vérifier Si par hasard je vois vous avez répondu aujourd'hui après 3 jours. Si vous voulez et si vous vous sentez nn est un désordre par MSN ou Skype ou par courriel
Malheureusement, beaucoup préfèrent ne pas commenter les détails du projet que je fais
[...] Le code produit respecte la norme structure orientée objet sur les objets décrits dans un plugin WordPress [...]
Discussion [...] sur la structure d'un plugin est disponible à l'adresse: Sur la structure des objets d'un plugin Wordpress, qui montre un squelette possible pour un package correctement [...]