Je suis juste curieux : y a-t-il des raisons spécifiques pour lesquelles le plugin “cakeday” a été désactivé ici ?
1 « J'aime »
C’est ta faute 
1 « J'aime »
Alors, la solution pour désactiver le plugin sur les forums qui n’utilisaient pas cakeday auparavant, est de désactiver cakeday sur les forums qui utilisent cakeday depuis des années ?
1 « J'aime »
Je pense que les choses ont mal tourné.
Voici la migration n°1, qui a été commentée 
. Comment peut-on savoir si elle a été exécutée sur chaque instance ?
Cette migration a persisté SiteSetting.cakeday_enabled dans la base de données.
Voici une migration de nettoyage qui supprime ce paramètre s’il a été créé autour du moment où la migration n°1 a été exécutée. Ce qui semble un peu louche mais bon, ça marche ÉDIT : non, ça ne marche pas.
Donc maintenant, il revient à la valeur par défaut qui est maintenant… désactivée ?
Les choses ont mal tourné. C’était louche et ça n’a pas fonctionné.
Je viens d’exécuter une mise à jour du site Discourse et je n’ai pas pu dépasser la migration de nettoyage dont vous parlez.
Cette migration plante. discourse/plugins/discourse-cakeday/db/migrate/20251127125226_delete_old_default_values.rb at main · discourse/discourse · GitHub
Lorsque la migration exécute migration_timestamp("20250717093505") et migration_timestamp("20250811132217") à partir de la méthode up, vous obtenez des valeurs nil. Ces valeurs nil cassent la requête SQL dans la méthode delete_settings de la migration.
Je vais déplacer ceci vers Bug en espérant que cela attire plus d’attention.
1 « J'aime »