• Three Ways phpMyAdmin Saves Your WordPress Site and Your Sanity

    phpMyAdmin, c’est un peu l’outil qu’on oublie jusqu’au moment où tout part en vrille. L’article rappelle trois trucs super pratiques : corriger les URL cassées après une migration (parce qu’on a tous déjà galéré avec ça), nettoyer les révisions qui bouffent la base, et réparer les tables corrompues en deux clics. Ce qui me plaît, c’est que c’est direct et sans bullshit. Pas de plugin miracle à installer, juste une connexion à la base et quelques requêtes SQL bien senties. C’est le genre de conseil qu’on donne à un pote qui flippe devant son site planté. Bon, évidemment, faut pas jouer avec la base les yeux fermés. Backup d’abord, explore ensuite. Mais franchement, phpMyAdmin reste un couteau suisse indispensable quand WordPress fait sa crise. Ça rassure de savoir qu’on peut encore mettre les mains dans le cambouis.
  • 8 février 2026 à 21:20

    En parcourant mon reader RSS, je suis tombé sur cet article https://www.alwaystwisted.com/articles/ive-been-compiling-my-sass-wrong-for-years et ça m’a fait réaliser que j’avais moi aussi ce warning quand je compile mes SCSS au boulot. Premier truc que je ferai en arrivant demain matin !
  • CSS @scope: An Alternative To Naming Conventions​​​​​​​​​​​​​​​​

    Alors là, je dois dire que @scope me parle vraiment. J’ai passé des années à jongler avec BEM, SMACSS, et toutes ces conventions de nommage qui finissent par te donner l’impression d’écrire du morse plutôt que du CSS. L’idée de pouvoir scoper du CSS natif sans avoir à préfixer chaque classe avec le nom du composant trois fois, c’est exactement ce qu’il me fallait.

    Ce qui me botte, c’est que ça reste lisible. Pas de .card__header–modifier à rallonge. Juste du CSS qui dit clairement “ça s’applique dans ce contexte, point final”. Et le support navigateur est déjà là pour une bonne partie. Bon, évidemment, il faut un peu de temps pour que tout le monde suive, mais l’approche progressive me va bien.

    Je pense tester ça sur mon prochain side project, histoire de voir comment ça se comporte dans la vraie vie. Parce qu’en vrai, les conventions c’est bien, mais si le langage peut gérer le problème nativement, pourquoi se compliquer la vie ?

  • Windsurf et moi : journal d’un dev qui apprend à parler à une IA

    Ça fait deux semaines que j’utilise Windsurf pour développer un plugin WordPress.
    Le principe ? Ajouter des options sur les blocs Gutenberg natifs (en React/JSX), et gérer des Custom Post Types proprement.

    Rien de dingue sur le papier.
    Mais en vrai, c’est le genre de projet où tu te retrouves vite avec du code front mélangé au code métier, des fichiers qui grossissent, et un moment où tu te demandes « mais pourquoi j’ai foutu ça là ? ».

    Avant, j’aurais passé une journée entière à refactoriser pour que ce soit propre.
    Là, j’ai tenté de faire équipe avec l’IA.

    Spoiler : c’est ni parfait, ni magique. Mais franchement, c’est troublant.

    Le moment où j’ai compris que c’était différent

    Au début, je lui ai juste balancé :

    « J’ai du code pour étendre des blocs Gutenberg. Aide-moi à séparer proprement le front-end de la logique métier. »

    Windsurf ne m’a pas juste craché trois suggestions de fonctions.
    Il a réorganisé des fichiers.
    Il a créé des dossiers, proposé une archi, déplacé du code React d’un côté, les enregistrements de CPT de l’autre.

    Pas parfait, hein. Mais cohérent.

    Et moi, pendant ce temps, je ne codais presque pas.
    Je lisais, je validais, je virais ce qui ne me plaisait pas.

    C’est là que j’ai senti le truc : je n’étais plus vraiment en train de « coder ».
    J’étais en train de piloter.

    Font Awesome sur les boutons : ou comment j’ai réécrit mes prompts 15 fois

    Le truc qui m’a le plus pris la tête, c’est l’ajout d’icônes Font Awesome sur les blocs core/button.

    Sur le papier, c’est simple :
    tu rajoutes un control dans le panneau Gutenberg, tu laisses l’utilisateur choisir une icône, tu l’affiches côté front avec la bonne classe Font Awesome.

    Dans la réalité ?
    Windsurf m’a sorti :

    • Des contrôles Gutenberg qui ne compilaient pas.
    • Des attributs qui disparaissaient au save/reload.
    • Du JSX bancal avec des icônes qui se dupliquaient ou qui partaient dans le mauvais sens.
    • Une fois, il m’a même proposé d’importer tout Font Awesome en JS côté éditeur (merci, mais non).

    Le problème, c’est que je lui demandais des trucs trop vagues.
    Genre :

    « Ajoute une option pour choisir une icône Font Awesome. »

    Résultat : il partait dans tous les sens.

    J’ai dû affiner. Beaucoup.
    Jusqu’à arriver à des prompts du style :

    « Ajoute un SelectControl dans InspectorControls pour choisir parmi 5 icônes Font Awesome.
    L’attribut doit s’appeler faIcon, de type string.
    L’icône doit s’afficher avant le texte du bouton, côté front uniquement, avec la classe fa-solid fa-{nomIcone}. »

    Là, ça commençait à tourner.

    Mais j’ai quand même dû tout recommencer à zéro une fois, parce qu’il m’avait généré une logique tellement tordue que je ne m’y retrouvais plus.

    Ce que j’ai appris : parler à une IA, c’est un métier

    Ce qui m’a le plus marqué, c’est à quel point la façon dont tu poses la question change tout.

    Si tu dis :
    « Fais-moi un truc pour gérer des icônes »,
    tu obtiens du code générique, verbeux, à moitié cassé.

    Si tu dis :
    « Crée un attribut faIcon de type string, ajoute un SelectControl avec 5 options fixes, affiche l’icône en <i> avec la classe correspondante dans le RichText »,
    là, ça roule.

    Et ça, pour moi, c’est nouveau.
    Avant, coder, c’était : je sais ce que je veux, je le tape.
    Maintenant, c’est : je sais ce que je veux, j’apprends à le formuler pour qu’une IA le fasse.

    C’est presque un exercice de specs en temps réel.
    Et franchement, ça m’a forcé à être plus clair dans ma tête sur ce que je voulais vraiment.

    La structure du plugin : là où l’IA m’a vraiment aidé

    Ce qui est cool, c’est que Windsurf m’a aidé à mettre en place une archi propre dès le début.

    Avant, j’aurais fait un gros index.php, un dossier assets, et je me serais dit « je rangerai plus tard ».
    Jamais fait, évidemment.

    Là, il m’a proposé direct :

    • Un dossier src/blocks pour tout le code React/JSX qui étend les blocs Gutenberg.
    • Un dossier includes pour les CPT et la logique métier.
    • Un build propre avec webpack (enfin… plus ou moins propre, j’ai dû ajuster).
    • Une séparation claire entre ce qui tourne côté éditeur et ce qui se charge côté front.

    C’est pas révolutionnaire.
    Mais c’est exactement ce que j’aurais dû faire depuis le début, et que je faisais jamais par flemme.

    L’IA m’a forcé à être structuré dès le départ, parce qu’elle avait besoin de comprendre où mettre les fichiers.

    Et résultat : mon code est plus maintenable. Plus facile à relire. Moins bordélique.

    Les moments de frustration (parce qu’il y en a)

    Je ne vais pas mentir : il y a eu des phases où j’ai eu envie de tout fermer et de retourner coder comme avant.

    Genre :

    • Quand l’IA me modifiait 4 fichiers alors que je lui avais demandé d’en toucher qu’un.
    • Quand elle « corrigeait » du JSX qui marchait très bien, merci.
    • Quand elle m’inventait des hooks React qui n’existent pas, et que je perdais 20 minutes à comprendre pourquoi ça plantait.

    Il y a aussi ce moment bizarre où tu te rends compte que tu lis plus de code que tu n’en écris.
    Et parfois, ça frustre.
    Parce que coder, c’est pas juste produire du code. C’est aussi réfléchir, tâtonner, trouver des solutions.

    Avec l’IA, tu sautes une partie de ce process.
    Des fois c’est génial.
    Des fois, tu te sens un peu… spectateur.

    Ce que je retiens après deux semaines

    Windsurf, c’est un outil de structure avant tout.
    Il te force à penser ton projet proprement, parce qu’il a besoin de comprendre où il met les pieds.

    C’est aussi un amplificateur de clarté mentale.
    Si tu ne sais pas vraiment ce que tu veux, il va partir en vrille.
    Si tu es clair, il va vite.

    Mais ça reste un assistant, pas un dev.
    Tu ne peux pas lui laisser la main sur tout.
    Surtout si tu fais du React/JSX un peu poussé, ou si tu touches à des trucs sensibles (attributs Gutenberg, save/edit, etc.).

    Le truc à retenir ?
    L’IA produit le squelette. Toi, tu mets la chair.

    Et franchement, pour l’instant, ça me va bien comme ça.

    Et toi, t’en es où ?

    Je suis curieux de savoir si d’autres devs WordPress ont testé ce genre d’outils sur des projets Gutenberg.
    Parce que franchement, entre le JSX, les attributs, le save vs edit, et tout le bordel de la compilation… c’est pas toujours évident de savoir ce qu’on peut déléguer à l’IA et ce qu’il vaut mieux garder sous contrôle.

    Si t’as des retours d’expérience, des prompts qui marchent bien (ou qui partent complètement en couille), ou juste une opinion tranchée sur le fait de coder avec une IA, balance-moi ça.

    Parce qu’au fond, on est tous un peu en train d’apprendre ensemble comment bosser avec ces trucs-là.
    Et autant partager les galères, non ?

  • dimanche 01 février 2026 @ 12:15:02

    J’ai fais le fifou ce week-end ! J’en avais un peu marre des couleurs de mon blog, alors j’ai un tout petit peu rafraîchi tout ça ! Et en prime j’ai utilisé ma couleur préférée #vismavie #osef

  • Accessible faux nested interactive controls

    Andy Bell propose une solution élégante pour contourner l’interdiction HTML d’imbriquer des éléments interactifs : créer une fausse zone cliquable qui reste accessible. L’idée, c’est d’utiliser un pseudo-élément positionné en absolu qui couvre toute la card, tout en gardant les vrais boutons ou liens interactifs au-dessus via z-index. Ça évite le balisage dégueu avec des <div> cliquables partout.

    Ce qui me plaît, c’est que ça reste propre côté DOM et que l’accessibilité n’est pas sacrifiée sur l’autel du design. Pas de role="button" sur des trucs qui n’en sont pas, pas de JavaScript tarabiscoté pour gérer les clics. Juste du CSS malin et un peu de réflexion sur la hiérarchie des interactions.

    Bon, faut quand même faire gaffe : si tu multiplies les zones cliquables imbriquées, ça peut vite devenir le bordel pour l’utilisateur. Mais pour une card avec un lien principal et quelques actions secondaires, c’est nickel. Andy donne même un exemple concret avec du code commenté, ce qui aide à bien piger la mécanique. Bref, une technique à garder dans un coin.

  • Date is out and Temporal is in

    On a tous galéré avec `Date()` en JavaScript. Les fuseaux horaires qui décalent tout, les calculs foireux, les librairies tierces pour compenser. Bref, un bordel.

    Temporal arrive enfin pour régler ça. Une API moderne, pensée dès le départ pour gérer proprement les dates, heures, durées et fuseaux. Fini de bidouiller avec des +86400000 pour ajouter un jour, fini les bugs silencieux quand on change de timezone.

    Ce qui me plaît surtout, c’est la clarté : `Temporal.PlainDate`, `Temporal.ZonedDateTime`, `Temporal.Duration`… Chaque type a son rôle, pas d’ambiguïté. Tu sais ce que tu manipules. Et les méthodes sont intuitives, cohérentes.

    Le support navigateur progresse doucement, mais ça vaut le coup de s’y intéresser maintenant. Parce que franchement, quand ça sera là partout, on se demandera comment on a pu vivre avec l’ancien système.

  • Web development tip: disable pointer events on link images

    Quand j’ai lu le billet du gars de LapcatSoftware, j’ai eu ce petit frisson “yeah, ça, ça a du sens”.

    Il explique qu’il vaut mieux désactiver les pointer-events sur les images utilisées comme liens — notamment les badges “Download on the App Store”. Sur iOS, la feature « Live Text » crée un bordel : quand tu tapes longuement sur l’image, tu tombes sur… la sélection de texte, pas le lien. Résultat, l’UX est foirée pour les utilisateurs de Safari iOS. 

    Alors le taf, c’est simple : tu rends l’image non-clickable (pointer-events: none;) et tu t’assures que l’anchor parent a un display: inline-block — comme ça le lien est cliquable sur toute la surface de l’image, comme un lien normal. 

    Moi ce que j’aime, c’est ce genre de petit coup de polish à la dev front-end : ça prend 2 secondes, mais ça améliore l’expérience utilisateur — surtout sur mobile. Si t’es comme moi, “pixel perfect” ça te parle. Le genre de détail qu’on zappe souvent, mais qui compte.

  • Programming principles for self-taught front-end developers

    Andy Bell balance des principes solides pour les autodidactes du front. J’aime bien son approche parce qu’elle casse l’idée qu’il faut tout savoir pour être légitime. Il insiste sur la simplicité d’abord, les fondamentaux avant les frameworks, et surtout : résoudre des vrais problèmes plutôt que d’accumuler des technos sur son CV.

    Ce qui me parle le plus, c’est son conseil de pas se laisser impressionner par la complexité des autres. On a tous tendance à croire que les devs « officiels » maîtrisent tout sur le bout des doigts, alors qu’en vrai, personne ne sait tout. L’impostor syndrome, ça touche tout le monde, diplômé ou pas.

    Il rappelle aussi qu’être autodidacte, c’est souvent avoir développé une capacité d’apprentissage autonome qui vaut de l’or. Ça forge une débrouillardise que les cursus classiques n’offrent pas toujours. Bref, un article qui fait du bien à l’ego et qui recentre sur l’essentiel : construire des trucs qui marchent, proprement.

  • Your URL Is Your State

    Ce billet m’a rappelé que les URLs, c’est pas juste un truc pour afficher une page, c’est carrément un système de gestion d’état vieux comme le web. Genre, la magie, c’est que l’URL encode tout ce dont on a besoin pour retrouver une config précise, un filtre, un état d’interface, sans base de données ou cookies. Le gars prend pas mal d’exemples concrets : PrismJS avec la config dans l’URL, GitHub qui cible des lignes précis, Google Maps, Figma… Bref, on peut tout partager et retrouver à l’identique. C’est con comme chou, mais tellement sous-estimé.

    L’article insiste aussi sur le fait que faut pas mettre n’importe quoi dans l’URL (pas d’info sensible ou de data super complexe), et qu’on doit faire suivre des bonnes pratiques genre éviter d’y mettre des valeurs par défaut ou d’écraser l’historique navigateur avec des méthodes mal choisies. Au final, l’URL c’est pas juste une adresse, c’est une part de l’expérience utilisateur, un contrat clair entre appli et utilisateurs. Une piqûre de rappel utile pour tous ceux qui codent du front et oublient parfois que la vieille URL a encore un truc à leur apprendre.