Le document aborde l'organisation du code dans WordPress, soulignant l'évolution rapide de la plateforme et les libertés laissées aux développeurs. Il évoque les défis liés à la lecture, à la gestion des versions et à la réutilisation du code, tout en mettant en avant l'utilisation des custom post types comme une avancée majeure. Enfin, il propose des méthodes pour créer un plugin afin de gérer efficacement les participants d'un meetup, tout en optimisant la structure du code.

1. Meetup #3
Bien organiser son code dans
WordPress : un peu d’objet beaucoup
d’effets

2. Constat
• En 4 ou 5 années d’utilisation de WordPress et
une centaine de réalisations, nous avons
rarement procédé de la même manière pour
aborder un projet.

3. Pourquoi #1
• WordPress évolue vite. Il faut donc intégrer
dans la mesure du possible les nouvelles
possibilités :
– Apparition des menus.
– Apparition des custom post types.
– Emergence de plugin « professionnels » (Yoast,
WooCommerce, MailPoet, etc..)

4. Pourquoi #2
• WordPress laisse beaucoup de libertés aux
développeurs :
– Codex plutôt complet mais pas de vrais « CookBook ».
– Documentation« atomisée ». Difficile d’avoir une
vision d’ensemble.
– Trop souvent on trouve dans Google un « snippet » de
10 lignes que l’on colle dans functions.php .
C’est à la fois la force et la faiblesse de WordPress.

5. 3 inconvénients majeurs
1. C’est dur à relire.
2. C’est dur à “versionner”.
3. C’est dur à ré-utiliser.

6. « Je bosse sur les CTP's, mais toi plutôt dans le
bas du fichier pour tes enqueues sinon on va
conflicter » Thomas D.
« Merde. C’est quoi ce projet déjà où on avait
une super Google Map ? » Virginie G.
Conséquences

7. LE CAS DES CUSTOM POST TYPES
Essayons de faire mieux

8. Rappel
• Apparus avec WordPress 3.0
• Evolution majeure pour les développeurs et
les webmasters
• WordPress devient un vrai CMS et plus
seulement un « un truc pour faire des blogs »
• Les clients adorent

9. Quand les utiliser ?
• Lorsque vous manipulez un contenu qui n’est
ni une vraiment page, ni vraiment un article.
Généralement, c’est le cas lorsque les fichiers
single.php et/ou page.php ne conviennent pas
pour leur affichage.
– Gérer les boutiques d’une enseigne
– Gérer des témoignages clients
– Gérer un portfolio

10. Comment les ajouter à son projet?
Sous la forme de plugins dédiés
– Le Post Type crée pourra « survivre » à un
changement de Thème.
– Le Post Type que je m’apprête à ajouter pourra me
servir sur d’autres projets. (d’autant plus si
l’ensemble du code est isolé au sein d’un dossier
unique.)

11. Un plugin pour faire quoi ?
• Cela dépend de mon projet évidemment, ici
on va simplement gérer les participants de
notre meetup.
• Le besoin est assez simple :
– Ajout / édition / suppression en back-office.
– Lecture en front (Single + Archive) avec templates,
css et requêtes spécifiques.

12. Traduction du besoin en WordPress
• init (pour l’enregistrement du CTP),
• pre_get_posts (pour adapter notre requête),
• wp_enqueue_scripts (pour une CSS
spécifique),
• template_include (pour gérer nos templates
directement depuis le plugin)
=> 4 fonctions sur 3 actions et 1 filtre

13. En objet c’est encore mieux
• Cela permet de disposer de propriétés.
– protected $_post_type = 'participants';
– protected $_posts_per_page = -1;
• Cela permet d’éliminer le function_exists et le
risque de collision.
=> Plus facile à lire et à comprendre donc facile
à modifier/réutiliser

22. Mission accomplie
100% du code nécessaire à notre
fonctionnalité se situe dans le plugin.