Cadre de script pour réorganiser les sujets et les catégories

Wiki de la communauté Adminsys
1

Pour pouvoir réorganiser un grand Discourse en collaboration avec la direction de mon site, j’ai écrit un framework simple pour regrouper un tas de petits scripts Ruby qui seront pilotés par un fichier de configuration YAML. De cette façon, je peux restaurer une sauvegarde sur un site de staging, exécuter mon script, obtenir des retours, modifier quelques lignes de YAML, restaurer la sauvegarde, exécuter le script avec la nouvelle configuration, et répéter jusqu’à satisfaction.

J’ai près de 600 lignes de configuration pour mon site, et le faire manuellement via l’interface utilisateur n’aurait tout simplement pas été possible. Pas une seule fois, et encore moins plusieurs fois pour bien faire les choses. Je le sais car la dernière fois que j’ai proposé d’apporter des changements majeurs, j’ai littéralement abandonné en essayant. En revanche, avec ce script, je peux maintenant réaliser le cycle complet en quelques minutes par itération, même si le site compte environ un demi-million de messages et plus de 100 catégories. Cela me permet d’obtenir des retours rapides de la part de la direction de mon site, et je serai prêt à migrer mon site rapidement.

Une documentation plus détaillée se trouve dans le fichier README du dépôt contenant le code :

:warning: Ce script ne fait aucune vérification d’erreurs. Il est tout à fait déraisonnable de l’exécuter sur votre site en production. Il est conçu pour être exécuté sur un site de staging, valider le résultat, puis être déployé en production. En tant qu’auteur, j’ai toujours l’intention de l’exécuter de cette manière. Si vous l’exécutez directement sur un site en production, vous devrez en assumer toutes les conséquences en cas de problème. :warning:

D’après la documentation, un fichier de configuration pourrait ressembler à ceci :

---
- describe:
    context: Ancien Nom
    category: 7
    name: Nouveau Nom
    description: Nouvelle description de la catégorie
    slug: nouveau-slug
- movePosts:
    context: déplacer uniquement les messages faq de la catégorie Support vers la catégorie Documentation
    source: 3 # ID de la catégorie Support
    target: 6 # ID de la catégorie Documentation
    withTag: faq
    hide: false # ne pas masquer la catégorie Support une fois terminé
- movePosts:
    context: consolider la catégorie Tutoriels dans la documentation avec le tag tutoriel
    source: 8 # ID de la catégorie Tutoriels
    target: 6 # ID de la catégorie Documentation
    addTag: how-to
    hide: true # masquer l'ancienne catégorie Tutoriels, visible uniquement par l'administrateur

La sortie de progression pendant son exécution pourrait alors ressembler à ceci.

==========
Déplacer les catégories masquées pour qu'elles n'encombrent pas la vue admin
setHiddenCategory: {:category=>11}
==========
Renommer Ancien Nom en Nouveau Nom
describe: {:category=>7, :name=>"Nouveau Nom", :description=>"Nouvelle description de la catégorie", :slug=>"nouveau-slug"}
==========
déplacer uniquement les messages faq de la catégorie Support vers la catégorie Documentation
movePosts: {:source=>3, :withTag=>"faq", :target=>6}
==========

Pour l’utiliser, placez votre fichier YAML dans /var/discourse/shared/app/tmp/rearrange.yaml puis :

cd /var/discourse
./launcher enter app
git clone https://github.com/johnsonm/discourse-site-rearranger.git script/discourse-site-rearranger
ruby script/discourse-site-rearranger/rearrange.rb /shared/tmp/rearrange.yaml

Cependant, il est fort probable que ce script ne fasse pas exactement tout ce dont vous avez besoin. C’est vraiment un framework qui rend très facile l’ajout de nouvelles actions automatisant davantage d’aspects d’une modification de site scriptée avec seulement quelques lignes de code. Il vous suffit de définir une méthode avec quelques lignes de code, et vous pourrez l’appeler correctement depuis le fichier YAML.

Avez-vous pensé à améliorer l’organisation de votre site, mais vous reculez devant l’utilisation de l’interface utilisateur, ou vous demandez-vous comment vous assurer que vous pourrez reproduire vos tests sur un site de staging pour déployer les changements en production ? Jetez-y un œil et dites-moi ce que vous en pensez !

5 « J'aime »
5

J’utilise ce script pour créer un site de test, en tant que clone de mon site principal. Une haute fidélité visuelle fait partie de l’intérêt, mais pourrait rendre facile la publication accidentelle sur le mauvais site lors de la révision des modifications, et faire disparaître ces publications accidentelles la prochaine fois que je rafraîchirai le site de test.

J’avais d’abord rendu mon site de test en lecture seule lorsque j’ai demandé des commentaires publics. Mais la connexion est désactivée lorsque le site est en mode lecture seule, ils ne pouvaient donc pas se connecter lorsque je leur ai demandé de le faire.

J’ai ajouté une nouvelle action publicCategoriesReadonly qui rend les catégories visiblement publiques inscriptibles uniquement par les :admins et en lecture seule par :everyone afin de permettre aux gens de se connecter et d’explorer, mais d’éviter de publier accidentellement sur le mauvais site. Maintenant, le site dans son ensemble n’est pas en mode lecture seule, mais les catégories publiques le sont.

6

Il est possible de référencer des catégories sous forme de hashtags par leurs slugs. Ce script permet de déplacer le contenu des catégories ensemble et de modifier les slugs, ce qui rendrait les anciens messages non liés après un nouveau “rebake”. (Avant un “rebake”, les redirections de permaliens permettraient aux liens de fonctionner.)

J’ai maintenant mis à jour le script pour suivre les tags avant et après la migration et pour remapper les références aux catégories modifiées dans les messages.

7

J’ai ajouté une action migrateRetortToReactions au framework pour ceux d’entre nous qui ont installé Retort et souhaitent passer à un plugin pris en charge.

2 « J'aime »
8

Génial ! C’est une excellente nouvelle. Ce serait formidable si quelqu’un pouvait en faire une tâche rake et la soumettre au plugin de réactions.

Je vais y jeter un œil bientôt.

1 « J'aime »
9

Le fait que ce soit une tâche rake dans le plugin me semble judicieux.

J’ai signé le CLA de CDCK, donc tout intérêt de ma part concernant les droits d’auteur sur le travail résultant ne fera pas obstacle, et il pourra être placé sous la même licence que le plugin lui-même.

De plus, j’imagine que j’ai pu me tromper sur certains points ; si vous trouvez quelque chose d’incorrect, j’aimerais beaucoup le savoir car j’ai l’intention d’exécuter ce script sur mon propre site dans les prochaines semaines. :smiley:

À plus grande échelle, si vous trouvez ce framework utile pour votre propre travail de support des installations Discourse mais que vous souhaitez une meilleure gestion des erreurs, j’accepterai les PRs. Je veux simplement m’assurer que toute PR qui y est soumise provient de quelqu’un qui a signé le CLA et accepte que toute partie utile puisse être incorporée à Discourse officiel, ce qui est vrai pour vous, je le sais…

2 « J'aime »
10

J’ai découvert dans le sujet Retort que @angus avait une branche avec une conversion pilotée par l’interface utilisateur, que j’avais complètement manquée.

Mon script plonge dans les détails internes qui pourraient potentiellement changer un jour, et une fois que j’aurai effectué mes conversions avec ce script, je ne remarquerai pas si ces détails internes changent. J’ai d’abord essayé de faire les choses « de la bonne manière », mais j’ai découvert que le plugin Reactions n’expose pas d’interface qui le permette. @angus adopte une vision à plus long terme :

@pfaffman si vous créez une tâche rake, vous voudrez peut-être la mettre dans une PR qui apporte également les modifications aux interfaces afin que, par exemple, created_by puisse être passé, ainsi que silencieux, plutôt que d’utiliser la « porte dérobée » que j’ai utilisée. À ce stade, la tâche rake serait là pour les migrations en ligne de commande, et elle permettrait simultanément à @angus d’effectuer une migration pilotée par l’interface utilisateur.