Le projet d'API WordPress Core Fields est à la recherche d'un nouveau leadership

En 2014, le développeur principal de Pods, Scott Kingsley Clark, a repris le rôle principal du projet Metadata UI. En 2015, le projet Metadata UI renaît sous le nom d'API Fields.

L'API Fields a été développée pour permettre l'enregistrement de champs sur différents écrans de la zone d'administration via une seule API. De nouvelles méta-boîtes et champs qu'elles contiennent pourraient être ajoutés aux messages tandis que de nouvelles sections et champs pourraient être ajoutés à l'écran de profil.

L'objectif de l'API est de s'intégrer à tous les différents écrans d'administration, y compris les publications, les conditions, les utilisateurs, les médias et les commentaires, et de fournir une standardisation.

Clark dirige le projet depuis trois ans et malgré un regain d'intérêt l'année dernière, il a annoncé sur la chaîne Slack du projet qu'il se retirait.

C'est le cœur gros que je dois passer le flambeau de ce projet. Après des centaines d'heures de mon temps, je ne crois plus que je peux effectuer des changements dans le noyau de WordPress.

La vision de l'API Fields était trop vaste, trop exigeante pour une seule personne. Je crois profondément que WordPress a besoin d'une API Fields, mais le chemin parcouru avec l'API Fields a été long et ardu.

La vérité est que j'ai brûlé il y a des années lors de la construction des premier et deuxième prototypes. Tout le monde n'était pas d'accord sur la façon d'architecturer le code, il a subi de nombreuses révisions basées sur les commentaires des principaux contributeurs. Je n'arrivais pas à enthousiasmer suffisamment de gens, je n'arrivais pas à intéresser suffisamment d'entreprises et de personnes à le soutenir.

J'ai besoin de laisser quelqu'un d'autre avoir sa chance, je la traîne vers le bas. Si quelqu'un se présente pour diriger à l'avenir, je serais heureux d'aider là où je le peux. Mais je ne suis pas en mesure de continuer à diriger la proposition/le projet de l'API Fields. Je suis désolé, veuillez accepter mes excuses et j'espère que vous pourrez me pardonner de ne pas avoir mené ce projet jusqu'à la ligne d'arrivée. Je crois toujours être une partie si essentielle du succès futur de WordPress.

Scott Kingsley Clark

Les épreuves et les tribulations de la direction d'un projet open source

Dans l'interview qui suit, Clark explique pourquoi il se sent personnellement responsable de l'absence de progrès du projet, pourquoi l'API est importante pour l'avenir de WordPress et réfléchit à ce qu'il aurait pu faire différemment.

Vous cherchez à passer le flambeau à quelqu'un en particulier ?

Non, je ne sais pas qui aurait le dynamisme et l'influence nécessaires pour mener à bien le projet. C'est un projet à grande échelle qui devrait être abordé avec une vision à long terme mais par incréments suffisamment petits pour en faire le cœur de WordPress. C'est beaucoup demander à quelqu'un, ce n'est pas non plus une priorité pour les gens en ce moment car ils sont distraits par la libération prochaine de Gutenberg.

Pourquoi l'API Fields est-elle un élément essentiel de l'avenir de WordPress ?

Les gens regardent WordPress aujourd'hui et se demandent comment ils ont pu survivre sans l'API REST. Eh bien, au moins je sais que je fais! La même chose peut être dite à propos de l'API Fields même si elle n'est pas encore là. Il y a tellement de cas où il est frustrant de créer des solutions pour WordPress à travers tous les différents crochets.

Pour la cohérence, c'est le Far West là-bas. Vous obtenez une méta-boîte enregistrée et vous la remplissez avec ce que vous voulez. Vous avez besoin de votre propre CSS pour styliser les champs du formulaire et chacun a sa propre idée de l'apparence de cette interface. Vous êtes responsable de vos propres mises en page réactives adaptées aux mobiles, il y a tellement de choses que vous devez gérer vous-même. Vous devriez pouvoir personnaliser les apparences, mais chaque endroit où vous souhaitez ajouter un champ ou un formulaire doit vraiment avoir une API appropriée.

À long terme, imaginez enregistrer des champs sur WordPress comme vous enregistrez des types de publication. Imaginez que les champs et leurs configurations soient disponibles pour l'API REST et accessibles via l'application WordPress ou d'autres applications personnalisées.

Le monde entier s'ouvre parce que vous avez une API cohérente, le monde entier a du sens parce que vous avez une interface cohérente pour ces champs sur les différents écrans d'édition. Les publications, les termes, les commentaires, les utilisateurs, les médias et même le Customizer auraient tous la même API sous-jacente pour ajouter des groupes, des panneaux et des champs à leurs écrans.

Si Gutenberg avait été fait après l'entrée de l'API Fields, la migration pour les gens n'aurait pas été aussi difficile. Gutenberg aurait pu afficher automatiquement toutes les interfaces de l'API Fields comme il le fait pour la rétrocompatibilité de la méta-boîte. Cela aurait été tellement plus joli aussi.

En prenant le temps de réfléchir, qu'auriez-vous pu faire différemment pour amener plus de contributeurs principaux à adhérer au projet et à en faire une priorité plus élevée ?

Je ne suis pas sûr, c'est un équilibre délicat entre la prise d'avis et la confiance dans le résultat final. Au début, les commentaires portaient sur la façon dont l'API était étrangère à WordPress, ils ont demandé si sa structure pouvait être similaire à celle d'autres API telles que le Customizer.

Nous avons supprimé le code et reconstruit à partir de zéro en tant que fork du Customizer, il a même pris en charge l'utilisation du Customizer en utilisant également l'API Fields. Au plus fort du développement, nous avions implémenté tous les domaines de l'API Fields.

Les versions principales évoluaient assez rapidement, il y avait beaucoup de changements de code d'une version à l'autre de WordPress que nous devions suivre car nous avions essentiellement créé un projet qui était un patch géant pour WordPress.

Il n'y avait pas assez de crochets en place pour faire ce que nous devions faire, et de nombreuses sections n'étaient pas extensibles en raison de décisions de code qui se marquaient comme "finales", ce qui signifie que vous ne pouvez pas étendre une classe spécifique pour personnaliser son fonctionnement.

J'aurais aimé pouvoir participer à tous les grands WordCamps aux États-Unis et en Europe, faisant essentiellement du lobbying pour cette fonctionnalité. Rassembler des supporters et autres, cela ressemble à de la politique en quelque sorte. J'ai traîné dans les réunions de développement Core, essayant d'en parler. J'ai essayé de légitimer la fonctionnalité en ayant un canal dédié dans le WordPress Slack officiel, en publiant des mises à jour sur https://make.wordpress.org/core/ et en organisant des réunions hebdomadaires.

Au final, j'ai priorisé mon temps de développement sur le temps de rassembler les troupes. C'était la chute, j'ai commencé à m'épuiser rapidement après les premières réécritures car j'avais de nombreuses autres responsabilités ailleurs au-dessus de l'API Fields.

Ce n'est pas comme si les entreprises voulaient facilement vous payer pour travailler sur un projet comme celui-ci indéfiniment, même si WebDevStudios et 10up m'ont donné le temps de le faire avancer. Ce n'était pas un chèque en blanc, à un moment donné j'ai dû me remettre au travail facturable. À partir de ce moment-là, tout était dans mon temps libre et c'était difficile à gérer pendant les périodes de stress financier et de vente/achat de maison.

Il y a une demande pour une API Fields dans le noyau mais pas assez de mains pour la construire. Pourquoi pensez-vous que c'est?

Tout le monde est concentré ailleurs. Il y a beaucoup de domaines de WordPress qui nécessitent l'attention des gens. Il y a des choses comme l'accessibilité qui méritent beaucoup plus d'attention qu'elles n'en reçoivent. Mais pour moi, l'accent semble être mis sur Gutenberg et l'API REST.

Gutenberg en particulier a été une énorme perte de temps pour les personnes qui contribuent et celles qui mettent en œuvre. C'est une très grande fonctionnalité. C'est définitivement plus grand que l'API Fields, c'est comme une toute nouvelle application qui vit dans WordPress. Son intégration a nécessité beaucoup d'éducation et d'essais/erreurs. L'attention des gens est là où elle doit être en ce moment. Il est juste regrettable que Gutenberg soit venu avant l'API Fields en termes de priorité et de niveau d'intérêt.

Quels conseils donneriez-vous au prochain chef de projet API Fields ?

C'est un gros projet, tout le monde voudra dire que ça devrait être d'une certaine manière. Vous devez évaluer les options et proposer quelque chose de plus petit pour le noyau pour commencer. Tirez parti de cela, mais ne perdez jamais de vue l'objectif à long terme d'intégration sur tous les écrans WordPress. Même les formulaires de commentaires frontaux pourraient prospérer avec l'API Fields.

Pourquoi vous sentez-vous personnellement responsable du fait que le projet n'est pas une priorité essentielle ?

À un moment donné, nous avons eu un élan. Nous avions au moins trois à quatre personnes qui étaient actives. Il s'est effondré parce que j'ai manqué de temps. C'est ma myopie, c'est ma faute. J'ai passé des centaines d'heures à développer le projet pendant quelques années. J'aurais dû me laisser beaucoup plus de temps pour organiser le texte de la proposition de fonctionnalité et entretenir le feu dans le cœur de nos contributeurs.

Considérant le temps et les efforts que vous avez consacrés au projet ces dernières années, vous sentez-vous soulagé de passer le flambeau ?

Si le flambeau est passé ou repris, je me sentirai beaucoup mieux. Le principal soulagement est que ce n'est officiellement plus un poids que je dois porter seul. C'est bien d'essayer et d'échouer, c'est quand même triste.

J'espère que quelqu'un ou une entreprise interviendra et consacrera du temps à cela. Ils pourraient même rallumer le feu dans mon propre cœur qui s'est éteint. Pour l'instant, j'ai une tâche majeure en moins. J'ai toujours une assiette bien remplie, mais ce n'est plus un fardeau aussi lourd.

Bien que l'avenir immédiat du projet ne soit pas clair, les personnes intéressées à le reprendre sont encouragées à lire les articles marqués de la balise API Fields sur Make.WordPress.Core pour en savoir plus sur son histoire. Vous pouvez également consulter la page Github du projet.

Si vous souhaitez reprendre le projet, vous pouvez contacter Clark sur Twitter, Slack ou via son site Web.