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.
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
Déclaration de nos propriétés. Et à la construction de la classe, enregistrement de notre fonction d’installation et déclenchement de 4 hooks sur plugins_loaded
Gestion du post type. Gestion de la requête. Gestion de la vue.
Afin de cibler correctement pre_get_posts et wp_enqueue_scripts
on s’aidera d’un petit « helper » pour le contexte :
Enregistrement du CPT. Recours au propriété de notre classe.
Ajustement de requête. C’est aussi pour cela que l’on utilise les custom post type. Leur affichage est différent des articles et pages. Notez l’utilisation des propriétés de la classes et notre petit helper. En utilisant la fonction pre_get_posts, je comprends facilement ce que je fais.
Ajout d’une feuille de style dédié. J’utilise notre helper pour cibler proprement. C’est important de ne charger que le nécessaire dans WordPress ! On aurait la même approche si besoin d’un fichier javascript
Gestion des templates. Je renvoie un fichier spécifique si présent. C’est donc optionnel.