 Du coup, petit sondage avant de commencer, qui dans la salle, c'est lire du code ? Oui, il y a beaucoup de développeurs, c'est cool. Et qui, l'île code source ? Oui, il y a des gens à convaincre. Donc pour me représenter brièvement, je m'appelle Willy, je suis web-designer, intégrateur et développeur, principalement développeur. J'ai travaillé quelques années en agence avant de passer en freelance, il y a un peu plus de deux ans. Et donc mon métier, c'est de créer des sites pour des clients, des thèmes et des plugins sur mesure. Donc pour mes clients qui sont des entreprises ou des associations. À côté de ça, je blogue sur mon site, qui est www.fer, je fais des articles plutôt orientés techniques. Et depuis deux ans, je co-organise Le Doulet Pétèque, qui est une journée de conférence technique sur WordPress. Et je co-organise ça avec Daniel Rock, qui est dans la salle en ce moment. Donc à la base, moi, je n'ai pas de formation de développeur, je n'ai pas suivi un cursus de développement. A la base, j'ai fait des études d'air plastique. Donc voilà, ça n'a pas grand chose à voir, mais en même temps dans l'écosystème WordPress, il y a beaucoup de gens qui ne sont pas développeurs à la base. Donc je me suis formé tout seul au cours de mes études, par un peu affinité avec le développement et puis pour des recherches artistiques. Et j'ai adoré le développement au point de vouloir en faire mon métier. Du coup, j'ai commencé par l'intégration, un peu parce que c'est ce qui est plus simple pour commencer. Et puis le java creep et le PHP. J'ai beaucoup aimé le PHP, mais pour un débutant, c'est un peu galère de faire un site from scratch, administration comprise. Et du coup, j'ai été voir un petit peu du côté DCMS, ce qu'il se faisait, parce que c'était plus simple pour moi. Donc j'ai testé à Spip, Joomla, tout ça. Et puis WordPress que j'ai adoré. Alors les ressources que j'ai utilisées pour commencer, c'est un peu comme tout le monde. C'était il y a 7 ans quand même, 7-8 ans, j'ai utilisé le Codex, qui était beaucoup plus pauvre à l'époque que maintenant. Et beaucoup de blogs, où les gens faisaient des tutoriels pour expliquer comment faire des petites fonctionnalités. Le truc, c'est qu'avec ces ressources, je ne pouvais pas faire des choses très avancées, j'étais un petit peu perdu. Et du coup, pour en venir au sujet de la conférence d'aujourd'hui, j'ai l'impression que ce qui m'a vraiment, vraiment frais progressé, c'est d'aller lire le code source, qui est pour moi la meilleure des documentations. Alors voilà maintenant, pourquoi actuellement prendre du temps à lire le code ? Parce que c'est vrai que maintenant, il y a plein de ressources qui sont beaucoup plus intéressantes, notamment parce qu'elles sont en français, parce qu'elles sont vulgarisées. Par exemple, on trouve le Codex qui a été vraiment étoffé. Il y a beaucoup plus de blogs, avec beaucoup plus de tutoriels. Il y a les forums toujours, les égrécateurs de documentations, comme d'où l'EP CIG, d'où l'EP HOOG DATABASE, le développeur référence, tous ces sites-là. Et puis il y a aussi les groupes sur Facebook et sur Slack, ou si vous avez un pépin, vous allez sur ces groupes, vous demandez de l'aide, et puis les gens vous expliqueront comment solutionner votre problème, quel plugin installer. Donc voilà pourquoi après s'embêter à lire le code source. Et bien pour moi, c'est parce que les gens, si vous leur demandez de l'aide, si vous cherchez sur le Codex, vous devez avoir des solutions toutes faites. Vous n'allez pas vraiment comprendre comment marche WordPress. Et vous allez passer à côté de quelque chose, des fois peut-être des fonctions toutes bêtes, des filtres, qui vont vous permettre de faire ce que vous voulez beaucoup plus simplement. En fait, vous aurez une vision globale de chaque fonction. C'est-à-dire que vous verrez chaque fonction dans son contexte, avec les paramètres de cette fonction, ce qu'elle retourne, depuis quand elle existe, ce qui se passe avant et ce qui va se passer après. Et tout ça, ça va vous permettre de progresser. Puisque vous allez moins réinventer la roue, si quand vous butez sur un souci, au lieu d'aller demander de l'aide directement, vous regardez comment c'est dans le Codex, vous allez découvrir peut-être des fonctions ou des hooks, qui vont vous permettre des résultats comme je le disais. Et à force du coup d'aller jeter un œil dans le Codex, de temps en temps, quand on bloque sur quelque chose, on va avoir une vision beaucoup plus globale de l'ensemble du fonctionnement de WordPress. Et en plus, vos développements seront plus stables et plus périns dans le temps. Parce que vous allez coder de façon plus native, et forcément ça tiendra mieux les versions de WordPress. Pour ça, il y a quand même des choses à savoir. Il faut connaître VITFELL code. Donc là, on est quasiment tous développeurs. Donc ça va, c'est simple. Mais après, il n'y a pas besoin de savoir super bien coder. Il faut juste savoir reconnaître les variables, les structures de contrôle, les fonctions, comment on définit une fonction, comment on l'utilise, comment on lui passe la paramètre, connaître les principaux opérateurs, savoir qu'une classe a priorité de notre classe. Voilà, savoir lire et vite faire du Code. Et puis il faut connaître aussi les hooks qui sont un mécanisme spécifique WordPress. Est-ce que tout le monde connaît les hooks ici ? Oui. Oui, voilà. Pas besoin d'expliquer, c'est... Bon, j'explique quand même. Je l'avais prévu. En fait, voilà, c'est une fonctionnalité qui permet de se greffer sur WordPress, alors soit via la fonction Ad Filter pour filtrer une variable, soit avec la fonction Ad Action, où vous allez pouvoir déclencher une action à un certain moment du Code. Autre chose qui est vachement bien, c'est que le Code, quand vous allez dedans, il est documenté. Il y a une documentation qui est assez complète, pas exhaustive, il y a comme des petits trucs qui manquent, mais il y a un effort qui a été fait, normalement depuis la 3.7, notamment, où les contributeurs ont documenté tous les hooks. Donc c'est... C'est très pratique quand elle est dans le Code Source. Il n'y a pas qu'un Code à lire. On peut aussi lire en anglais, forcément, la documentation. Cette documentation, d'ailleurs, elle va être extraite et reprise, comme je disais au tout début, sur le développement de références, hook, database, tout ça. Voici un exemple de documentation. Donc on sait quand une fonction, ici, d'où l'EPMU de l'étudeuseur, on sait qu'elle existe depuis la 3. Là, j'ai inventé un truc pour montrer qu'il y a quelque chose qui a été ajouté. On peut voir ce qu'il reste à faire, qu'elle variable utilise, les paramètres, les retours, tout ça. Il y a vraiment plein de choses qu'on peut retrouver dedans et ça aide vraiment à savoir ce que fait une fonction. Donc, avant peut-être de rentrer vraiment dans le gras de la conférence, je pense qu'il faut faire un petit tour, comme de l'arboréissance des fichiers de l'Aurtspress. Donc à la racine, qu'est-ce qu'on va trouver ? À la racine, déjà, on va avoir les fichiers qui s'occupent du chargement du corps. Donc ça va être forcément le index, le blog-aider, l'EP Config, tous ces fichiers-là, ils sont à la racine parce qu'ils vont lancer la machine. À côté de ça, la racine, on va trouver d'autres types de fichiers qui sont là pour des raisons pratiques, puisqu'ils peuvent être appelés par Wordpress, mais aussi de l'extérieur. Ça va être le cas du Cron, de XML-RPC, des formuleurs de commentaires, des formuleurs de connexion, de récupération de mode pass. En fait, ils incluent des bootstraps. C'est-à-dire qu'ils chargent eux-mêmes Wordpress si besoin, si on les appelle directement. Et puis on trouve aussi les trois répertoires qu'on connaît tous, qui sont d'où l'EP Includes. Donc dans d'où l'EP Includes, on trouve toutes les fonctions communes à Wordpress, BackOffice et FrontOffice. D'où l'EP Contente, c'est tout ce qui est propre au site. La source se fichit, on s'en fiche. Et puis il y a d'où l'EP Admin qui va nous intéresser seulement si on fait des plugins et qu'on veut toucher l'interface, voir comment fonctionne Wordpress en Admin et peut-être pouvoir utiliser des fonctions ou comprendre comment ça marche. Donc c'est bon pour le tour du propriétaire, on voit à peu près comment ça marche. Donc si on veut lire le code, qu'est-ce qu'on fait ? On commence par le début ? Non, c'est pas une bonne idée. En fait, si on essaie de faire ça, on regarde ce qu'il fait. Il appelle D'où l'EP Blockadeur. Donc on regarde D'où l'EP Blockadeur. En fait, il ne fait pas grand-chose, il cherche d'où l'EP Load. Dans d'où l'EP Load, il appelle les configs, le fichit config pour se connecter à la base de données. Donc on va avoir dans d'où l'EP Config. D'où l'EP Settings. Là, ça va, c'est simple à suivre. Si vous voulez continuer à lire, il va falloir ouvrir tous ces fichis là, et puis les fichiers qui sont inclus et essayer de comprendre. Donc voilà, c'est pas vraiment la bonne approche en fait. La bonne approche pour moi, c'est d'avoir un projet en cours et de temps en temps, d'aller voir les fonctions en rapport à ce qu'on développe. On va trouver un point d'entrée, donc une fonction qui nous intéresse. Par exemple, si on fait un template, on va prendre une fonction d'un template, on va la rechercher dans le code source et essayer de comprendre comment ça marche. Wordpress, c'est une grosse machine avec plein plein de fichiers et ces fichiers, ils sont un petit groupe de 3-4 pour faire des fonctionnalités. Donc voilà, on va pouvoir apprendre des fonctionnalités bout à bout de Wordpress et au final, avoir cette vision globale, cette compréhension de l'ensemble de Wordpress. Ok, mais du coup, comment on trouve des fichiers en rapport avec nos développements? Eh bien, il faut avoir une version de Wordpress sur son ordre. Soit on télécharge une archive sur Wordpress.org, soit via GitHub ou SVN, on fait un check out. On peut télécharger soit le trunk, soit l'ensemble des tags, si on a un giga à tuer, on peut. Et puis ça nous servira pour fouiller. Ce n'est pas top de l'avoir en distan parce que déjà, ça sera plus lent et puis on ne pourra pas faire de rechercher dans les fichiers, ce qui est une fonction quand même très pratique des auditeurs. Moi, par exemple, j'utilise Sublime Text 3 et ça marche aussi. C'est simple pour faire une recherche dans fichiers. On fait Command Shift F, sur Mac et Control Shift F sur PC. Et puis on va pouvoir rechercher, par exemple, la fonction Exert. Donc là, on indique où est-ce qu'on va rechercher une fonction, on tape zExert et là, du coup, il va nous sortir plein de trucs en fait. Il va sortir la déclaration de la fonction, mais en fait, ce n'est pas tout à fait ça qu'il faut faire. Ce qu'il faut faire, ça va être de rechercher la fonction zExert ou onzExert. Là, ça passe. Si on fait cette recherche là, on va trouver exactement la déclaration de la fonction avec le fichier et puis la ligne exacte quand on clique, on peut y aller. Donc là, on a un point d'entrée dans le code. On peut aller voir comment est cette fonction, qu'est-ce qu'elle fait. Donc ici, on a la documentation, on voit zExert. Et si on s'interroge sur est-ce que le corps intervient sur zExert, on peut rechercher aussi, finalement, le filtre en faisant filtre zExert, ça suffit. Avec un espace pour respecter les coding standard de WordPress, on sait que ça sera toujours comme ça. Et là, on trouve des faux de filters qui vont appliquer quelques petits filtres sur les zExert. Imaginez-nous maintenant que ce qu'on veut y trouver, c'est une action. Donc là, il n'y a pas d'action sur l'extrait. Donc on va plutôt rechercher, par exemple, on a envie de désactiver les notifications de commentaires. On sait que les commentaires sont ajoutés via de le pain new command post. Et on va chercher dans cette fonction. On va regarder s'il y a des actions. Donc on va un petit très chercher d'où actions. On trouve command post. Et puis après, on fait un peu une recherche sur des déactions. On n'est pas obligé de tout taper command post. Et là, on va trouver les lignes directement aux celles définies. Et quels sont les calbaques où on les filtre les actions appliquées à cette fonction pour pouvoir faire un remove action. Et donc, ça débarrasser des notifications de commentaires si on ne veut pas. Bon, allez, un peu pareil, toujours dans le templating. Si on veut voir comment on marche un objet, enfin, une classe, comment on a senti un objet. On fait une recherche sur la classe WLP query qui est une classe super intéressante. Si vous n'êtes pas allé voir ces fichiers, c'est donc un point PHP. C'est très intéressant. Et après, on peut aller voir la classe construct qui va instantier l'objet. Et puis après, on se balade dans les méthodes, voir tous les filtres qu'il y a. Et dans cette classe, il y en a un paquet de filtres. On peut vraiment changer tout le chargement de des contenus de WordPress ici. Bon, après, des fois, il y a des classes qui rit d'autres classes. Petite blague avec l'héritage. Par exemple, Walker NavMenu, elle irrite assez rapidement, on voit qu'elle est rit de Walker. Donc, si vous recherchez comment intervenir sur Walker NavMenu, allez voir aussi la classe Walker, parce qu'en fait, vous aurez peut-être d'autres moyens d'intervenir sur les menus de WordPress en regardant la classe Walker. Tout simplement. Donc ça, c'était pour tout ce qui était en rapport avec le front de le templating. Mais c'est ce qui vous intéresse c'est de savoir comment marche l'admin de WordPress. C'est un peu différent, parce que dans l'admin, vous n'allez pas connaître les fonctions. Vous n'allez pas les utiliser, donc il faut avoir les trouver. Alors ce qui est bien, c'est que dans l'admin, le marquage HTML il y a un peu plus statique, donc on peut se baser là-dessus. Par exemple, si je veux voir comment on se fait les listes d'articles de plugins ou d'utilisateurs, je repère, on n'a pas la classe aussi, c'est-à-dire la classe Doppelistable. C'était pour gagner à Paris. Et voilà, on va trouver en fait trois fichiers en rapport. Et en fait, on se dit, oui, il a appris trois fois mais c'est parce qu'il y a deux classes qui étendent d'une seule, qui est Doppelistable. Donc après cette classe-là, on peut en se dégâcher, parce que ce n'est pas périn trop ce qui est dans l'administration, mais on peut l'utiliser dans des plugins. Maintenant, on reste chez JavaScript aussi. Si on veut voir un peu de marche de JS dans l'admine, déjà, il va falloir activer le script debug. Sinon, toutes les fonctions que vous aurez retrouvées, elles seront minifiées, concatenées, ce sera élisible. Donc il faut l'activer dans WPconfig, un script debug trop. Et puis après, on va utiliser l'inspecteur d'une navigateur pour trouver une fonction JavaScript. Par exemple, le bouton modifier les parmaliens, si je veux savoir comment ils fonctionnent. Voilà, je vais dans un petit stunner, je recherche une action en clic avec les ancêtres, parce que ce n'est pas forcément appliqué pile-boile sur cet élément. On trouve quelque chose qui semble être correspondant à cette action, et puis après on n'a plus qu'à rechercher la fonction, elle dit permalink, comme on a fait tout à l'heure dans Fandin files, et on la trouve normalement. Donc on pourra même l'utilisant des développements à côté. Et si vous ne trouvez rien, du coup, ce qu'il vous reste à faire, c'est de regarder si vous ne connaissez pas toutes les fonctions de WordPress, ça se trouve, je veux dire une connerie, vous tombez sur Arremap, vous vous dites ce que c'est déclaré dans WordPress. En fait, ce n'est pas déclaré dans WordPress, c'est une fonction PHP. Donc là, vous recherchez sur Google. Vous avez des chances de trouver ce que vous recherchez. Ça peut être dans le cadre d'une libjs, par exemple, une dépendance externe. Ou bien, ça peut être une fonction qui va se trouver dans un plugin ou un thème. Ce qui est très intéressant, c'est que ça vaut pour le corps, mais ça vaut aussi pour comprendre le fonctionnement des plugins. Par exemple, j'ai toujours une installation des fichiers de WooCommerce en local qui a un plugin assez gros, assez compliqué, et pour lequel on a besoin de lire le code source aussi. Pour terminer, si vous n'avez pas trop envie d'aller comme ça à la pêche aux fichiers, je peux vous suggérer 2-3 fichiers qui sont vachement intéressants. Donc c'est vraiment une entrée en bouche. Allez les voir, ça vous apprendrait des choses et vous ferez des milliards de dollars de points après. Formating.php, c'est le fichier qui va contenir toutes les fonctions de nettoyage et de vérification de chaîne. Et puis, default filters, on l'a vu un petit peu dans les démos, c'est le fichier qui va appliquer ces fonctions via des filtres à certains éléments de WordPress. Vous pouvez aller voir aussi fonction.php. Function.php, c'est un peu le vrac des fonctions de WordPress. Donc vous trouverez plein de fonctions intéressantes que vous ne connaissez pas, et peut-être que vous recrez même à la main dans vos développements. Allez voir ce fichier-là, vous apprendrez des choses et vous pouvez les utiliser dans vos développements. Il y a query.php que j'adore, j'en ai parlé tout à l'heure. Il est super long, bourré de filtres et on peut tout faire avec ce fichier. Et puis, si au fait du templating vous pouvez aussi aller voir dans General Template, et puis Post-Template, donc ça, toutes les fonctions que vous utilisez dans un thème et pouvoir changer un petit peu leur comportement. Nous voilà, c'est vraiment les fichiers les plus intéressants. Après, si vous êtes sur des spécificités, si vous voulez creuser des API, fait comme j'ai dit, aller chercher avec des fonctions que vous connaissez et plus chier le code et vous verrez que ça va vous servir. Avec tout ça, maintenant, vous pouvez rester informé parce que vous allez comprendre le fonctionnement de certains fichiers et de certaines API, mais ça va évoluer au fil des versions de WordPress. Donc, comme suggéré tout à l'heure, Julio, allez suivre le MakeWord Prescor. Vous serez au courant des nouveautés, vous pourrez discuter avec les autres contributeurs et voir comment le code va évoluer. Et si vous avez la flemme, vous voulez juste être tenu au courant, suivez 2 API Devolles sur Twitter. En fait, c'est un robot qui publie tous les changements faits au courant. Donc voilà, est-ce que... Très bien. Vous avez des questions ? Merci. Est-ce qu'il y a des questions ? Bonjour. Bonjour. Moi, c'est Benjamin. Enchanté. Moi aussi. Très content d'être ici. Moi aussi. Alors, en fait, j'ai une question par rapport à ce que vous avez dit sur le Walker. Oui. Donc vous avez parlé des menus quand on veut modifier des choses sur le menu. Souvent, on tombe sur Walker. C'est bien ça, que j'ai compris. Oui, en fait, il y a un Walker 9 Menu qui va générer non pas, il va pas récupérer les éléments du menu mais va construire le menu avec ses niveaux de hiérarchie. En fait, moi, ma question c'est sur un détail précis. C'est que une partie des thèmes WordPress propose de mettre un seul menu nativement. Quand on veut installer un site multilingue, vous savez, un petit drapeau qui permet de passer de français à l'anglais, quoi que ce soit. Moi, ma problématique sur un projet c'est que ces drapeaux-là vont s'afficher dans le menu. Visuellement, c'est pas très joli et moi j'aimerais pouvoir afficher les drapeaux en haut à droite et donc créer un nouveau mini menu. Je me demandais si par rapport à cette question-là non. En l'occurrence, si ce que tu veux, c'est filtrer les éléments qui vont être dans le menu. Il faut fouiller dans le code, c'est vraiment ça. Je crois que ça va être dans 9 minutes en plait. Tu vas trouver quelque chose en dehors de la classe qui va te permettre de filtrer les éléments, de retirer tes drapeaux. Si voilà, ils sont ajoutés par un plugin automatiquement, tu peux les retirer et après, soit en tout cas ailleurs, je sais pas, ça peut être sur le header, tu vas pouvoir ajouter tes drapeaux dans le plugin, ça va être de pot filtre à poser et une fonction pour générer tes drapeaux. Tu utilises quel plugin ? Je... Je sais plus le nom. Polylang, WPML. Oui, Polylang, je crois que c'est celui-là. Et donc du coup, si j'ai bien compris, là, lui il intègre mes drapeaux dans le menu mais il le fait ça... Tu aurais une fonction dans Polylang pour enlever les drapeaux du menu. D'accord. Ok. Merci beaucoup. Bonjour. Par exemple, j'ai eu un problème sur WooCommerce où je cherchais un truc très simple et c'était un tel jeu de piste qu'au bout d'un moment, j'ai dit au client non, c'est bon, c'est bien comme ça. En fait, ce qui est bien dans le code de WooCommerce, c'est que non seulement ils vont te dire les filtres mais ils vont te mettre au-dessus tous les filtres utilisés, tous les callbacks et pareil pour les actions, ils vont dire à ce endroit donc il faut jouer beaucoup, beaucoup avec les removations dans WooCommerce. Si tu commences à partir dans l'héritage de template ça va pas du tout tenir la version. Il faut vraiment jouer qu'avec les hook dans WooCommerce si on veut que ça tienne dans le temps. D'accord. Et encore, des fois ça peut changer. Merci pour la conférence. J'ai une question, moi, par rapport quand tu fais une recherche à chaque fois tu mets ddaction plus d'eau de mettre addaction. Il faut pas tout taper, c'est juste un gain de temps. Si tu disais que je tape on, c'est une fonction. Si tu tapes juste on, ça peut être un return. Ddaction c'est parce que sinon si tu mettais que ddaction, ça pourrait être dit d'action. D'accord mais tu aurais pu taper addaction c'est vraiment... Après c'est un gain de temps, c'est-à-dire que moi je fais ça tout le temps c'est si tu tapes tout en entier à chaque fois, il n'y a pas besoin. Ok, merci. Bonjour. Je voulais savoir ce que tu utilises des outils particuliers pour savoir un petit peu l'ordre des déroulements des opérations parce que des fois c'est vrai qu'on arrive à trouver bon c'est ici mais il y a des actions, il y a des filtres qui ont modifié ça avant. Alors tu peux regarder un peu brutal, tu peux regarder la globale de l'enregistrement des filtres et des actions. J'ai utilisé des plugins récemment il y a Hooker qui a fait un plugin et en fait c'est... inutilisable parce qu'en fait on l'active sur WordPress et là on a 300 filtres réactions qui nous sautent à la tête. Donc on sait pas du tout qu'est-ce qui se déclenche. Après non, en général je teste en fait. Je teste ma priorité un petit peu au pifomètre avec soit des anti-assets bas, soit PHP Initmax pour passer par-dessus tout. Merci. Quand tu parcours un plugin admettons par exemple vous commerce à la recherche du filtre que tu aimerais qu'il existe si tu le trouves, tu es content mais s'il se trouve qu'il n'y a pas de filtres qui a été prévu, qu'est-ce que tu fais ? OBS start c'est mal. En fait je trouve un filtre au-dessus un petit OBS start et puis sur un filtre plus bas je vais faire un OBS get content donc les fonctions en fait qui vont déférer temporiser l'affichage de sortie et après je fais une regex. Voilà c'est très brutal et au commerce ça ne tient pas très bien parce qu'en plus des fois il change un petit peu le marquage il n'y a pas des fils partout mais c'est la seule méthode je trouve ou alors l'héritage de template mais ça ne va pas lui avoir dans le temps non plus. C'est-à-dire que chaque version t'oblige de repasser sur contemplates, de refaire tes changements pour être sûr de passer à côté de rien. Oui c'est vrai tout à fait tout ce que les versions sont assez régulières Moi je voulais juste rajouter peut-être parce que j'ai aussi galéré il y a 3 ans à peu près à chercher, chercher toujours où justement ça se modifie etc et j'ai découvert, alors c'est plus sur un tips pour tout le monde je pense c'est les logiciels type agrégateur de documentation notamment par exemple sur Mac, Dash qui permet justement quand tu commences à fouiner une fonction tu vas automatiquement rechercher dans le codex immédiatement qu'est-ce qu'elle fait qu'est-ce qu'elle prend comme paramètre pas d'une fois, c'est vrai il y a ça le développeur référence par exemple c'est vraiment une extraction de la documentation alors des fois elle est pas vraiment exhaustive je m'explique, elle va commenter ce qui se passe dans la fonction, enfin cette documentation elle va dire voilà il se passe ça t'as les fils qui ont été créés pour cette fonction mais des fois tu vas avoir gait option dedans gait option c'est un filtre tu peux le filtrer, tu peux le greffer dessus des fois tu vas appeler d'autres fonctions enfin d'autres fonctions vont être inclus et vont avoir d'autres fils qui vont pas être dans la doc et puis forcément tu perds le contexte tu sais pas vraiment on dit à quoi sert mais tu le vois pas tu sais pas ce qu'il y a avant, c'est pas ce qu'il y a après donc c'est pour ça que je préfère avoir le code en local mais effectivement si vous êtes habitué à Dash vous pouvez faire ça salut merci pour ta conférence du coup un participement à parler de Dash du coup j'imagine comme tout le monde c'est parfois un petit peu compliqué de se rappeler lors des paramètres d'une fonction etc est ce que tu utilises un IDE comme PHPStorm des choses que tu as testées qui te font de l'auto complétion ou qui te permettent du coup d'aller chercher dans une classe tu cliques sur une fonction et ils te ramènent à la classe correspondance etc ou tu as testé des choses j'ai testé mais voilà je suis plus à l'aise en fait avec le code bruit dans sublime texte j'ai testé au PHPStorm après c'est vraiment pour les dev qui font que du bac je trouve après c'est avec avec vos habitudes chacun a son éditeur de préférence vous pouvez tester les IDE si ça vous convient vous pouvez faire la même chose et du coup dans sublime est-ce que tu as aussi un plugin ou un atome qui t'aide à résoudre sur les choses j'ai pas été voir il y a quand même beaucoup de plugins sublime texte je pense atome c'est sûr merci moi personnellement sur Mac j'utilise CODA et sur CODA il y a un plugin on peut installer un petit plugin WordPress qui fait l'autocompression sur les fonctions et quand on acte l'autocompression ça nous sort les 3-4 paramètres qui sont à fournir à la fonction mais ça nous renvoie pas sur une doc enfin ma connaissance ça ne renvoie pas sur une doc ou sur des fichiers WordPress en tout cas on a le nom de la fonction et les 4-5 paramètres s'il y en a ouais bon bah merci beaucoup pour vous très coûte alors merci