Un back office WordPress pratique et efficace

Utilisé nativement, WordPress dispose d’un back-office beau, simple, pratique. Mais avec l'accumulation de plugins et l'utilisation d'un thème de la forêt ou d'ailleurs… ça devient vite le boxon.
Petit talk à propos de ce qu'est et ce que n'est pas un bon BO WordPress, quelques exemples et idées pour améliorer un peu tout ça.
Disclaimer: les slides n'étaient qu'un support, la majorité du contenu a été dit oralement :)

Transcript

1. Un back-office WordPress pratique & efficace… c’est (encore) possible ? WP Valence #5 – 3 mai 2017
2. Plop. Moi c’est Jb, responsable technique WordPress chez Whodunit Développeur full-stuff depuis 10 ans sur WP, thèmes sur-mesure, extensions officielles ou pas, traducteur, responsable de la maintenance d’un gros parc de sites web… amoureux des standards, de la qualité web & de la communauté WP. @audrasjb | jeanbaptisteaudras.com | whodunit.fr new : keepmywp.com
3. Pour la p’tite histoire • 2005-2008 : customisation de thèmes du repo et découverte progressive du codex et des fonctions natives WP • 2009-2011 : conception d’un starter thème efficace et adapté à la clientèle • 2010-2015 : utilisation d’un thème WP sans design fixe et développé en amélioration continue, avec un back-office agissant en surcouche • 2016 : houdonite? ◦ conflit dans mon ancienne agence ; départ non sans mal de toute l’équipe vers de nouveaux horizons, pour ma part avec de nombreux partis pris techniques (et aussi quelques préjugés ^^) ◦ Whodunit : une clientèle beaucoup plus diversifiée, mais de gros projets poussant à adopter une démarche réflexive : ▪ Qu’est-ce que c’est qu’un bon site WordPress ? ▪ Qu’est-ce que c’est qu’un bon back-office WP ? ▪ Est-ce qu’il y a des règles universelles ?
4. tl;dr : un bon back-office WP c’est… • Un back-office où le rédacteur retrouve ses petits : charté (mais pas trop), respectant les règles et wording métier… • Un back-office bien rangé et logique : chaque chose est à sa place et est affichée dans un ordre logique dans un processus de rédaction • Un back-office sans éléments inutiles : si ce n’est pas utilisé ça ne devrait pas être affiché • Un back-office respectueux des standards natifs WP : autant utiliser ce qui existe, et si possible ne pas le casser :)
5. Un back-office où que je retrouve mes petits • Mes règles métiers sont respectées ◦ Au niveau des types de contenus ou des champs personnalisés, les éléments doivent correspondre à ma logique métier ◦ Les wordings correspondent à ceux de mon métier : le nommage des contenus et des champs doivent utiliser mes conventions • Les éléments du BO sont traduits dans ma langue ◦ Le thème doit être traduit (ou traduisible), les plugins également ◦ Il y a des outils pour effectuer les traductions comme Zanto, mais le mieux est d’utiliser la traduction officielle WordPress (GlotPress génère automatiquement un package de langues à partir du moment où les chaînes traduites sont validées par un GTE ou un PTE) • Les éléments sont chartés ◦ Custom login, un peu de personnalisation BO ◦ Mais attention à respecter WP ! Un back-office tout pété dans 2 ans ce serait dommage :)
6. Un back-office bien rangé et logique • L’ordre des éléments dans le menu est logique : ◦ tableau de bord ◦ médias ◦ types de contenus ◦ apparence ◦ extensions ◦ outils ◦ réglages ◦ internationalisation / traduction ◦ options spécifiques aux plugins touchant à WP dans son ensemble. • Cela doit être prévu en amont de la construction du site • Puis pendant le développement / montage du site • Puis si c’était impossible avant, revu lors de la recette, soit par le code, soit par une extension comme Admin menu editor qui permet de modifier l’ordre et le rangement des éléments
7. Un back-office sans éléments inutiles • Votre site n’utilise pas les étiquettes ou les commentaires : on vire ! • Les extensions ajoutent souvent tout un tas d’éléments inutiles • Même WordPress affiche des trucs que l’on peut juger inutiles, comme le Planet ou certains écrans de réglages Si un élément ou une fonctionnalité n’a aucune utilité, il faut la supprimer ! • Soit par le code (thème ou plugin maison) • Soit par une extension comme Admin menu editor ou autre
8. Un BO respectueux des standards WP Le CMS dispose : • de guidelines : RTFM cher développeur :) → WordPress developer handbooks • d’une charte graphique back-office → plugin pour afficher les classes CSS BO • de fontes icônes et autres assets → préférer les dashicons à vos images :) • de librairies JS → WP utilise : jQuery/jQuery UI, TinyMCE ou encore Plupload, on ne charge donc pas MooTools, FCK Editor ou FineUploader ! + d’infos • d’éléments fonctionnels pré-configurés comme des tableaux, des éléments de formulaires, des listes… c’est pas pour les prunes :) En gros, ceci est un message aux développeurs : toujours préférer les éléments natifs aux pièces rapportées !
9. Les thèmes et extensions
10. Une page d’option pas très raccord avec WP A lire : https://delipress.io/designer-pour-wordpress/
11. Alerte! Alerte! Clique ici ! Achète ceci ! Ici, le plugin respecte un peu la charte WP, mais quelle horreur !
12. SecuPress est déjà moins intrusif :) (et beaucoup plus beau !) Mais il s’affranchit des règles WP…
13. Keep my WP, un entre-deux :)
14. Une utilisation discutable des dashicons, du menu admin, des plugins qui se mettent n’importe où…
15. L’éditeur visuel
16. Mon “ami” Visual Composer :’( En gros, en plus d’apprendre WP, le client doit apprendre Visual Composer qui a sa propre interface (complexe en plus)
17. Pourquoi faire simple quand on peut faire compliqué… Tout ça pour finalement coller l’éditeur WP natif… :’((
18. Si c’était juste pour gérer le colonnage il y a plus simple : Advanced WP Columns
19. Sélecteur de styles et de formats Utiliser les sélecteurs natifs pour placer les choses – vraiment – utiles. \o/
20. Pour trier les pages, Simple Page Ordering Rien de plus relou que d’avoir une liste de page alphabétique : rendez-moi mon arborescence !
21. L’exemple du multilingue
22. WPML, un plugin “hyper clair” :D
23. Sinon utilisez Polylang c’est mieux :)
24. ACF
25. ACF : gestion de l’ordre des champs ça parait tout bête mais faire en sorte que les champs s’affichent dans un ordre logique, c’est quand même mieux ^^
26. ACF : assignation des champs Et si en plus on peut les afficher uniquement là où on en a besoin c’est encore mieux !
27. ACF : réglages généraux du groupe de champs Et si en plus on les positionne au bon endroit et qu’on supprime les trucs inutiles, alors là c’est parfait ^^
28. Attentions aux repeater VS CPT :) Si vous avez plus de 5 ou 6 éléments dans un repeater, vous gérez un contenu à part entière devez utiliser un custom post type ! Un repeater doit avoir un nombre de champ maximum limité et paramétré dans ACF ! Sinon c’est souvent que l’architecture de l’information n’est pas bien conçue…
29. De la personnalisation
30. Un login personnalisé c’est bien… Erident Custom Login and Dashboard Permet d’obtenir une page de login chartée, ça c’est plutôt sympa :)
31. Mais trop c’est trop :) Cherchez l’erreur :)
32. La personnalisation en mode barbare
33. (sur github) Et en mode tranquille :)
34. Quelques bonnes adresses :)
35. Extensions • Multilingue : Polylang + Theme strings translation • Customisation du login : Erident custom login and dashboard • Types de contenus personnalisés : Custom Post Type UI • Champs personnalisés : ACF • Editeur visuel : Advanced WP Columns, Tinymce Advanced… et les plutôt “bons” constructeurs de pages comme Beaver Builder ou le récent Elementor • Une meilleure gestion en BO : Simple page ordering, Admin menu editor • Les plugins SEO… aucun ? ou sinon ACF ? :D… bon ok Yoast mais bon :((((
36. On en discute ? :)