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 r√©flexions au sujet de « Les statuts de WordPress, ma suggestion pour surmonter le statu quo actuel. »

  1. lriaudel

    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. imath Auteur

      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.