Ç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 ?

Je n’en peux plus de mon blog dans son état actuel.

Quand je suis repassé sous WordPress, je me suis empressé d’installer un thème et des plugins me permettant de garder à peut prêt les mêmes fonctionnalités « IndieWeb » que j’avais réussi à mettre en place sur mon installation Jekyll.

À peu prêt 6 mois plus tard, j’en viens à penser qu’installer le plugin Post Kinds, qui ne supporte toujours pas les blocs de contenus de Gutenberg, l’éditeur actuel de WordPress, était en fait le mauvais move.

J’aime ce que je publie sur mon blog, je suis à l’aise avec le fait qu’il y ait beaucoup plus de contenus relatifs à ma vie personnelle que d’articles à propos de développement Web, mais je trouve que tout ce que j’avais mis en place pour « faire partie de l’IndieWeb », au final c’est du gros bullshit.

J’ai envie de revenir à l’essentiel. Un WordPress « basique », sans plugins qui modifient la façon dont Automattic et Matt Mullenweg ont pensé la rédaction de contenus. J’ai adoré l’époque où WordPress était « concurrencé » par Tumblr, ça a permis l’arrivée de ce qui pour moi a toujours était une fonctionnalité géniale : les formats d’articles.

Mon erreur, lorsque je suis repassé sur WordPress, ça a été de me précipiter. Alors oui, ça m’a permis de bloguer plus facilement et plus souvent, j’en suis ravi. Mais le fait est que le thème SemPress que j’utilisai, avant de changer pour Twenty Twenty-Four ces dernières semaines, faisait le taff même si visuellement il n’est pas top.

Je pense qu’il est grand temps pour moi créer un thème WordPress par moi même, plutôt que de me reposer sur un thème qui ne répond plus à mon besoin ou de perdre du temps à en chercher un qui me convienne.

Twenty Twenty-Four n’est pas idéal, mais ça reste un thème plutôt propre et peut-être une bonne base pour commencer mon propre thème

On se quitte là dessus pour aujourd’hui

Suite à tous mes posts de ce matin, j’ai cherché une façon de générer un titre à mes notes, que je publie généralement via la Web app quill.p3k.io développée par Aaron Pareki.

Il existe de nombreux filtres pour agir sur le contenu d’un post ou d’une page, mais la plupart sont exécutés à l’affichage comme the_title ou the_content, ou encore à la modification comme le filtre save_post.

On pourrait très bien générer notre titre après l’enregistrement dans la base de données, mais dans mon cas je souhaitais définir le titre et le permalien avant, simplement pour éviter que le partage sur Mastodon se fasse sans titre défini dans les metadonnées utilisées par OpenGraph.

Heureusement, il existe un filtre sur lequel agir pour ça : wp_insert_post_data.

Voici comment j’ai reussi :

function generate_post_title($data)
{
    if (empty($data['post_title'])) {

        $content = $data['post_content'];

        $pieces = explode(" ", $content);
        $first_part = implode(" ", array_splice($pieces, 0, 5));

        $data['post_title'] = $first_part; // Defines post title
        $data['post_name'] = sanitize_title($first_part); // Defines post slug
    }
    return $data; // Returns the modified data.
}
add_filter('wp_insert_post_data', 'generate_post_title', '99', 1);

Je pourrais toujours l’améliorer par la suite, par exemple :

• en prenant la première phrase de mon contenu, plutôt que les cinq premiers mots actuellement,
• en ajoutant des points de suspensions lorsque la première phrase dépasse les six mots.

J’espère que ce petit morceau de code vous aidera.

Il y a quelques jours, je travaillais sur l’intégration d’un design dans le système de blog WordPress, plateforme que j’utilise notamment ici. Dans ma charte graphique, chaque élément du menu de navigation est suivi d’une petite phrase expliquant ce que l’on trouvera dans la page lié. J’avais décidé d’enregistrer ces phrases dans un champ personnalisé pour pouvoir l’afficher très simplement et rapidement avec l’une des fonctions qu’intègre WordPress comme wp_page_menu() ou wp_list_page().

Malheureusement, comme me l’a confirmé mon ami @clawfire, ces deux fonctions n’entrent pas dans ce qu’on appelle la Boucle ou Loop dans le jargon WP, il me fallait donc coder moi même l’affichage du menu intégrant ce champ personnalisé. Voilà la marche à suivre

Sur quelles tables de la base de données doit on travailler?

D’abord il faut savoir dans quelles tables sont enregistrés les données qui nous intéresses.  On remarquera que WordPress enregistre les données d’un article dans la table wp_posts, et la table wp_postmeta enregistre d’autres informations moins primordiales comme par exemple quel modèle de page utilise l’article, ET les différents champs personnalisés attachés à l’article.

Au boulot!

Maintenant qu’on sait sur quoi faire notre requête SQL, il est temps de passer à la programmation!

try{

$db = new PDO('mysql:dbname=database;host=localhost','root','pass');

} catch(PDOException $e){

echo "connexion echoué : ".$e->getMessage();

}

//on récupère l'ID de la page statique qui sert de page d'accueil du site

$strHomepage = "SELECT option_value FROM wp_options WHERE option_name = 'page_on_front'";

$stmt = $db->prepare($strHomepage);

$stmt->execute();

$home_id = $stmt->fetch(PDO::FETCH_OBJ)->option_value;

//on récupère la valeur de l'option siteurl

$strHomeUrl = "SELECT option_value FROM wp_options WHERE option_name = 'siteurl'";

$stmt = $db->prepare($strHomeUrl);

$stmt->execute();

$home_url = $stmt->fetch(PDO::FETCH_OBJ)->option_value;

//on récupère les infos neccessaires à l'affichage du menu avec la taglines

$strTagline = "SELECT * FROM wp_posts p, wp_postmeta m WHERE p.ID = m.post_id

AND meta_key = 'nav_tagline' AND post_parent = 0

AND post_type ='page' AND post_status = 'publish'

ORDER BY menu_order ASC";

//echo $home_id;

$stmt = $db->prepare($strTagline);

$stmt->execute();

echo "<ul>";

while($r = $stmt->fetch()){

if($r['ID'] == $home_id){

} else {

echo "<li><a href='".$home_url."/?page_id=".$r['ID']."'>".$r['post_title']."<span>".$r['meta_value']."</span></a></li>";

}

}

echo "<ul>";

Et voilà, notre menu avec un custom field est terminé!