Appuyez ici : vos plugins WordPress sont-ils compatibles GPL ?

Bienvenue sur Press This, le podcast de la communauté WordPress de WMR. Chaque épisode présente des invités de toute la communauté et des discussions sur les plus grands problèmes auxquels sont confrontés les développeurs WordPress. Ce qui suit est une transcription de l’ enregistrement original.

Propulsé par RedCircle

Doc Pop : Vous écoutez Press This, un podcast de la communauté WordPress sur WMR. Chaque semaine, nous mettons en lumière les membres de la communauté WordPress. Je suis votre hôte, Doc Pop. Je soutiens la communauté WordPress à travers mon rôle chez WP Engine et mes contributions sur TorqueMag.io. Vous pouvez vous abonner à Press This sur RedCircle, iTunes, Spotify ou votre application de podcast préférée, ou vous pouvez télécharger des épisodes directement depuis WMR.fm.

Si vous avez déjà contribué à un projet open source, vous savez que tout est question de collaboration et d'innovation, mais il existe un défi peu connu auquel de nombreux développeurs pourraient être confrontés pour s'assurer que leurs plugins restent du bon côté de la GPL, GNU, Licence Publique Générale. Ce n'est pas seulement une question de conformité. Il s'agit de préserver l'esprit de l'open source.

Nous avons donc aujourd'hui un invité spécial, Jeff Paul, directeur de l'open source chez 10up, qui partagera une solution révolutionnaire qu'il a présentée au WordCamp US cette année. Imaginez avoir un outil qui analyse automatiquement votre base de code pour garantir la compatibilité GPL de votre plugin, même lorsque vous ajoutez de nouvelles fonctionnalités et dépendances.

C'est de cela dont nous allons parler aujourd'hui. Mais avant de plonger dans le vif du sujet, Jeff, pouvez-vous nous raconter l’histoire de votre origine WordPress ?

Jeff Paul : Bien sûr. Je ne sais pas si j'ai l'année exacte. C'était probablement au début des années 2000. J'avais un site personnel qui était sur un ancien CMS, je crois qu'il s'appelait Geeklog. Et entre cela et mon hébergeur de l’époque, et qui sait combien d’autres facteurs, il y a eu, vous savez, un effondrement du contenu dans les CMS.

Et donc je cherchais juste quelque chose pour remplacer cela à l’époque. J'ai trouvé WordPress et cela a fonctionné pour ce dont j'avais besoin. Vous savez, je n'ai pas moi-même entrepris de créer un CMS, ce qui semble être une bonne histoire pour beaucoup de gens. Mais c'était, appelez-le, je ne sais pas, de 2004 à 2007, quelque part dans cette fourchette, mais je n'ai pas franchi en quelque sorte le fossé pour contribuer jusqu'à la version WordPress 4.7 lorsque j'ai rejoint l'équipe de publication là-bas avec Helen Hou-Sandi et Aaron Jorbin. J'ai donc passé de nombreuses années à être un consommateur du projet, et ce n'est qu'un certain temps plus tard que je suis devenu contributeur et, vous savez, j'ai continué sur cette voie depuis lors. Eh bien, vous savez, double consommateur et contributeur à ce stade.

DP : Et vous avez également été un contributeur très actif au cœur de WordPress. 10up gère des dizaines de plugins dans le référentiel de plugins, notamment ElasticPress, Distributor, ClassifAI. Tous ces éléments sont disponibles sur le référentiel wordpress.org et sont maintenus sur GitHub, publiquement et en utilisant des pratiques open source.

Vous connaissez très bien le sujet que nous allons aborder. Pourquoi ne commençons-nous pas simplement par le référentiel WordPress, comme le référentiel de plugins WordPress ? Dites-nous vite, qu'est-ce que le dépôt WordPress et quelles sont les règles pour pouvoir y télécharger quoi que ce soit ?

JP : Bien sûr. Ainsi, le référentiel WordPress est hébergé par WordPress.org, le projet open source, distinct de WordPress.com, distinct de tout autre hébergeur de l'écosystème, distinct des sociétés ou distributeurs de plugins tiers. Et c’est ce qui est directement lié ou lié à chaque installation WordPress. Lorsque quelqu'un est dans l'administrateur WordPress et recherche un plugin ou un thème, ces recherches s'effectuent via le référentiel de plugins WordPress.org et le référentiel de thèmes, disponibles dans l'administrateur WordPress. Et de même sur WordPress.org. En effet, la même recherche, le même contenu, y sont disponibles.

Pour ce qui est d'obtenir quelque chose qui y soit répertorié, l'équipe de révision des plugins wordpress.org dispose d'un ensemble de directives détaillées sur les choses à faire et à ne pas faire pour les développeurs de plugins. Et puis il y a un véritable flux de travail de soumission à suivre pour effectuer cette soumission initiale au référentiel de plugins wordpress.org. Une fois cela approuvé, un dépôt SVN est créé pour votre plugin. Et, vous savez, toutes les mises à jour, versions, etc. y sont transmises vers SVN. Et c’est en quelque sorte là que tout vit et respire actuellement pour les éléments disponibles pour la recherche sur WordPress.org ou dans l’administrateur WordPress.

DP : Selon moi, l'une des premières règles est que tout ce que vous mettez dans le référentiel WordPress doit être conforme à la GPL, y compris les polices et les images, pas seulement le code. Est-ce exact?

JP : Exactement. Droite. Donc littéralement, la première règle de l’équipe des plugins est que les plugins dans leur intégralité doivent être compatibles GPL. Il s’agit de la même licence que celle suivie par WordPress et, comme vous l’avez mentionné, le code, les images et les bibliothèques tierces doivent tous être compatibles GPL. Il ne doit pas nécessairement s'agir de la licence GPLv2, vous savez, il y en a d'autres qui sont compatibles GPL, mais oui, les polices, les images, les bibliothèques tierces, les dépendances, tout cela doit être compatible GPL et pas seulement le le code qu'un développeur de plugin écrit, n'est-ce pas ? Toutes ces autres choses doivent également être compatibles GPL.

DP : Et juste pour ne pas faire attendre les auditeurs, nous pourrions simplement nous lancer. Votre exposé portait sur la façon de vérifier la compatibilité GPL à l'aide des actions GitHub. Pouvez-vous nous expliquer ce processus ?

JP : Oui, donc cela vient un peu de mon rôle de directeur de l'open source chez 10Up. Ce n'est peut-être pas quelque chose dont un auteur de plugin ordinaire, vous savez, d'un seul plugin ou même de plusieurs plugins, pourrait en être conscient ou le déranger. Mais je pense qu'à un moment donné, je me suis presque littéralement réveillé au milieu de la nuit en pensant : « Je ne sais pas si je suis sûr que vous savez, toutes les images, toutes les dépendances tierces, toutes les polices. , et cetera, sont compatibles GPL et essaient de trouver un moyen à grande échelle pour nous chez 10up où nous avons, comme vous l'avez mentionné, des dizaines de plugins disponibles sur le référentiel wordpress.org ou sur GitHub également. La source là-bas.

Je ne voulais pas avoir à passer tout cela au peigne fin et à vérifier toutes les dépendances en amont que nous utilisions pour les plugins et à comprendre, vous savez, comment celles-ci sont sous licence. Cela pourrait être pénible pour un seul plugin, sans parler de plusieurs. Et grâce à certaines recherches en ligne, j'ai identifié qu'il existait des outils, des actions GitHub qui pourraient être utilisées pour aider à automatiser efficacement ce processus afin que, vous savez, il n'y ait pas qu'une seule analyse unique d'un référentiel pour dire, oui, vous êtes compatible ou non, vous ne l'êtes pas, mais des analyses continues afin que toutes les futures corrections de bogues, améliorations, etc., qui pourraient soit ajouter une nouvelle dépendance, soit peut-être supprimer une dépendance dans votre plugin qui pourrait peut-être changer la façon dont quelque chose se passait licence, être capable de vérifier cela en continu et d'effectuer ce genre de premier passage était quelque chose que j'essayais de comprendre afin que cela ne devienne pas simplement un processus manuel et intensif et une sorte de cauchemar continu pour garantir que , cette compatibilité.

Alors oui, je veux dire, je pense que la préoccupation initiale que j'avais était que je ne le savais pas – je n'avais aucun moyen de savoir qu'une fonctionnalité que nous ajoutions, si nous incluons une nouvelle dépendance, était compatible avec la GPL. , puis j'ai réalisé qu'il aurait pu y avoir un scénario encore pire où nous avions publié des plugins, répétés sur lesquels il y avait déjà des incompatibilités au sein de leur logiciel.

Et c’était donc en quelque sorte le premier problème que je voulais essayer de résoudre. Cette première analyse initiale, n'est-ce pas ? Nos plugins individuels, et tous ceux pris en charge par 10up, sont-ils vraiment compatibles avec la licence que nous avons déclarée ? Et j’espère que nous croiserons les doigts pour qu’ils l’étaient. Et puis, vous savez, à partir de là, cette vérification continue pour s'assurer que les futurs PR, qu'ils soient de mon équipe et de la pratique open source chez 10up, en général avec d'autres 10upers contribuant aux projets, ou n'importe qui dans la communauté, s'assurant que ceux-ci conservaient la licence que nous avons indiquée dans les plugins eux-mêmes.

DP : Et juste pour clarifier ici, si vous ne l'avez pas fait, si vous avez découvert grâce à cela, qu'il y avait, euh, une dépendance existante ou quelque chose là-dedans qui, qui n'était pas conforme, les ramifications sont en quelque sorte une sorte de honte de la part du communauté ou y a-t-il des dommages punitifs que vous pourriez subir pour ne pas avoir respecté les règles ?

JP : Donc je ne suis pas avocat, n'est-ce pas ? Donc, vous savez, je n'ai pas de statut d'avocat pour faire ce commentaire, donc, vous savez, ce n'est pas un conseil juridique valable, mais l'approche que j'ai adoptée pendant que j'exécutais ces analyses sur nos plugins, parce que encore une fois, je n'ai pas Je sais, j'étais en fait assez nerveux en dirigeant tout cela, quels seraient les résultats.

Mon plan était que si je découvrais qu'il y avait un plugin qui utilisait quelque chose qui n'était pas compatible GPL, la meilleure approche serait soit de supprimer cette dépendance, soit de l'échanger contre autre chose, de clarifier efficacement cela, quel que soit le problème. était et publiez rapidement une nouvelle version, non ?

Je pensais qu'il n'y avait pas grand chose à faire pour ce qui avait déjà été publié et diffusé. De mon point de vue, rien de tout cela n’aurait été fait dans le but de contourner délibérément les licences. cela aurait simplement été, vous savez, à un moment donné, une erreur humaine, un peu semblable à un problème de sécurité signalé à un auteur de plugin. Par exemple, la meilleure approche consiste à travailler sur une correction et à publier rapidement une version afin que les personnes qui restent au courant des plugins soient dans cet état plus sûr, qu'il s'agisse d'un problème de sécurité ou, dans ce cas, d'un problème de licence. Certes, s'il existait un plugin générant des revenus importants, et s'il pouvait y en avoir, des raisons de montrer que c'était une erreur connue d'avoir quelque chose hors licence, à part, je ne crois pas que quiconque dans l'espace fait cela exprès, mais je pense que les seuls qui pourraient potentiellement courir un risque juridique seraient ceux qui génèrent des revenus importants et qui seraient une cible pour l'octroi de licences.

Alors oui, pour faire court, si quelqu'un effectue une analyse et trouve un problème dans sa base de code existante, je pense que la meilleure approche est vraiment de publier une version, une version mise à jour, vous savez, de l'appeler dans le journal des modifications, indiquez dans les notes de version ce qui a été modifié et pourquoi, soyez transparent à ce sujet. Mais à ce stade, c’est vraiment, je pense, le mieux qu’un auteur de plugin puisse faire dans ce cas. Heureusement pour les plugins 10up, nous n'avons pas rencontré ce scénario. Heureusement, tout était compatible, et j’espère que la grande majorité des personnes empruntant cette voie, mettant en place une automatisation pour leur offrir ce niveau de confort, vivront une expérience similaire.

Cela peut être une attente un peu nerveuse et anxieuse de quelques secondes ou d'une minute pour que les actions GitHub s'exécutent. Mais, vous savez, une fois que tout est passé, je pense que la plupart des gens se retrouveraient probablement dans cet état.

DP : En parlant de mise à l'aise, nous allons faire une petite pause. Alors asseyez-vous et détendez-vous, et nous reviendrons après la courte pause publicitaire avec la suite de notre entretien avec Jeff Paul, le directeur des initiatives open source chez 10up sur la conformité de vos plugins à la GPL. Restez à l’écoute pour en savoir plus après cette courte pause.

DP : Bienvenue à nouveau sur Press This, un podcast de la communauté WordPress. Je suis Doc. Je parle à Jeff Paul de l'utilisation des actions GitHub pour vous assurer que votre code et vos plugins sont conformes à la GPL. Avant la pause, nous avons en quelque sorte plongé un peu dans ce sujet et nous avons parlé des conséquences si vous n'êtes pas entièrement conforme. Et je suppose que je voulais revenir à cette chose spécifique. Il existe des actions GitHub que tout le monde peut créer. Mais Jeff, vous avez mentionné dans votre exposé WordCamp que vous utilisez l'action officielle GitHub, je pense, avec quelques petits changements. Pouvez-vous nous dire quel est le nom de l’action que les gens devraient rechercher pour pouvoir faire cela ?

JP : Bien sûr. C'est une action de révision des dépendances. Donc GitHub.com, actions de barre oblique, dépendance de barre oblique, révision des traits d'union, action de trait d'union. Espérons que la transcription comprenne correctement. S'il y a un problème pour trouver que j'ai des notes à ce sujet sur mon site, sur un article qui couvre la discussion. Il existe donc des liens disponibles, mais si vous recherchez une action de révision des dépendances sur le marché des actions GitHub, vous trouverez, espérons-le, celle officielle que j'ai utilisée, et elle fait plus que simplement vérifier les dépendances des plugins. Il vérifiera bien plus que les licences. Il peut également vérifier les vulnérabilités et d’autres éléments dans les dépendances de votre plugin. Mais la seule chose pour laquelle je l'utilise, la principale raison pour laquelle je l'utilise, est de vérifier les licences invalides dans les dépendances de nos plugins.

DP : Et c'est une action qui vous permet de définir le type de GPL que vous souhaitez suivre. Vous pouvez inclure une licence et elle vérifie cela. Et il y a aussi la possibilité, si vous gérez, disons, des dizaines de plugins, de pouvoir toujours vous procurer la même chose. Vous pouvez avoir tous ces plugins que vous maintenez toujours dans ce répertoire, vous n'avez donc pas besoin d'aller le mettre à jour à chaque fois, n'est-ce pas ?

JP : Exactement. Ouais. Je vois que vous avez assisté à mon discours au WordCamp US, bravo à vous d'être dans le public, éveillé et écouté, ou vous l'avez capté sur YouTube ou WordPress.tv, mais oui, il y a en quelque sorte deux flux standards auxquels je m'attendrais, les gens. à suivre ici.

Premièrement, un auteur de plugin qui est responsable d'un ou d'un très petit nombre de plugins, ou quelqu'un qui en a plus sur une échelle de un à n, ils ont autant de plugins qu'ils prennent en charge. Donc, pour les personnes qui n'en ont qu'une seule, l'action GitHub, telle que vous l'avez définie, peut effectivement dans ce fichier de workflow où vous appelez effectivement cette action de révision des dépendances, et la faire analyser dans votre référentiel, il y a deux variables environnementales. ou les paramètres que vous pouvez fournir. Cette première action consiste à autoriser les licences et, en corollaire, à refuser les licences. On ne peut pas faire les deux en même temps. et l'approche que j'ai adoptée était d'opter pour les licences autorisées plutôt que pour les licences refusées. L'idée était qu'il y avait… Je préférerais avoir un cas où j'oublierais d'inclure une licence compatible GPL dans la liste des licences autorisées et obtiendrais effectivement un faux positif, n'est-ce pas ? Comme obtenir une dépendance signalée comme non compatible avec mes licences parce que sa licence était juste quelque chose que j'ai oublié d'ajouter dans la liste, alors que si j'utilise la liste de licences refusées et que j'ai oublié de refuser une licence que je ne veux pas, alors cela pourrait cela signifiait qu'une dépendance passerait, ne serait pas prise en compte par ce contrôle.

Ma recommandation extrêmement forte est donc de suivre cette liste de licences autorisées. Et dans le cas où quelqu'un gère un seul plugin, il suffit d'utiliser ce paramètre et cette liste de licences dans vos fichiers de workflow. Donc, pour 10up, pour nos plugins, c'est le répertoire point GitHub, puis le sous-répertoire workflows. Et puis nous avons le flux de travail de révision des dépendances qui appelle cette action de révision des dépendances, a la liste des licences autorisées, vous pouvez consulter ma présentation soit sur mon site, soit trouver la discussion en ligne et voir la liste des licences dont nous disposons. Vous pouvez également explorer n'importe lequel des référentiels 10up sur GitHub et voir les licences que nous explorons.

Nos fichiers de workflow sont assez bien documentés et expliquent en quelque sorte comment nous sommes parvenus à identifier ce que nous considérions comme des licences compatibles avec nos plugins. Les gens seraient donc invités à utiliser la liste que nous avons, à utiliser un sous-ensemble de cette liste, à faire leurs propres recherches, peut-être pour se sentir à l'aise. Mais nous avons effectué des recherches assez longues pour nous assurer que ce que nous utilisions dans notre liste de licences autorisées est réellement compatible avec ce que nous déclarons. Et à peu près par défaut pour 10up, nous utilisons GPLv2 ou version ultérieure, et donc toutes les licences que nous répertorions sont spécifiquement compatibles GPLv2.

C'est donc le cas, encore une fois, de l'auteur du plugin avec un seul plugin qu'il gère. Comme vous l'avez mentionné, dans le cas où quelqu'un en possède plusieurs, vous pouvez avoir un fichier de politique de licence distinct qui contient effectivement toutes ces licences déclarées. Et puis vous référencez ce fichier de configuration, ce fichier de politique de licence, dans le flux de travail de vos plugins, de sorte que, comme vous l'avez mentionné, vous n'avez réellement à ce stade qu'un seul endroit dont vous avez besoin pour maintenir la liste des licences compatibles. S'il y a, vous savez, une nouvelle licence open source approuvée par l'initiative qui s'avère être compatible GPLv2 pour nous, n'est-ce pas ? Si un nouveau système apparaît, il pourrait alors être ajouté à la liste, ou peut-être que s'il faut en retirer un pour quelque raison que ce soit, vous n'êtes pas obligé de le faire dans des dizaines d'endroits. Vous le faites à un seul endroit, puis tous vos fichiers de flux de travail faisant référence à cette configuration sont immédiatement mis à jour, à l'aide de cette nouvelle liste de licences.

DP : Tout est automatisé, donc si quelqu'un fait une pull request, il le fait juste pour vous. Droite?

JP : Exact, exact. Ainsi, lorsque nous créons nos fichiers de workflow dans nos référentiels, nous avons un déclencheur sur une pull request. Donc, vous pourriez aussi peut-être le configurer pour qu'il s'exécute selon un planning CRON, vous pourriez le faire fonctionner de manière hebdomadaire ou mensuelle, mais en réalité, une fois que vous avez effectué cette première exécution, vous analysez toute la base de code des dépendances, et ça va vraiment en avant, vous n'avez vraiment besoin de vérifier que les demandes d'extraction qui arrivent. Vous pouvez probablement également vérifier les validations individuelles si vous n'utilisez pas un système assez strict exigeant des PR sur quelles que soient vos branches par défaut ou stables pour vos plugins.

Il pourrait donc y avoir des déclencheurs supplémentaires que les gens pourraient vouloir utiliser. Pour 10up, nous avons tendance à exiger assez strictement que les PR développent et tronquent des branches afin que nous puissions utiliser cette action de manière fiable et savoir que toute modification des dépendances qui en introduit une nouvelle ou modifie une version qui modifie la licence sera prise en compte par cela. . Alors oui, nous utilisons, nous pivotons ou déclenchons des demandes d'extraction, mais en fonction de la rigueur des gens, vous pourriez peut-être vérifier les validations individuelles dans une branche spécifique, ou même exécuter selon un calendrier quotidien, hebdomadaire, mensuel, juste avoir ce confort en sachant que votre code est toujours en cours de transmission, qu'il n'y a aucune licence incompatible avec, dans ce cas, la GPLv2 pour 10up.

DP : Nous allons faire une autre petite pause ici. À notre retour, nous terminerons notre conversation avec Jeff Paul sur les licences GPL et reprendrons peut-être tout ce que nous n'avons pas abordé plus tôt. Alors restez à l’écoute pour en savoir plus après cette courte pause.

DP : Bienvenue à nouveau sur Press This, un podcast de la communauté WordPress. Nous terminons le spectacle et nous allons changer un peu de sujet. On a récemment parlé du processus de révision du référentiel de plugins et, en disant simplement que c'est le cas, il est un peu plus lent que par le passé.

Certaines personnes disent qu'elles savent qu'il faut, vous savez, des mois pour faire réviser quelque chose alors que je pense l'avoir vu culminer à peut-être quatre semaines au cours de la plupart de mes années dans WordPress. Donc, Jeff, je sais qu'ils ont parlé de certains changements qu'ils allaient apporter à cela. Pouvez-vous nous dire sur quoi travaille l’équipe actuellement ?

JP : Bien sûr. Ouais. Et j'ai, vous savez, j'amplifie ce que vous avez dit. Je pense qu'historiquement, j'ai vu que toutes les choses que j'ai soumises duraient moins de deux semaines et étaient beaucoup plus rapides que ce qui est habituellement rapporté. Et cela dure environ 88 jours, ce qui est malheureux pour toutes les personnes impliquées.

Je pense qu'il y a eu un certain roulement dans cette équipe. Certaines connaissances de haut niveau très expérimentées ont été perdues. Et les gens qui sont gracieusement intervenus pour aider à combler ce vide, je pense, en sont encore au point où ils peuvent avoir le même type de débit pour le traitement des plugins et l'examen de ces soumissions initiales. Et ils font du travail pour essayer d’automatiser une partie de cela. Donc, certaines des choses pour lesquelles, vous savez, les ordinateurs sont meilleurs que les humains ne le sont peut-être pas, peut-être comme exécuter les normes de codage WordPress et affiner les erreurs vraiment critiques signalées, n'est-ce pas ? Au lieu qu'un humain doive parcourir et traiter ces choses, avoir un vérificateur de plugin qui s'exécute et vérifie les choses qui peuvent être automatisées et aider cette équipe de révision des plugins à obtenir une pause initiale rapide, les choses qui sont automatisées sont-elles transmises ? Si tel est le cas, alors, d'accord, plongez-vous dans votre examen humain et accélérez les choses. Si des choses ont été signalées, étant de nature automatisée et qui ne passent pas, alors c'est, je pense, une réponse plus rapide à ce développeur de plugin de, hé, nous avons identifié ces choses initiales dans notre analyse, vous savez, s'il vous plaît, résolvez-les. puis soumettez un fichier zip mis à jour pour remettre les choses sur la bonne voie.

Je sais donc qu'ils travaillent à ajouter un peu d'automatisation, je pense que plus ils peuvent faire pour les aider sur cette voie, mieux c'est, simplement parce qu'à ce stade, avec plus d'un millier de plugins, le retard est long, et encore une fois , n'aidant personne là-bas. Alors oui, ils travaillent sur des automatisations. Je sais qu'ils veulent faire plus, et je pense que si c'est un domaine dans lequel quelqu'un est particulièrement doué en automatisation et souhaite contribuer, je pense que l'équipe de révision des plugins adorerait avoir de l'aide sur ce front. Alors contactez certainement Slack si tel est le cas.

DP : Et en parlant de contact, si les gens ont des questions, sur votre conférence que vous avez donnée au WordCampUS, ou simplement sur certains des projets sur lesquels 10uP travaille dans l'espace open source, quelle est la meilleure façon pour les gens de vous contacter. ?

JP : Bien sûr. Mon site Web est donc jeffpaul.com. J'ai ma présentation là-haut, si vous recherchez simplement GPL, ce sera probablement l'un des premiers articles de toute façon. Sinon, mon email est [email protected] , mon email professionnel, euh, et puis à peu près tous les réseaux sociaux. WordPress.org, GitHub, Twitter, slash X, et je suis @Jeff Paul, et vous pouvez tous me trouver sur les réseaux sociaux de cette façon.

DP : De même, si les auditeurs veulent trouver des exemples du travail de 10uP sur GitHub, je suppose que ce n'est que 10up sur GitHub ?

JP : Exact, ouais, github.com/10up. Tous les référentiels de nos plugins sont accessibles au public. Notre équipe suit de près les nouveaux problèmes et les relations publiques. Tout cela est transmis à notre chaîne Slack, donc toutes les questions, toutes les discussions, y sont ouvertes. Notre équipe devrait être assez réactive à cela, mais sinon, vous savez, en me contactant, sur WordPress Slack, sur Twitter par e-mail, n'importe lequel d'entre eux fonctionne. Je suis toujours heureux de discuter de l'open source avec les membres de la communauté.

DP : Eh bien, merci beaucoup d'être venu nous rejoindre aujourd'hui, Jeff, c'était vraiment génial de parler avec vous et j'ai beaucoup appris sur les actions de GitHub pour les demandes d'extraction et l'automatisation de cette expérience. C'est très utile.

Si vous avez manqué l'épisode de Press This de la semaine dernière, nous avons discuté avec Carmen Johnson des étapes que vous pouvez suivre pour préparer votre site à la fin de vie de MySQL 5.7 et de la façon de vous préparer pour MySQL 8. C'est donc un très bon épisode pour vous. pouvez vérifier, et nous en avons bien d’autres. Vous pouvez les trouver sur TorqueMag.io si vous souhaitez trouver des versions transcrites. Merci d'avoir écouté Press This, un podcast de la communauté WordPress sur WMR. Vous pouvez suivre nos aventures sur Twitter, au Torque Mag.

Vous pouvez vous abonner à Press This sur RedCircle, iTunes, Spotify ou votre application de podcast préférée, ou vous pouvez télécharger des épisodes directement depuis WMR.fm. Je suis votre hôte, Dr Popular. Je soutiens la communauté WordPress à travers mon rôle chez WP Engine et j'aime mettre en lumière les membres de cette communauté chaque semaine sur PressThis.