I’m just curious: are there specific reasons why the cakeday plugin has been deactivated here?
This is your fault ![]()
So, the solution for disabling the plugin on forums that didn’t use cakeday before is to disable cakeday on forums that have been using cakeday for years? Is there no way to leave the settings of forums that used it before untouched?
I think things just went south.
Here’s migration #1, which has been commented out
.
How can one know whether it has been ran on every instance?
So that migration persisted SiteSetting.cakeday_enabled into the database.
Here’s a clean up migration which deletes that setting if it was made around the time migration #1 was executed. Which looks a bit sketchy but hey, it works EDIT it doesn’t.
So now it falls back to default which is now… off ?
Things did go south. It was sketchy and did not work.
I just ran a Discourse site update and couldn’t get past the clean up migration you’re talking about.
This migration is crashing out. discourse/plugins/discourse-cakeday/db/migrate/20251127125226_delete_old_default_values.rb at main · discourse/discourse · GitHub
When the migration runs migration_timestamp("20250717093505") and migration_timestamp("20250811132217") from the up method you get nil values. Those nil values break the sql query in the delete_settings method of the migration.
Probably because the migration it refers to has been commented out.
I’ve always been taught that migrations should never be modified afterwards. This is why.
I’m going to move this to Bug hoping it gets more eyeballs…