 Pour ceux qui ne me connaissent pas, je suis le lead développeur du plugin d'Oui Péroquette qui est un plugin d'optimisation de performance pour WordPress. Et aujourd'hui, je vais vous parler de comment moderniser et standardiser le développement PHP spécifiquement quand vous travaillez sur WordPress, donc ça peut être pour du thème ou du plugin ou tout autre chose. Ça va être basé en fait sur l'expérience que j'ai acquise depuis que je travaille sur le plugin d'Oui Péroquette donc ça va faire à peu près 3 ans et donc tout ce qu'on a mis en place au fur et à mesure pour améliorer tout ça au niveau du code. La première chose à faire quand vous travaillez sur un plugin ou sur un thème, et même si vous êtes tout seul, c'est d'utiliser un outil de version control. C'est un outil qui vous permet de gérer les changements du code source dans le temps et c'est un outil en fait à plusieurs avantages. Il y a deux outils qui sont très connus pour ça donc qui s'appelle Subversion, abrigé en général par Svn qui est l'outil qui est utilisé par WordPress quand vous publiez un plugin sur le repository. Et l'autre qui est le plus utilisé et le plus connu qui est Git donc là vous allez trouver des milliers de projets que ça soit du WordPress ou pas du WordPress qui utilise Git pour la gestion des versions du code et c'est celui qui est le plus recommandé. L'avantage d'utiliser un outil comme celui là c'est déjà d'avoir un historique de tous les changements que vous faites donc c'est super intéressant parce que vous savez qu'est ce qui a été changé dans le code et quand. Et par qui surtout donc si jamais il y a un problème vous savez à quel moment ça a été généré par qui et en général comment le comment le corriger. Un autre des avantages c'est si vous travaillez en équipe de faciliter la collaboration parce que ça a un système de branche et de fusion du code donc par exemple vous avez plusieurs développeurs sur un projet. Et ils ont besoin de travailler sur deux nouvelles fonctionnalités différentes grâce au système de branche qui peuvent chacun travailler sur leurs propres branches. Puis une fois qu'ils ont terminé peut fusionner les broches ensemble dans la branche principale et il n'y aura pas de problème de. De code de. De conflit de code de choses comme ça donc c'est vachement intéressant quand vous faites de la collaboration si vous avez une team de plusieurs développeurs. Ça peut même être intéressant quand vous travaillez vous même juste pour avoir une méthodologie. Efficace. Et donc tout ça ça vous permet d'avoir une bonne traçabilité quand vous avez de la gestion de projet à faire si vous avez une personne qui est dédiée au projet. Il pourra très facilement voir. Que à quelle étape le développement et qui a comment assigné les tâches aux différents développeurs et ainsi de suite. Il existe différentes plateformes pour. Pour gérer le version control comme ça qui sont la plus connue c'est GitHub. Vous avez aussi GitLab et Bitbucket qui sont toutes en fait des plateformes qui utilisent Git pour pour gérer le code source. Ce qu'on a fait nous chez Doeperroquette c'est qu'auparavant on était chez Bitbucket au tout début et on a migré sur GitHub en fait pour plusieurs raisons. Mais la raison principale c'était c'était celle ci. Avant on avait un Bitbucket privé donc en fait le code n'était pas accessible à l'extérieur c'était accessible que la team. Et au moment on a décidé de migrer sur GitHub on s'est dit. On va le passer public comme ça tout le monde aura accès au code de toute façon c'est pas ça qu'on vend. Donc on peut donner accès et avec le principe de la licence GPL de toute façon tout le monde est censé avoir accès au code et pour le modifier. Donc ce qu'on a fait c'est qu'on a passé sur un dépôt public. Et ça nous a permis d'avoir des contributions de personnes extérieures à l'équipe qui nous ont aidé à améliorer le produit. Parce que eux-mêmes avaient détecté des bugs ou des problèmes comme ça. Donc si vous décidez de mettre votre code en place sur un repository je vous conseille ça c'est vraiment une bonne raison. De le mettre public systématiquement parce que même si vous vendez le plugin ou le thème que vous avez. Ce que vous vendez c'est pas le code en lui même c'est le service que vous offrez autour avec le support les mises à jour et choses comme ça. Donc ça c'est la première étape c'est l'étape dirais indispensable si vous voulez faire un développement un développement moderne. Parce que ça va vous permettre de gérer tout le tout le système du code source. Une première chose à considérer avant de quand vous décidez de développer un nouveau plugin ou un nouveau thème c'est. Les versions de minimum de PHP de WordPress que vous avez supporté. C'est très connu que. Pour WordPress pour le coeur de WordPress depuis très longtemps la version minimum c'est la 5.2 et la rétro compatibilité est extrêmement importante donc. Il faut que toute nouvelle mise à jour de WordPress soit compatue avec 5.2 ce qui est une grosse imitation sur certains. Domaine de développement parce que 5.2 n'offre pas toutes les nouvelles features toutes les nouvelles fonctionnalités qui ont été apportées avec PHP 5.3 4 6 et maintenant PHP 7 ainsi de suite. Mais pour votre projet en fait ça vous de décider quelle version minimum de PHP vous voulez supporter vous avez aucune raison de. Supporter 5.2 parce que WordPress supporte 5.2. Nous chez d'eau et perroquette auto départ on suivait ce que WordPress osait donc on a été 5.2 pendant très longtemps. Puis récemment on a fait ça nous limite quand même beaucoup dans le développement donc on va faire évoluer ça au fur et à mesure. Donc on est passé en premier minimum 5.3 et maintenant on est minimum 5.4. Ce qui nous a permis d'utiliser de nouveaux outils de développement vraiment pratique. Et je vous conseillerai idéalement si vous pouvez si vous créez un nouveau plugin ou un nouveau thème. Supporter au mi fait un minimum PHP 5.6 parce qu'il y a encore une très grosse portion des hébergeurs et des sites qui sont sur 5.6. Mais si vous pouvez aller directement sur PHP 7 parce que vous gagnez au moins 50 % de performance en plus directement. Pour la version minimum de WordPress actuellement quand il y a une nouvelle version mineure pour des patchs de sécurité ou des choses comme ça. Il y a encore des patchs qui sortent jusqu'à la version 3.7. La version 3.7 elle a 8 ans ou un truc comme ça. Donc bon c'est pas forcément nécessaire pour vous pour votre projet de la même façon d'aller jusqu'à PHP 7 WordPress 3.7. Parce que entre temps il y a énormément de nouvelles fonctionnalités, de nouvelles fonctions qui sont sorties dans WordPress et qui peuvent être extrêmement utiles à ce que vous faites dans votre développement. Donc de la même façon dans nos hébergeurs à l'époque on était 3.7 et des choses comme ça. Maintenant on est 4.7 donc ça a à peu près deux versions avant celle qui est actuelle. Et ça nous permet d'utiliser des fonctions qui n'existaient pas avant d'avoir presse, d'utiliser directement dans nos hébergeurs sans avoir à faire des vérifications de compatibilité avec le code etc pour pas casser les sites des clients. Donc là je vais vous parler un peu de ce qu'on appelle le PHP moderne. Je vais pas aller jusqu'à vraiment dernier cri PHP 7 et tout ça parce que c'est un retour d'expérience que je fais et que nous on a cette limitation d'être jusqu'à d'avoir minimum PHP 5.4. Mais c'est des choses qu'on a apprises au cours du développement grâce à notre changement de version minimum. La première chose et qui est je pense la plus importante et qui a eu le plus gros impact c'est l'utilisation des namespace en PHP. Les namespace il y a un système qui existe depuis PHP 5.3 pour faire une organisation du code dans une hiérarchie virtuelle. Et qui est extrêmement pratique pour prévenir tout ce qui est conflit de nommages, de fonctions, de classes, de paramètres, de constant, de choses comme ça. Parce qu'une fois que votre code est derrière un namespace et bien s'il y a deux fonctions qui s'appellent ou deux classes ou deux fonctions qui s'appellent de la même façon et bien il n'y a pas de problème. Je vais vous donner un exemple. Très simple. J'utilise une namespace de deux les péroquettes et je crée une classe qui s'appelle plugin avec à intérieur une fonction qui s'appelle unit. Vraiment le truc basique. Si un autre plugin utilise la même classe et la même fonction et le même nom de fonction comme je suis derrière un namespace il n'y aura pas de conflit. Là je change un autre plugin image face à un autre plugin qu'on utilise. Il utilise les mêmes noms de classe même non de fonction mais comme il est derrière un namespace on est safe et ça c'est très important parce que ça vous évite aussi de vous retrouver avec des fonctions à rallonge avec des préfixes. D'où les péroquettes underscore underscore pour protéger le pour protéger toutes les fonctions que vous créez. Pour montrer c'est un exemple pour montrer la hiérarchie du code en fait une fois que vous avez que j'utilise les namespace. Donc là vous avez un fichier de classe qui se trouve dans le dossier deux péroquettes in classes admin settings page. Ça montre la hiérarchie qui va être ensuite reprise par le namespace pour la classe page donc qui se retrouve dans le namespace deux péroquettes admin settings. Vous avez une duplication comme ça une correspondance entre le chemin réel du fichier et le namespace et le nom de classe que vous utilisez. Ça va être important pour plus tard c'est pour ça que je voulais le montrer maintenant. Un autre des avantages qui est sorti avec PHP 5.4 c'est la création de trait c'est un mécanisme qui vous permet de réutiliser du code. Pour réduire certaines limitations qui existent quand vous faites du code orienté objet et que vous avez besoin de faire hériter des classes. Ça vous permet de partager des méthodes. Dans des classes qui sont indépendantes et qui ne sont pas dans la même hiérarchie en fait. Le plus simple c'est que je vous montre un exemple aussi. Ça c'est un exemple de trait que vous créez donc c'est ce trait là il sert à réécrire les les chemins qui se trouvent dans. Par exemple dans les fichiers css quand vous faites de la minification nous on est obligé d'adapter les les chemins des fichiers pour. Garder la bonne le bon chemin pour tout ce qui est image intégrée dans du css etc. Donc on a une fonction qui sert à ça et cette cette fonction là on en a besoin à différents endroits dans le code mais qui se trouve pas dans la même hiérarchie de classe. Donc il nous fallait une solution pour ça et grâce au trait en fait on va pouvoir l'utiliser par exemple dans la classe qui sert à faire la minification. Grâce au mot clé use au début qui fait appel en fait au nom de classe on peut utiliser dans les fonctions de la classe. La fonction à être passe qui est définie dans le trait et ça c'est vraiment pratique. Parce que de cette façon vous pouvez avoir. C'est ce partage de une horizontale en fait de de de de de fonctions entre différentes classes qui sont pas du tout. En ce qui sont pas liés donc ça c'est une autre fonction une autre classe qu'on a qu'on a dans le plugin. Qui elle permet de d'enlever les craistings quand vous avez dans les fichiers css et si. De la même façon vous utilisez le use et ça va utiliser la même fonction mais dans différentes méthodes et différentes classes. La dernière chose que je vais aborder pour le PHP moderne c'est des fonctions anonymes. Qui ont été introduites avec PHP 5.3 il me semble bien. C'est une des méthodes qui permettent de créer des fonctions sans avoir sans leur donner le nom. Et ça vous permet de ça nous a permis notamment de simplifier beaucoup le code. Parce que ça nous évite de ça nous évite. Permis d'éviter d'utiliser beaucoup de de boucles des fonctions qu'on avait dans le code qui servait à un seul endroit en fait. La fonction est servie uniquement. Pour un appel spécifique de de boucles ou de choses comme ça. Et grâce aux fonctions anonymes on a pu beaucoup simplifier le code c'est très utile pour tout ce qui est fonction de call back. Qui sont notamment par exemple à remap qui permettent qu'ils nécessitent en fait c'est des fonctions qui nécessitent une autre fonction. Pour faire un process dessus sur sur le paramètre qui est passé. Donc là je vais donner un exemple aussi ça c'est ce qu'on faisait avant donc on a une boucle forage sur un tableau. Et on avait cette fonction et une usage unique qui requête qui était requête. Qui vérifie en fait si la correspondance est bonne ou pas et s'il n'y a les pas bonnes on enlève la valeur du tableau. Et on a pu remplacer ça. Grâce à la fonction anonyme donc on voit une fonction qui est créée mais qui a pas de nom qui reçoit directement le paramètre. On a pu remplacer ça par un remap donc faire de la programmation fonctionnelle directement. Et on a en termes de simplification et de. Complexité du code c'est beaucoup plus facile à lire et beaucoup plus facile à comprendre et vous réduisez la quantité de code que vous avez dans votre code base. Là où il faut moi je conseille de pas utiliser fonction anonyme. C'est quand vous allez vous bouffer sur les hook de WordPress donc ad filter et les add action. Parce que c'est le code que je présente c'est tout à fait valide. Soit vous bouquez sur le filtre et content. Vous utilisez une fonction anonyme et vous retournez quelque chose à la place. Le problème c'est que si quelqu'un dit ben moi j'ai pas envie que votre code vous intégrer face à ça il a aucun moyen d'enlever. Donc si vous utilisez quand vous utilisez des hook. Utilisez quand même un nom de fonction directement systématiquement parce que ça simplifie beaucoup. C'est comme si quelqu'un veut faire un remove ou remove action sur sur l'action que vous avez ce sera beaucoup plus simple pour lui. Dans le monde de PHP il y a un groupe qui s'est formé en fait qui a pour but de créer des standards de développement qui s'appelle. C'est des règles en fait qui sont établies par le PHP. Qui essaie d'établir des points communs entre les différents projets participants pour que ça soit plus fossile pour les développeurs de passer de l'un à l'autre parce que. Ils auront ses points communs directement. Ça permet en fait une grosse standardisation de la façon dont vous allez coder du PHP. Et de partager entre les différents projets la manière de l'écrire. La manière de charger le code PHP et la manière d'interagir avec les différentes interfaces qui existent et qui sont définies par ce groupe. Donc ça c'est extrait directement du site des PHP standard. Il y a différentes versions donc il y a un focus qui est fait sur les coding stacks donc la façon d'écrire le code. Il y a deux règles là dessus PSR 1 et PSR 2 qui servent de. De recommandations sur est-ce que je mets par exemple les coeurs libre à quête au bout de la fonction ou au retroit la ligne. Comment nommer les namespace comment nommer les classes avec des underscores ou avec des des camel case des choses comme ça. Il y a une recommandation de standard sur l'auto loading. L'auto loading ça sert à enlever tout ce qui est la complexité dans le chargement des fichiers PHP. Au lieu d'avoir à faire des récroyeurs non du fichier à chaque fois dans tous les sens vous avez un système qui va le faire automatiquement pour vous. Il y a enfin le plus gros des recommandations de standard en fait c'est sur les interfaces donc l'idée des interfaces c'est d'avoir des. Une sorte de contrat quand vous allez utiliser une interface dans votre code vous savez à quoi vous attendre au niveau des méthodes et des paramètres qui seront disponibles. Donc là sur les interfaces il en existe actuellement. Il y en a encore d'autres qui sont en train d'être préparés. Et c'est vraiment bien parce que ça vous permet de de passer d'une livrairie à l'autre qui utiliseraient la même interface de base. Et bien le code ce sera le même. Postcode a pas besoin de changer parce que vous savez que dans un tel interface tel et tel méthode sont déjà définis. Composeur. Composeur ça c'était une sorte de révélation une fois que j'ai commencé à l'utiliser. C'est un outil qui sert en fait pour la gestion des dépendances de PHP donc c'est disponible sur Get Composeur. Et c'est très très très utile. Notamment pour les dépendances mais aussi pour d'autres choses donc vous avez Composeur. Le site Composeur pour avoir l'outil et Packages qui va regrouper sur ce site ça va regrouper toutes les librairies que vous pouvez installer avec Composeur directement. Le gros avantage c'est que ça va faciliter la maintenance des dépendances de votre projet dans le code source. Pour tout ce qui est installation et mise à jour par exemple avant dans Roquette on avait on utilise une librairie qui sert pour l'anification qui fonctionne très bien. Mais avant Composeur on devait télécharger la librairie l'inclure dans notre code et s'assurer qu'elle est tout le temps à jour et faire ça manuellement. Grâce à Composeur maintenant c'est cette librairie vit sur son propre repository sur GitHub et nous on a juste à faire une commande pour la mettre à jour. Et quand on envoie le truc aux les nouveaux fichiers aux clients la mise à jour est faite automatiquement. L'autre avantage de Composeur c'est l'inclusion automatique du code des dépendances et du code projet grâce à l'auto loader inclus dans Composeur. Donc pas besoin de faire de récroyer et de choses comme ça et de risquer d'oublier un fichier non inclus Composeur gère ça pour vous. Pour la configuration de Composeur ça utilise en fait un fichier Composeur point Jason. Tout ce que vous avez besoin au minimum en fait ça a un nom pour votre pour votre projet donc là par exemple. Lui définir un type un plugin et lui dire quelles sont les projets et quelles sont les dépendances qui sont dans le le projet donc là vous avez. Grâce au mot clé récroyer et les fichiers les fichiers. Après les différentes lignes indique en fait qu'il est le nom de l'auteur et du paquet que qu'on veut récupérer. Donc là on demande au minimum une version de PHP 5.4. Et on va chercher donc de différentes librairies pour faire du background processing pour gérer Cloudflare pour gérer la minification. Et dans le récroyer dev qui sont ce sont les outils qu'on utilise spécifiquement pour développement donc PHP Cutsniffer les standards de WordPress et ainsi de suite. Je présente quelques quelques commandes qui sont celles de base pour installer donc vous avez Composeur install pour installer toute la liste des dépendances que vous avez Composeur update. Pour mettre à jour les dépendances et si vous voulez ajouter une nouvelle dépendance vous pouvez juste faire Composeur require avec le nom qui correspond aux repository et ça ajoutera la dépendance automatiquement. Et l'ajouter dans l'auto loader automatiquement donc je passe à l'auto loading justement donc nous le principe de l'auto loading c'est de chercher automatiquement les classes PHP au moment où on a besoin. Si elles ne l'ont pas déjà été autre part. C'est un gros avantage parce que avant quand on n'avait pas d'auto loading on était obligé de faire ça et encore là j'ai coupé dans nos épéroquettes on avait facilement je pense une cinquantaine de récroyer comme ça. Et ça c'était vraiment compliqué à maintenir déjà ça fait ça pollue le code dans tous les sens. Et c'était très facile d'oublier de faire un récroyer quand on a ajouté un nouveau chichin avec l'auto loader de Composeur on en est rendu à ça ou globalement on a un récroyeur à faire sur l'auto loader et c'est fini. On peut faire des appels de classe directement après. Au moment où la classe est appelée Composeur est dit je l'ai dans ma liste d'auto loader et c'est bon. Pour gérer l'auto loader dans Composeur vous avez juste une ligne ajoutée pour gérer l'auto loader l'auto loading. Donc ça utilise ici par exemple le standard PSR 4 qui correspond au standard d'auto loader d'auto loading qu'on a vu tout à l'heure. Et qu'il utilise une correspondance entre le name space que vous avez dans votre plugin donc ici d'où les perroquettes et un dossier dans le code de votre plugin donc c'est le dossier qui contient toutes les classes. Une fois que vous avez fait ça vous êtes tranquille ça charge vous pouvez ajouter autant de chichis que vous voulez ça chargera tout automatiquement. Là on va passer un peu à standardisation en fait et donc ce qu'on appelle les candidates standard et les coding standard. Le but d'un coding standard quand vous êtes dans une équipe de développement c'est que tous les fichiers d'un projet quand vous les lisez vous avez l'impression que c'est la même personne qui les aigrite parce que le style de code est exactement le même. C'est très avantageux parce que n'importe qui qui arrive sur le projet il peut comprendre et modifier une partie du code quel que soit le moment ou la personne qui l'a écrit parce que ce serait toujours écrit de la même façon. Ça aide aussi à éliminer des erreurs fréquentes qui peuvent arriver où vous vous avez oublié de faire double égal au lieu d'un seul égal ou inversement et vous vous retrouvez à avoir une erreur dans le code mais le coding standard vous aurez signalé là c'est pas bon. Et ça éméliore la lisibilité du code. Vu que le code est toujours écrit la même façon. Donc il y a différents standards. Il y a le world press canning standard qui est celui qui a été mis en place par les contributeurs du corps qui ont leur un peu leur propre version. Spécifique qui correspond pas en fait à. Coding standard de PHP. Plus globaux si vous allez sur d'autres projets PHP. Ils vont utiliser le PSR 1 ou PSR PSR 1 et PSR 2 pour gérer le code donc après ça vous de choisir est ce que vous voulez suivre le code standard world press ou celui qui est plus général. Ça dépend de votre projet. Nous on suit code code standard world press mais c'est pas forcément idéal. Les outils pour coding standard pour pouvoir bien les appliquer. Vous avez PHP code sniffer qui va être un outil que vous lancez en ligne de commande et qui va vous dire tous les endroits où vous avez fait des erreurs. Et l'extension de world press coding standard pour avoir les règles spécifiques à world press. Un exemple rapide de la sortie du PHP CS que vous faites la commande. Il va vous indiquer les erreurs donc là par exemple là j'ai une fonction qui qui est au lieu d'être roquet de gaites par sueur et c'est le gait qui est devant donc ça c'est pas ok. Et il y a un espace en trop dans une des fonctions voilà c'est quelques indications comme ça là c'est un exemple rapide mais c'est le genre de sortie que vous aurez. Mais c'est détecteur c'est un autre outil que j'ai découvert quand Karl a fait une Karl Alexander a fait une conférence à loop conf l'année dernière. Et qui est vraiment intéressant parce que ça vous permet de détecter des problèmes potentiels dans le code source donc c'est disponible sur PHP MD. Et vous êtes à trouver des bugs potentiels. Et des erreurs que vous auriez faites par exemple j'ai oublié vous avez des variables des paramètres ou des méthodes qui vous utilisez pas dans le code il va vous dire ben vous avez ça et pas de vous l'utiliser pas donc vous pouvez l'enlever améliorer le code facilement. Et il va aussi vous indiquer si vous avez du code qui est trop long ou trop complexe donc si vous avez une méthode qui fait 500 lignes c'est qu'il y a un problème il faudrait peut-être la couper pour que ce soit plus simple. Donc là un autre exemple. Quand vous lancez la commande PHP MD sur un fichier spécifique il va vous dire ben là par exemple j'ai une méthode qui s'appelle task. Elle fait sans trois lignes de code et la limite est laissée elle est définie à 100 donc il faudrait que je trouve une façon d'améliorer cette fonction. J'utilise un else qui n'est pas vraiment recommandé parce qu'il y a toujours une façon de faire sans elle sans général. Et il y a un paramètre qui s'appelle data mais que j'utilise pas un méthode donc il faut que je l'enlève un mot sur le design pattern. Je vais faire très rapidement parce que ça pourrait faire l'objet de plusieurs conférences ou d'un workshop de 3 heures de choses comme ça. Mais c'est l'idée des design patterns c'est d'avoir des solutions qui sont répétables et standardisées pour un problème récurrent en design logiciel. Qu'est en fait qu'il n'y a aucune dépendance à un gage spécifique c'est des solutions qui peuvent s'appliquer et que c'est facile du PHP. Du Java script quoi que ce soit du C ou quoi que ce soit c'est des des schémas. Qui s'appliquent à n'importe quelle façon de coder et c'est des trucs qui existent depuis ces patterns existent depuis assez longtemps en fait ils sont très documentés. C'est des solutions qui sont maintenant testés à approuver et qui permettent en fait d'uniformiser le code quel que soit le code le langage que vous utilisez. Et aussi d'avoir un vocabulaire commun quand vous parlez de un autre développeur avec vous l'édite bien sur ça j'ai utilisé le pattern. Mediator pour pour gérer le problème s'il a la même connaissance que vous des designs patterns il comprendra tout de suite quelle est la solution que vous avez appliqué. Donc ça c'est vraiment intéressant parce que ça vous permet de pas réinventer la roue. Il y a des solutions qui existent déjà pour certains problèmes que vous avez rencontrés et comme vous connaissez les designs patterns vous savez quelle solution utiliser. Alors à sortir un petit peu du code en lui-même et plus des process qu'on a mis en place. Déjà avec l'automatisation parce qu'on perdait en fait on perdait énormément de temps sur certaines tâches et le but c'est de réduire le temps nécessaire pour effectuer des tâches répétitives. Pour gagner du temps pour le développement ou juste pour avoir du temps libre en plus. Ça c'est un exemple de quand je déployais une nouvelle version du plugin avant donc il fallait que je crée une nouvelle release sur l'item. Je téléchargais le fichier ZIP qui était généré. Décompresser le fichier le renommé faire le compte la commande de compositeur pour installer les dépendances. Rezipé le fichier lui donner le bon nom l'envoyer sur le ftp et mettre la version jour sur le site. Donc ça ça me prenait c'est pas si une fois que on a l'habitude c'est pas si long c'est 10 minutes mais à chaque fois qu'on fait une mise à jour 10 minutes au bout du compte ça fait beaucoup. Maintenant avec on a utilisé un cible qui est un outil d'automatisation. Je crée une nouvelle release sur l'item je fais cette commande avec un cible qui en fait qui va lire un fichier yamel qui contient tout le tout le process à effectuer. Ca s'occupe de toutes les parties qui ont qui ont qui ont été qui étaient vraiment laborious avant et j'ai plus qu'à faire une mise à jour de la version sur l'admire du site c'est fini. Donc ça cherchait à automatiser toutes les tâches répétitives que vous avez cherché à les automatiser au maximum si vous le pouvez ça vous fait gagner énormément de temps. Et finalement idéalement fait des tests donc les tests les tests unitaires ça c'est une vers c'est quelque chose qui n'est pas dont on parle pas énormément dans le monde de WordPress qui est beaucoup plus répandu. D'autres projets PHP. Projet en général de développement mettre en place des tests unitaires pour s'assurer que le retour de chaque fonction méthode que vous utilisez. Retourne bien le résultat attendu suivant ce que vous lui avez donné ça ça vous permet d'éviter toutes les problèmes de régression du code. Donc le l'outil plus connu pour ça c'est PHP unit pour PHP et idéalement on aimerait aussi mettre en place des textes fonctionnels par exemple dans un requête on sait que ça affecte énormément le. Le rendu potentiel du site une fois que vous l'avez mis en place donc les tests fonctionnels avec une automatisation avec avec Selenium par exemple qui est un outil qui permet de simuler des visites. Ça me permettrait de s'assurer que le fichier de cache est bien créé que le fichier de miniscation sont bien créés que le layout est bon et ainsi de suite. Et idéalement il faudrait qu'on automatise ça en utilisant des outils d'intégration continue comme. Trayvis circuler et ainsi de suite qui permettent de au moment où. Vous faites un merge sur sur votre nouvelle feature dans votre branche principale. Github il envoie la requête à votre outil d'intégration continue qui va faire tous les tests pour vous et vous dire si c'est ok ou pas. Donne quelques ressources qui m'ont été utiles en fait sur tout ce temps que j'ai passé à développer nos épéroquettes. Donc des livres que l'un qui s'appelle moderne PHP qui a été chez qui est dit chez Aurélie. Qui va parler justement de toutes ces nouvelles fonctionnalités dans PHP et qui va parler aussi de versioning de compositeur ainsi de suite. Et un qui s'appelle PHP object patterns in practice qui va être beaucoup plus focalisé sur faire du code orienté object. Et comment utiliser un certain nombre de design patterns. Avec une application non PHP donc avec énormément d'exemples et c'est vraiment très ça m'a été très très utile pour apprendre. Quelles sont les designs patterns qu'on peut utiliser et comment les appliquer. Et aussi des personnes à suivre parce que il faut soit ils font des tolles que soit ils écrivent des choses qui sont vraiment intéressantes donc. Carles Alexander qui est organisateur ici qui a son blog ou en termes de questions PHP orienté object et PHP moderne c'est du top. Il a une newsletter où il vous il fait toute une explication sur le PHP orienté object et il est en train de préparer un livre. Alain Schleser qui a fait un workshop au WorldCamp Europe sur l'application de design patterns dans un plugin WordPress. Avec l'application de dependency injection de toutes ces méthodes qui sont plus modernes et qui sont comment les appliquer quand vous faites un plugin WordPress. Josh Pollock aussi qui est là à la conférence il n'est pas ici parce qu'il parle que anglais mais. Qui est très intéressant qui écrit des articles sur advance PHP sur torque mag notamment donc si vous voulez avoir à prendre comment faire du PHP plus avancé. Allez lire ces articles et enfin Tonya qui a le site qui s'appelle nos codes qui ne base de données incroyable sur. Qui regroupe plein de tutoriels en fait pour apprendre à. Améliorer votre développement PHP faire des comment faire des tests sur votre code et ainsi de suite c'est une souscription mais ça vaut largement le coup parce que c'est vraiment vraiment intéressant. Même pour des développeurs comme nous de plugins qui sont. Qui ont une connaissance avancée il y a toujours quelque chose à prendre ce que vous avez des questions alors le gros problème en fait c'est que. On aimerait en faire mais on n'a pas eu le temps de les faire encore dans deux épéroquettes. C'est quelque chose dont on parle depuis très longtemps en fait de faire des tests unitaires dans le plugin mais c'est qu'il faut prendre le temps de le faire parce que. Surtout quand nous on a une code base existante qui l'a depuis 5 ans. Tu n'as pas fait tous les tests unitaires d'un coup à te dire ben là je prends 3 semaines pour faire tous les tests c'est pas possible. Donc en fait actuellement on cherche à trouver la meilleure méthode de comment intégrer les tests unitaires dans notre code au fur et à mesure qu'on fait du nouveau développement. Et c'est pour ça aussi qu'on recrute parce qu'on a besoin de plus de main d'oeuvre en termes de développement pour avoir le. Le temps humain nécessaire pour en faire pour faire des tests c'est pour ça que j'en ai pas inclus parce que je n'ai pas d'exemple directement. Je vais répéter la question pour la. Donc est-ce qu'on duplique du code pour s'assurer en fait que. Que ça fonctionnera toujours quelque soit la version PHP ou de WordPress. On a fait ça pendant un moment on par exemple on avait besoin de certaines fonctions qui se trouvaient uniquement dans PHP 5.6 ou dans WordPress 4.7. Et du coup on avait on avait un fichier un fichier spécifique. On avait un fichier spécifique pour tout ce qui est compatibilité comme ça on faisait si la fonction n'existe pas. Voilà ça c'est le code de la fonction qu'il faut utiliser dans le code après de requête. Donc on avait on avait un système comme ça mais maintenant avec l'augmentation des versions minimum qu'on a faites en fait dans ce fichier il n'y a plus rien parce qu'on a plus besoin de le faire pour l'instant. Mais oui c'est une bonne idée aussi oui si tu as besoin tu te dis ben cette fonction elle est vraiment bien faite. J'aimerais bien l'utiliser mais j'ai obligé de supporter une version inférieure. Parce que tu fais ta propre fonction tu la dupliques dans ton propre code en fait. Dans Composeur en fait j'ai un appel d'une des librairies de bonne dépendance en fait de que j'ai dans Composeur. En fait c'est un alias parce que cette librairie comme elle est actuellement sur son propre repo. Elle n'est pas comme il me faut donc ce que je fais en fait c'est que je lui dis moi j'ai ma propre version de cette librairie que j'ai fait un fort dessus et utilise. Je lui donne le chemin de mon propre repo et je lui dis utilise cette version de ce repo là à la place de l'autre tout en gardant le nom initial du repo parce que si jamais lui il met un jour comme il faut après je peux virer l' alias et c'est bon. Donc la question est-ce que je peux dire je veux juste supporter PHP 7 et puis voilà. Oui honnêtement oui après ça dépend de qui tu vises en termes de part de marché suivant ton business model en fait mais si tu dis je veux faire que du PHP 7 parce que je sais que c'est plus performant. Que ce sera ça me permet d'utiliser du PHP dernier cri dans mon code et. Que ce sera bénéfique tu peux le faire tout à fait le droit par exemple sur le repo maintenant tu peux indiquer la version PHP minimum que tu supportes donc les gens qui vont vouloir télécharger ton plugin ils vont devoir directement remarquer support minimum PHP 7. Et s'ils veulent l'utiliser il faut qu'il soit sur PHP 7 aussi. C'est tout à fait valable nous on le fait pas pour des questions d'héritage en fait de la base client qu'on a parce que avec les stats qu'on récupère on sait qu'on a actuellement. 35% des gens qui sont encore sur 5.6 et 5% qui sont encore sur 5.3 sur 5.4 et 5.5 donc en fait dans globalement 40% des gens. De nos utilisateurs sont sur des versions anciennes en fait qui vont être qui sont soit déjà dépréciés soit qu'ils vont l'être à la fin de l'année. Mais on peut pas tous leur dire mettez à jour PHP parce qu'il y a énormément de raisons qui font qu'on peut pas mettre à jour PHP quand on est sur un hébergement. Mais si vous faites un nouveau plugin directement il n'y a pas il n'y a pas de raison de pas de pas supporter PHP 7 directement. Pour le développement quel environnement on utilise moi j'utilise maintenant et je pense la plupart des gens dans mon équipe aussi on utilise visual studio code. Parce que Microsoft a fait un sacré travail avec avec cet outil et un des gros avantages en fait c'est qu'on peut avoir directement tout ce qui est PHP CS PHP mes électeurs etc. Tous ces outils là peuvent être intégrés directement dans le dans le l'outil de code et ça s'affiche dans la site bar au fur et à mesure que vous faites des changements. Donc vous avez tout en temps réel ça c'est extrêmement pratique. Avec un cibol tu peux faire vraiment tout ce que tu veux en fait ça l'avantage à partir. Qu'est ce qu'on a d'autres avec un cibol on a qu'est ce qu'avec d'où les perroquets spécifiquement on n'a pas plus que ça avec un cibol c'est vraiment spécifique sur ça. Mais sur d'autres produits on l'utilise pour déploiement de nouvelles app. Parce qu'on a une app qui gère l'optimisation des images par exemple et elle est créée un autre gs. Avec un cibol ça va servir pour le déploiement des versions automatiquement pour les différents staging par exemple. On va avoir un dev un staging pré prode et une prode et un cibol permet de déployer les trucs automatiquement comme ça. On l'utilise aussi pour. Pour nos sites quand on fait de nouvelles versions. Il y a un hook d'un item quand quand tu commites une nouvelle branche spécifique ça va mettre à jour automatiquement à partir de la branche sur le ftp du site comme ça tu. Tu n'arrêtes pas à faire toi même le déploiement c'est un cibol qui s'occupe du déploiement du nouveau site de la nouvelle version. Tant écoulé c'est bon merci beaucoup d'être venu.