Publier vers le site en production
Exécutez wpsync avec ${CLAUDE_PLUGIN_ROOT}/bin/wpsync, dans le dossier du site. Démarrez un
chapitre "Publication" et la liste de vérification de publication depuis
${CLAUDE_PLUGIN_ROOT}/skills/wp-dev/guiding.md, et demandez comme indiqué.
La publication remplace tout le site en production (base de données et fichiers) par la copie locale. Les fichiers
wp-config.php, .htaccess et ceux ajoutés par l'hébergeur sur le site live sont conservés. Les modifications
apportées par les utilisateurs sur le site live depuis la dernière synchronisation sont perdues.
- Wordfence : si
wpsync status --jsonaffiche"wordfence": "back-on", suivez maintenant${CLAUDE_PLUGIN_ROOT}/skills/wp-dev/wordfence.md("Avant"). Il doit rester désactivé jusqu'à ce que la publication soit finalisée ou annulée ; puis suivez sa section "Quand wpsync est terminé" pour le réactiver. - Commitez d'abord. wpsync refuse de publier du code non commité. Si
git statusmontre des modifications, listez-les et demandez : Les commiter (Recommandé : vous écrivez un message décrivant la modification), ou Arrêter (rien n'est publié). - Essai à sec :
wpsync push --dry-run. Affichez au développeur son résumé sous forme de tableau : taille de la base de données, fichiers à uploader et à supprimer, plugins ajoutés, supprimés ou mis à jour, et toute modification live depuis la dernière synchronisation (articles, pages, commentaires, nouveaux utilisateurs). Si le live a des modifications, demandez, en les nommant : "Le site live a des modifications depuis la dernière synchronisation que la publication effacerait. Que devons-nous faire ?" : Les récupérer d'abord (Recommandé : mais la récupération remplace le contenu local, donc le contenu créé localement doit être refait), Publier quand même (ces modifications live sont perdues), ou Arrêter. - Demandez un oui clair, en nommant le site : "Publier la copie locale vers maintenant ? Cela remplace tout le site live ; vous pouvez annuler avec un retour arrière jusqu'à la finalisation." : Publier , ou Pas encore. Seul Publier est un oui.
- Publier :
wpsync push, en tant que tâche longue (guiding.md). Il affiche le même résumé dans une boîte de dialogue macOS, et ne continue que lorsque le développeur tape le domaine live dans cette boîte. Dites-leur que la boîte de dialogue arrive, qu'elle peut s'ouvrir derrière d'autres fenêtres, et que vous ne pouvez pas y répondre. Il sauvegarde ensuite ce qui va changer dansbackups/, uploade, remplace tout, et vérifie les pages clés. Si la vérification échoue, il remet l'ancien site tout seul et le signale. - Vérifiez vous-même le live : ouvrez la page d'accueil et les pages touchées par le changement dans le navigateur, et montrez-les au développeur.
- Le live conserve la version précédente jusqu'à la finalisation. Demandez "Comment se présente le site live ?" :
- Ça a l'air bien, gardez les deux pour l'instant (Recommandé) : rien ne se passe de plus ; l'annulation reste disponible. Rappelez-leur qu'ils peuvent dire "finaliser" ou "annuler" plus tard.
- Quelque chose ne va pas, annuler :
wpsync rollback(une boîte de dialogue macOS demande au développeur de confirmer) restaure le site live précédent. - Tout va bien, finaliser :
wpsync finalize(également confirmé dans une boîte de dialogue macOS) supprime la copie sauvegardée sur le serveur. Après cela, l'annulation n'est plus possible ;backups/conserve toujours une copie locale.
Avant de publier, wpsync vérifie à nouveau que sa clé fonctionne toujours et que le serveur dispose d'espace (environ le double de la taille du site). Si l'un ou l'autre échoue, dites ce qui a été rapporté et arrêtez.