Les statuts de WordPress, ma suggestion pour surmonter le statu quo actuel.

Crédits Photo Olivier Ortelpa sur Flickr

A l’occasion de certaines de mes crĂ©ations (BuddyDrive ou plus rĂ©cemment WP Idea Stream), j’ai eu l’occasion de me frotter Ă  cette API que je qualifierais de dĂ©terminante dans la mesure oĂč elle intervient au moment de la crĂ©ation des contenus (l’enregistrement) et au moment de leur consommation (la lecture).

Cependant, je ne me suis jamais attardĂ© plus que ça sur cette API car elle semble, selon moi, inaboutie et cela fait plus de 7 ans qu’aucun progrĂšs n’a Ă©tĂ© rĂ©alisĂ© sur un de ses aspects primordiaux : la possibilitĂ© d’affecter un statut personnalisĂ© Ă  un type contenu. Puisqu’en effet, l’intĂ©rĂȘt pour le dĂ©veloppeur peut consister Ă  vouloir ajouter de nouveaux statuts pour les donnĂ©es qu’il structure Ă  l’aide de l’API des Types de contenu de WordPress (Custom Post Types).

Un temps, j’ai pensĂ© proposer un patch sur ce fameux ticket #12706 et je me suis ravisĂ©. Ce ticket est suivi par plus de 160 contributeurs, les rares qui se sont aventurĂ©s Ă  proposer des correctifs ont abandonnĂ© assez vite car on se trouve dans une situation de « statu quo ». Tout le monde est d’accord sur le fait qu’il faut faire quelque chose, mais personne n’a de certitudes indiscutables s’agissant du comment faire cette chose… Bref on est coincĂ©!

Par ailleurs, vu que mes prĂ©cĂ©dentes suggestions sont restĂ©es dans le vide abyssal du Trac (cf. #39028, #37819, #39703, #31928 – L’indiffĂ©rence vis Ă  vis de ce dernier ticket m’attriste d’autant plus que je lui ai attachĂ© un patch qui amĂ©liore sensiblement le « templating » de la page d’inscription des configurations Multisite), il me fallait trouver un autre moyen pour tenter de modestement faire avancer ce schmilblick.

C’est la raison pour laquelle j’ai crĂ©Ă© l’extension WP Statuses ! Il me semble, en effet, que le format « feature as a plugin » est la meilleure maniĂšre d’obtenir les certitudes, grĂące aux retours des utilisateurs, sur le « comment » et de dĂ©passer cette situation figĂ©e. Avant de vous vanter les bienfaits de cette derniĂšre, je vous propose de nous rafraĂźchir les neurones sur les statuts et la publication dans WordPress.

Les statuts natifs de WordPress et son workflow de publication.

Il existe huit statuts dans le code source de WordPress pour lui permettre de suivre les Ă©volutions des contenus publiĂ©s et organiser son processus d’Ă©dition.

En effet, WordPress utilise ces derniers en lien avec les rÎles des utilisateurs pour proposer un workflow de validation simple, plutÎt cohérent et efficace :

  • Des contributeurs peuvent crĂ©er de nouveaux brouillons d’article et les soumettre pour relecture et validation auprĂšs des Ă©diteurs ou des administrateurs.
  • Les auteurs sont relativement autonomes pour directement publier et modifier leurs articles de blog,
  • Les pages du site sont quant Ă  elles le territoire exclusif des Ă©diteurs et des administrateurs (ces deux rĂŽles pouvant, bien entendu, publier des articles de blog!).

ProcĂ©dons par ordre en commençant par dĂ©crire le statut draft, brouillon en français. Il s’agit de l’Ă©tat qui vous permet de travailler sur votre publication sans qu’elle ne soit visible dans la partie publique du site. Seuls son rĂ©dacteur et les utilisateurs ayant des rĂŽles d’Ă©dition « élevĂ©s » (3e point de la liste prĂ©cĂ©dente)  peuvent dĂ©clencher des aperçus du brouillon dans l’ambiance publique du site. Son petit cousin auto-draft permet Ă  WordPress de rĂ©aliser des sauvegardes automatiques rĂ©guliĂšres de vos Ă©crits sur 7 jours glissants.

Une fois que le contributeur est satisfait de sa rĂ©daction, comme on l’a vu plus haut, il fait basculer son article sur le statut pending (traduit en français par « en attente de relecture »). Ce statut permet d’isoler une file d’attente des articles à publier afin que les éditeurs et les administrateurs puissent plus facilement les valider.

L’auteur ou le validateur peut alors choisir de rendre public le contenu immĂ©diatement, dans ce cas son statut devient publish (publiĂ©) et il est consultable depuis la partie publique du site pour tout visiteur. Le rĂ©dacteur peut Ă©galement dĂ©cider de planifier cette publication Ă  une date ultĂ©rieure, auquel cas le statut du contenu est future jusqu’Ă  ce que cette date soit atteinte (moment oĂč le statut passe en publiĂ©). Bien entendu, ce workflow est fonction du nombre de contributeurs du site. Sur ce blog perso, Ă©tant le seul Ă  publier, je n’utilise pas ce statut pending.

Jusque lĂ , tout va bien. Ça commence Ă  se compliquer avec le statut private (privĂ©) dans la mesure oĂč il introduit une notion de visibilitĂ© dans l’Ă©tat du workflow de publication. Par ailleurs, je dois avouer que j’ai du mal Ă  saisir l’intĂ©rĂȘt de ce statut. Les articles privĂ©s peuvent ĂȘtre postĂ©s par les auteurs, les Ă©diteurs et les administrateurs. Ils peuvent ĂȘtre consultĂ©s par les Ă©diteurs et les administrateurs, les auteurs ne pouvant accĂ©der qu’aux articles privĂ©s dont ils sont les rĂ©dacteurs ! Il me semble que cette restriction est beaucoup trop forte et que les contenus privĂ©s devraient ĂȘtre lisibles par tout membre authentifiĂ© sur le site.

Et puis, il peut arriver qu’on ait besoin de supprimer certains contenus. Le statut trash (Mis Ă  la corbeille) permet de disposer d’une quinzaine de jours pour Ă©ventuellement changer d’avis avant leur volatilisation totale.

Le statut du type de contenu révision est inherit.

Enfin, le statut inherit est un peu particulier. Il est utilisĂ© pour les accessoires du contenu en quelque sorte. Ainsi les mĂ©dias attachĂ©s Ă  l’article et ses trĂšs prĂ©cieuses rĂ©visions (dĂ©clenchĂ©es Ă  chaque nouvelle mise Ă  jour du contenu de l’article) sont deux types de contenu accessoires qui utilisent ce statut.

Revenons quelques instants sur cette notion de visibilitĂ©. Si vous observez la fenĂȘtre de publication de WordPress, les prĂ©fĂ©rences dans ce domaine sont d’abord masquĂ©es et se rĂ©vĂšlent lorsque vous cliquez sur le lien « Modifier » comme illustrĂ© ci-dessous.

La « Publish metabox » (fenĂȘtre de publication)

Or on s’aperçoit que ces prĂ©fĂ©rences contiennent le statut « Privé » alors qu’on pourrait l’attendre dans la liste dĂ©roulante « État ». Du coup se pose la question des autres prĂ©fĂ©rences de visibilitĂ© : « Public », « Public mis en avant » et « ProtĂ©gĂ© par mot de passe ». Sont-ce de nouveaux statuts ? Aussi l’observation la table MySQL des contenus devrait pouvoir nous Ă©clairer.

La table des types de contenu de WordPress.

Étrangement la protection par un mot de passe n’est pas un statut mais ce que j’appellerais un attribut de statut.  On aurait pu raisonnablement penser qu’il s’agissait d’un statut intermĂ©diaire entre le « Publié » (car publier, c’est aussi rendre public) et le « Privé ». En rĂ©alitĂ©, seul un article dont le statut est « Publié » peut comporter un mot de passe. Par ailleurs, l’information de mise en avant de l’article n’est pas stockĂ©e dans cette table, ni mĂȘme dans la table des MĂ©tadonnĂ©es de contenu (wp_postmeta) mais dans un tableau sĂ©rialisĂ© logĂ© dans la table des options du site et dont le nom d’option est sticky.

En revanche comme le montre l’interface, cette possible mise en avant ne concerne que les articles publiĂ©s. En passant, je me rappelle que lorsque j’ai commencĂ© Ă  utiliser WordPress, j’avais eu du mal Ă  trouver cette possibilitĂ© de mise en avant des articles. A mon humble avis, elle devrait ĂȘtre plus « visible » pour le coup ! Seuls les articles publiĂ©s publiquement peuvent ĂȘtre mis en avant, sauf que si vous utilisez l’outil d’Ă©dition en masse des articles, vous vous apercevrez qu’un bug permet de mettre en avant un article privĂ©.

Tada ! « PrivĂ©, mis en avant » CQFD 🙂

Par ailleurs, j’attire votre attention sur le fait que depuis cet Ă©cran, la prĂ©fĂ©rence de visibilitĂ© « Privé » de la fenĂȘtre de publication de l’Ă©diteur WordPress est devenu un « État » (autrement dit un statut). Voici qui n’est pas trĂšs cohĂ©rent.

Les statuts de WordPress sont donc des objets assez complexes qui peuvent avoir un rapport avec le workflow de publication, avec les prĂ©fĂ©rences de visibilitĂ© et avec la date de publication. Puisqu’en effet le statut « Planifié » entre en action pour les articles dont la visibilitĂ© est publique et dont la date de publication est prĂ©vue ultĂ©rieurement. C’est notamment cette complexitĂ© qui freine (pour ne pas dire immobilise) les contributeurs de WordPress dans la possibilitĂ© de prendre en charge les statuts que certaines extensions (ex: Woocommerce, bbPress,…) ajoutent pour leurs types de contenu directement dans son interface utilisateur. Par consĂ©quent, certains dĂ©veloppeurs contournent cette difficultĂ© soit en injectant via Javascript leurs statuts dans les listes dĂ©roulantes de WordPress, soit comme bbPress ou WP Idea Stream le font, en utilisant une nouvelle fenĂȘtre (metabox) dans l’interface d’Ă©dition.

A gauche la fenĂȘtre de sĂ©lection des statuts de sujet de bbPress. A droite, la fenĂȘtre de dĂ©sarchivage de WP Idea Stream.

Ma suggestion : WP Statuses

L’objectif de cette extension est d’abord d’intĂ©grer dans les interfaces utilisateur de WordPress permettant de modifier le statut d’un contenu la possibilitĂ© de gĂ©rer l’intĂ©gralitĂ© des statuts initialisĂ©s. C’est Ă  dire ceux nativement inclus par WordPress et ceux que d’Ă©ventuelles extensions auraient ajoutĂ©s. Il y a ainsi trois interfaces concernĂ©es :

  • la fenĂȘtre des actions de publication (Publish metabox) qui est affichĂ©e en haut Ă  droite de l’Ă©cran d’administration permettant de rĂ©diger ses contenus,
  • la fenĂȘtre d’Ă©dition rapide d’un contenu (Quickedit) qui s’affiche lorsque, depuis la liste des articles de votre administration, vous cliquez sur le lien « Modification rapide »
  • la fenĂȘtre d’Ă©dition en masse des contenus qui s’affiche lorsqu’on active le choix « Modifier » de la liste dĂ©roulante pour les actions groupĂ©es (Bulk edit) depuis la liste des articles de votre administration.

 Une nouvelle fenĂȘtre pour les actions de publication.

C’est la premiĂšre dĂ©cision que j’ai prise trĂšs rapidement. Il faut savoir que le code de la fonction post_submit_meta_box() qui est chargĂ©e d’afficher cette fenĂȘtre n’a quasiment pas Ă©voluĂ© depuis la version 2.7 de WordPress laquelle fut publiĂ©e il y a plus de 8 ans. Si vous regardez dans le fichier wp-admin/includes/meta-boxes.php, les lignes 107 Ă  118, vous comprendrez notamment pourquoi la liste dĂ©roulante pour sĂ©lectionner les statuts n’acceptent que ceux gĂ©rĂ©s nativement par WordPress : ils sont Ă©crits en dur !

La deuxiĂšme dĂ©cision que j’ai prise a Ă©tĂ© de crĂ©er un nouveau statut pour les articles protĂ©gĂ©s par un mot de passe. J’ai donc choisi de privilĂ©gier la notion de visibilitĂ© sur les autres notions que recouvrent un statut WordPress et que nous avons abordĂ©es Ă  la fin du chapitre prĂ©cĂ©dent (elles sont Ă©numĂ©rĂ©es en gras). Ce statut un peu particulier correspond en fait Ă  un publish avec mot de passe, c’est Ă  dire qu’au niveau de la table des contenus, rien ne change par rapport Ă  ce que fait WordPress Ă  ce jour.

La troisiĂšme dĂ©cision que j’ai prise a Ă©tĂ© de simplifier l’interface en retenant le principe que les options de visibilitĂ© sont des attributs de statut et en optant pour une liste dĂ©roulante qui est capable d’accueillir tout type de statut (les natifs et ceux ajoutĂ©s par des extensions). En effet, ça colle plutĂŽt pas mal pour les statuts publish et private et on pourrait assimiler pending et draft Ă  deux statuts invisibles ! Je me retrouve donc avec 5 statuts listĂ©s par dĂ©faut comme le montre le deuxiĂšme Ă©tat de la fenĂȘtre dans l’illustration ci-dessous.

Sur la droite: les 3 Ă©tats principaux de la fenĂȘtre des actions de publication gĂ©nĂ©rĂ©e par WP Statuses

Comme vous pourrez le constater, les attributs s’afficheront directement en fonction du statut sĂ©lectionnĂ© dans la liste dĂ©roulante. Ainsi, on comprend trĂšs vite qu’on peut mettre des articles en une, par exemple, et on Ă©conomise un clic (plus besoin de cliquer sur le lien « Modifier ») !

Adaptation des fenĂȘtres d’Ă©dition en ligne de la liste des contenus.

Cette partie a Ă©tĂ© beaucoup plus rapide. En observant le code de la mĂ©thode inline_edit() de la classe WP_Posts_List_Table, j’ai trĂšs vite saisi que ma seule alternative Ă©tait de me reposer sur Javascript pour les adaptations que j’avais Ă  rĂ©aliser ! Le gros du travail Ă©tait relativement simple. Il s’agissait pour moi de remplacer les statuts utilisĂ©s nativement par WordPress dans la liste dĂ©roulante qui s’intitule « Etat » par les 5 que ma fenĂȘtre des actions de publication utilisent (restons cohĂ©rents !). Ensuite, il fallait me concentrer sur l’interception de quelques cas particuliers comme la dĂ©sactivation du contrĂŽle permettant de mettre en avant des contenus lorsque le statut choisi Ă©tait privĂ© ou protĂ©gĂ© par un mot de passe.

Les adaptations apportĂ©es Ă  la fenĂȘtre de modification rapide.

Enfin, comme le montre l’illustration ci-dessus, pour le cas particulier de la fenĂȘtre de modification rapide, j’ai dĂ» supprimer la case Ă  cocher « Privé » puisque pour moi c’est un des statuts de la liste dĂ©roulante et repositionner les champs pour mettre en avant un contenu ou dĂ©finir son mot de passe Ă  proximitĂ© de cette liste.

Etendre l’API des Statuts de WordPress.

L’objectif de cette extension est ensuite d’Ă©tendre l’API des statuts de WordPress afin que l’objet statut contienne de nouvelles propriĂ©tĂ©s pour permettre aux extensions :

  • d’indiquer si elles veulent que leur statut personnalisĂ© soit listĂ© ou non dans les interfaces de WordPress,
  • de spĂ©cifier les textes Ă  utiliser pour chacune des listes dĂ©roulantes de ces interfaces,
  • de prĂ©ciser le ou les types de contenu (Post Type(s)) auquel(s) s’applique(nt) le statut personnalisĂ©.
  • de personnaliser le dashicon qui illustre le statut personnalisĂ©.

Il faut savoir que, de la mĂȘme maniĂšre qu’il existe une fonction pour initialiser un type de contenu (register_post_type()), il existe une fonction (register_post_status()) pour rĂ©fĂ©rencer les statuts personnalisĂ©s. Cette fonction doit ĂȘtre appelĂ©e en s’accrochant au hook init et son rĂŽle est de globaliser un tableau des statuts disponibles pour les types de contenu rĂ©fĂ©rencĂ©s dans WordPress dans la variable $wp_post_statuses. Ainsi WP Statuses interviendra une fois que tous les statuts seront dĂ©finis pour leur ajouter les propriĂ©tĂ©s spĂ©cifiques qui permettront de satisfaire aux quatre points listĂ©s plus haut.

Easter egg! Sachez que l’extension inclut une dĂ©monstration de ses possibilitĂ©s d’intĂ©gration des status personnalisĂ©s pour le type de contenu page. Pour activer et charger cette dĂ©monstration, il vous suffira d’insĂ©rer le filtre suivant dans le functions.php de votre thĂšme ou mieux dans un nouveau fichier positionnĂ© dans le rĂ©pertoire wp-content/mu-plugins.

add_filter( 'wp_statuses_use_custom_status', '__return_true' );

Un systÚme de remontée de bugs en moins de 150 lignes!

Pour illustrer les fonctionnalitĂ©s de l’extension par un cas d’usage concret, je me suis amusĂ© Ă  crĂ©er un type de contenu « ticket » et une sĂ©rie de nouveaux statuts lesquels sont affichĂ©s dans la capture d’Ă©cran ci-dessus. Le code fonctionnel de l’exemple est disponible ici et vous verrez qu’en un peu moins de 150 lignes on peut mettre en place un systĂšme de rapport de bugs pour son site 🙂

Cette extension s’adresse donc d’abord aux dĂ©veloppeurs dĂ©sireux de facilement crĂ©er des workflow personnalisĂ©s. Pour les aider, il peuvent trouver dans le morceau de code qui suit, une description des arguments spĂ©cifiques Ă  l’extension qui leur permettra de paramĂ©trer leurs statuts personnalisĂ©s.

Il ne vous reste plus qu’Ă  vous amuser avec cette extension 🙂 Si vous pensez que ces suggestions vont dans le bon sens, n’hĂ©sitez pas Ă  ajouter une Ă©toile sur son dĂ©pĂŽt Github!

2 commentaires sur “Les statuts de WordPress, ma suggestion pour surmonter le statu quo actuel.

  1. Hello,
    Je viens de lire l’article et de tester rapidement le bousin 😉
    Et en testant, je me suis rendu compte d’un comportement de WordPress, celui du bouton « Publier ». Dans tous les cas, il reste.
    Cela m’est dĂ©jĂ  arrivĂ© de choisir « Brouillon » et valider par le bouton « Publier ».
    On voit clairement avec ton extension que c’est plus propre, mais aussi qu’il y a un souci d’#UX avec cette MetaBox de WordPress.
    Personnellement j’irais encore plus loin, en supprimant tout bouton au dessus du « select ». Par contre je modifierais l’intitulĂ© du bouton « Publier ».

    La plupart du temps dans les appli, ce genre de bouton est un bouton « Valider ». Si nous faisons une action de la selection du status, pourquoi voudrait-on publier ?
    La logique n’est d’avoir qu’un seul bouton « Submit », et celui-ci changement en fonction de la sĂ©lection du status.

    1. Salut @lriaudel,

      Merci pour ton commentaire et ta suggestion. Dans l’extension, j’ai effectivement voulu garder le comportement de ce bouton. Il a en fait diffĂ©rentes actions en fonction du contexte. Ta proposition simplifierai beaucoup effectivement.

      Pour info: les différentes variations du bouton:
      – Lorsqu’on est authentifiĂ© sur le rĂŽle contributeur: il permet de passer du statut de « Draft » Ă  « Pending » et s’intitule « Mettre Ă  relire ».
      – Lorsqu’on modifie la date de publication, il s’intitule « Planifier ».
      – Lorsqu’on met Ă  jour un articles dĂ©jĂ  publier il s’intitule « Mettre Ă  jour ».

Les commentaires sont fermés.