Ce n'est pas une question sur la façon de construire un plugin WordPress. Quels guides, le cas échéant, pourraient être appliqués sur la manière de mettre en place l'architecture de fichier d'un plugin.
Certains autres langages de programmation ou bibliothèques ont des méthodes très contrôlées d’organisation des répertoires et des fichiers. Parfois, cela est agaçant et met en évidence la liberté offerte par PHP, mais du côté opposé, les plugins WordPress sont mis en place de la manière que leur auteur détermine.
Il n'y a pas de bonne réponse}, mais mon espoir est de préciser comment, moi et d'autres, construisons des plugins pour les rendre plus conviviaux pour les autres développeurs, plus faciles à déboguer, plus faciles à naviguer, et peut-être plus efficace.
La dernière question: qu’est-ce que vous pensez être le meilleur moyen d’organiser un plugin?
Vous trouverez ci-dessous quelques exemples de structures, mais en aucun cas une liste exhaustive. N'hésitez pas à ajouter vos propres recommandations.
Structure supposée par défaut
/wp-content
/plugins
/my-plugin
my-plugin.php
Méthode du contrôleur de vue modèle (MVC)
/wp-content
/plugins
/my-plugin
/controller
Controller.php
/model
Model.php
/view
view.php
my-plugin.php
Les trois parties de MVC:
Organisé par type de méthode
/wp-content
/plugins
/my-plugin
/admin
admin.php
/assets
css/
images/
/classes
my-class.php
/lang
my-es_ES.mo
/templates
my-template.php
/widgets
my-widget.php
my-plugin.php
WordPress Plugin Boilerplate
Disponible sur Github
Basé sur le Plugin API , Normes de codage et Normes de documentation .
/wp-content
/plugins
/my-plugin
/admin
/css
/js
/partials
my-plugin-admin.php
/includes
my_plugin_activator.php
my_plugin_deactivator.php
my_plugin_i18n.php
my_plugin_loader.php
my_plugin.php
/languages
my_plugin.pot
/public
/css
/js
/partials
my-plugin-public.php
LICENSE.txt
README.txt
index.php
my-plugin.php
uninstall.php
Méthode mal organisée
/wp-content
/plugins
/my-plugin
css/
images/
js/
my-admin.php
my-class.php
my-template.php
my-widget.php
my-plugin.php
Notez que les plugins sont tous des "contrôleurs" selon les standards WP.
Cela dépend de ce que le plug-in est censé faire, mais dans tous les cas, j'essayerais de séparer autant que possible la sortie de l'écran du code PHP.
Voici une façon de le faire facilement. Commencez par définir une fonction qui charge le modèle:
function my_plugin_load_template(array $_vars){
// you cannot let locate_template to load your template
// because WP devs made sure you can't pass
// variables to your template :(
$_template = locate_template('my_plugin', false, false);
// use the default one if the theme doesn't have it
if(!_$template)
$_template = 'views/template.php';
// load it
extract($_vars);
require $template;
}
Maintenant, si le plugin utilise un widget pour afficher des données:
class Your_Widget extends WP_Widget{
...
public function widget($args, $instance){
$title = apply_filters('widget_title', $instance['title'], $instance, $this->id_base);
// this widget shows the last 5 "movies"
$posts = new WP_Query(array('posts_per_page' => 5, 'post_type' => 'movie'));
if($title)
print $before_title . $title . $after_title;
// here we rely on the template to display the data on the screen
my_plugin_load_template(array(
// variables you wish to expose in the template
'posts' => $posts,
));
print $before_widget;
}
...
}
Le gabarit:
<?php while($posts->have_posts()): $posts->the_post(); ?>
<p><?php the_title(); ?></p>
<?php endwhile; ?>
Des dossiers:
/plugins/my_plugin/plugin.php <-- just hooks
/plugins/my_plugin/widget.php <-- widget class, if you have a widget
/themes/twentyten/my_plugin.php <-- template
/plugins/my_plugin/views/template.php <-- fallback template
Où mettez-vous votre CSS, JS, images, ou comment concevez-vous le conteneur pour les crochets est moins important. Je suppose que c'est une question de préférence personnelle.
IMHO, la route la plus facile, la plus puissante et la plus facile à maintenir consiste à utiliser une structure MVC, et WP MVC est conçu pour rendre l'écriture de plugins MVC très facile (cependant, je suis un peu partial) ... . Avec WP MVC, vous créez simplement les modèles, les vues et les contrôleurs, et tout le reste est géré en arrière-plan pour vous.
Des contrôleurs et des vues distincts peuvent être créés pour les sections public et admin, et l'ensemble de la structure tire parti de nombreuses fonctionnalités natives de WordPress. La structure de fichier et la plupart des fonctionnalités sont exactement les mêmes que dans les frameworks MVC les plus populaires (Rails, CakePHP, etc.).
Plus d'informations et un tutoriel peuvent être trouvés ici:
Cela dépend du plugin. Ceci est ma structure de base pour presque chaque plugin:
my-plugin/
inc/
Any additional plugin-specific PHP files go here
lib/
Library classes, css, js, and other files that I use with many
plugins go here
css/
js/
images/
lang/
Translation files
my-plugin.php
readme.txt
Ceci serait quelque chose qui irait dans le dossier lib
.
Si c'est un plugin particulièrement complexe, avec de nombreuses fonctionnalités de la zone d'administration, j'ajouterais un dossier admin
pour contenir tous ces fichiers PHP. Si le plug-in effectue quelque chose comme remplacer les fichiers de thème inclus , il existe peut-être également un dossier template
ou theme
.
Ainsi, une structure de répertoire pourrait ressembler à ceci:
my-plugin/
inc/
lib/
admin/
templates/
css/
js/
images/
lang/
my-plugin.php
readme.txt
Comme beaucoup d’entre eux ont déjà répondu Cela dépend vraiment dépendde ce que le plugin est censé faire, mais voici ma structure de base:
my-plugin/
admin/
holds all back-end administrative files
js/
holds all back-end JavaScript files
css/
holds all back-end CSS files
images/
holds all back-end images
admin_file_1.php back-end functionality file
admin_file_2.php another back-end functionality file
js/
holds all front end JavaScript files
css/
holds all fronted CSS files
inc/
holds all helper classes
lang/
holds all translation files
images/
holds all fronted images
my-plugin.php main plugin file with plugin meta, mostly includes,action and filter hooks
readme.txt
changelog.txt
license.txt
Nous utilisons un mélange de toutes les méthodes. Tout d'abord, nous utilisons le Zend Framework 1.11 dans nos plugins et nous avons donc dû utiliser une structure similaire pour les fichiers de classe à cause du mécanisme d'autoload.
La structure de notre plugin principal (qui est utilisé par tous nos plugins comme base) ressemble à ceci:
webeo-core/
css/
images/
js/
languages/
lib/
Webeo/
Core.php
Zend/
/** ZF files **/
Loader.php
views/
readme.txt
uninstall.php
webeo-core.php
webeo-core.php
dans le dossier racine du plugin.Webeo_CoreLoader
dans ce fichier, qui définit certaines constantes de plug-in, initialise l'autoloader de la classe et appelle la méthode d'installation de la classe Core.php
dans le dossier lib/Webeo
. Ceci s’exécute sur le hook d’action plugins_loaded
avec une priorité de 9
.Core.php
est notre fichier d'amorçage de plugin. Le nom est basé sur le nom du plugin.Comme vous pouvez le constater, nous avons un sous-répertoire dans le dossier lib
pour tous nos packages de fournisseurs (Webeo
, Zend
). Tous les sous-packages d'un fournisseur sont structurés par le module lui-même. Pour un nouveau formulaire d'administration Mail Settings
, nous aurions la structure suivante:
webeo-core/
...
lib/
Webeo/
Form/
Admin/
MailSettings.php
Admin.php
Core.php
Form.php
Nos sous-plugins ont la même structure à une exception près. Nous allons plus loin dans le dossier du fournisseur en raison de la résolution des conflits de noms lors de l'événement de chargement automatique. Nous appelons également les plugins boostrap classe E.g. Faq.php
à la priorité 10
à l'intérieur du hook plugins_loaded
.
webeo-faq/ (uses/extends webeo-core)
css/
images/
js/
languages/
lib/
Webeo/
Faq/
Faq.php
/** all plugin relevant class files **/
views/
readme.txt
uninstall.php
webeo-faq.php
Je vais probablement renommer le dossier lib
en vendors
et déplacer tous les dossiers publics (css, images, js, langues) dans un dossier nommé public
dans la prochaine version.
Ma logique, plus le plugin est gros, plus je prends de structure.
Pour les gros plugins, j’ai tendance à utiliser MVC.
J'utilise cela comme point de départ et évite ce qui n'est pas nécessaire.
controller/
frontend.php
wp-admin.php
widget1.php
widget2.php
model/
standard-wp-tables.php // if needed split it up
custom-tabel1.php
custom-tabel2.php
view/
helper.php
frontend/
files...php
wp-admin/
files...php
widget1/
file...php
widget2/
file...php
css/
js/
image/
library/ //php only, mostly for Zend Framework, again if needed
constants.php //tend to use it often
plugin.php //init file
install-unistall.php //only on big plugins
Je suis partisan de la disposition suivante du plugin, mais cela change généralement en fonction des exigences du plugin.
wp-content/
plugins/
my-plugin/
inc/
Specific files for only this plugin
admin/
Files for dealing with administrative tasks
lib/
Library/helper classes go here
css/
CSS files for the plugin
js/
JS files
images/
Images for my plugin
lang/
Translation files
plugin.php
This is the main file that calls/includes other files
README
I normally put the license details in here in addition to helpful information
Je n'ai pas encore créé de plug-in WordPress nécessitant une architecture de style MVC, mais si je devais le faire, je le disposerais dans un répertoire MVC séparé, qui contient lui-même des vues/contrôleurs/modèles.
Tous mes plugins suivent cette structure, qui semble être très similaire à celle de la plupart des autres développeurs:
plugin-folder/
admin/
css/
images/
js/
core/
css/
images/
js/
languages/
library/
templates/
plugin-folder.php
readme.txt
changelog.txt
license.txt
plugin-folder.php est alors généralement une classe qui charge tous les fichiers requis à partir du dossier core /. Le plus souvent sur le crochet init ou plugins_loaded.
J'avais aussi l'habitude de préfixer tous mes fichiers, mais comme l'a noté @kaiser ci-dessus, c'est vraiment redondant et j'ai récemment décidé de le supprimer de tous les futurs plugins.
La bibliothèque/dossier contient toutes les bibliothèques auxiliaires externes sur lesquelles le plugin pourrait dépendre.
Selon le plugin, il peut également y avoir un fichier uninstall.php à la racine du plugin. La plupart du temps, cela est géré via register_uninstall_hook (), cependant.
Évidemment, certains plugins peuvent ne pas nécessiter de fichiers d’administrateur, de modèles, etc., mais la structure ci-dessus fonctionne pour moi. En fin de compte, vous devez simplement trouver une structure qui fonctionne pour vous, puis vous y tenir.
J'ai également un plugin de démarrage, basé sur la structure ci-dessus, que j'utilise comme point de départ pour tous mes plugins. Tout ce que j'ai à faire est alors de faire une recherche/remplacement pour les préfixes de fonction/classe et c'est parti. Quand je préfixais encore mes fichiers, c’était une étape supplémentaire que je devais faire (et assez ennuyeux à cela), mais maintenant je dois juste renommer le dossier du plugin et le fichier de plugin principal.
Aussi, voyez ce superbe WP widget "warmplate" . Cela donne d'excellentes indications quant aux structures (même s'il n'y a pas de classe ni de dossier pour des modèles séparés).
L'approche par type de fichier est une approche moins commune pour structurer les fichiers et les répertoires d'un plug-in. Il convient de mentionner ici pour être complet:
plugin-name/
js/
sparkle.js
shake.js
css/
style.css
scss/
header.scss
footer.scss
php/
class.php
functions.php
plugin-name.php
uninstall.php
readme.txt
Chaque répertoire contient des fichiers de ce type uniquement. Il convient de noter que cette approche ne tient pas compte de plusieurs types de fichiers .png .gif .jpg
qui pourraient être classés de manière plus logique dans un seul répertoire, par exemple images/
.