궁금한 점이 하나 있습니다: cakeday 플러그인이 여기에서 비활성화된 특별한 이유가 있나요?
1개의 좋아요
이건 네 탓이야 
1개의 좋아요
그러니까, cakeday를 이전부터 사용하지 않던 포럼에서 플러그인을 비활성화하는 해결책은, 수년 동안 cakeday를 사용해 온 포럼에서 cakeday를 비활성화하라는 건가요? 이전에 cakeday를 사용했던 포럼의 설정을 그대로 두는 방법이 없나요?
1개의 좋아요
일이 좀 꼬인 것 같습니다.
마이그레이션 #1은 주석 처리되어 있습니다 
.
모든 인스턴스에서 실행되었는지 어떻게 알 수 있을까요?
해당 마이그레이션은 SiteSetting.cakeday_enabled 값을 데이터베이스에 영구적으로 저장했습니다.
정리용 마이그레이션은 마이그레이션 #1이 실행된 시점 근처에 생성된 설정이라면 해당 설정을 삭제합니다. 이 부분은 좀 불안해 보이는데 하지만 어쨌든 작동하긴 합니다 수정: 작동하지 않습니다.
이제 기본값으로 되돌아갔는데, 기본값은 이제… 꺼져 있습니다?
사정은 좋지 않았습니다. 불안정했고 작동하지도 않았습니다.
방금 Discourse 사이트 업데이트를 실행했는데, 말씀하신 정리 이관(cleanup migration) 단계를 넘지 못했습니다.
이 이관이 충돌(crash)을 일으키고 있습니다. discourse/plugins/discourse-cakeday/db/migrate/20251127125226_delete_old_default_values.rb at main · discourse/discourse · GitHub
이 이관의 up 메서드에서 migration_timestamp("20250717093505")와 migration_timestamp("20250811132217")를 실행하면 nil 값이 반환됩니다. 이 nil 값들이 이관의 delete_settings 메서드에서 SQL 쿼리를 깨뜨립니다.
아마도 해당 참조하는 마이그레이션이 주석 처리되었기 때문일 것입니다.
마이그레이션은 나중에 수정해서는 안 된다고 항상 배워왔습니다. 그 이유가 바로 이것입니다.
더 많은 관심을 받기를 바라며 이 내용을 Contribute > Bug 채널로 옮기겠습니다…
1개의 좋아요
d-cakeday를 코어로 병합하는 과정이 계획대로 진행되지 않았습니다…
모든 번들링된 플러그인은 기본적으로 비활성화되어 있어야 하며, d-cakeday는 이전부터 항상 활성화되어 있던 소수의 마이그레이션 대상 중 하나였습니다.
마이그레이션 전에 해당 플러그인이 활성화되어 있던 사이트는 계속 활성화된 상태를 유지하고, 이전에 플러그인이 없던 사이트는 새로운 기본값(off)을 사용한다는 것이 아이디어였습니다.
현재는 가장 최근의 (잘못된) 마이그레이션을 대체하여 cakeday/cakeday_birthday를 활성화할지, 아니면 기본값인 "off"를 유지할지 판단하는 휴리스틱을 사용하는 새로운 마이그레이션으로 교체하는 PR을 열었습니다.
5개의 좋아요
이 주제는 4일 후 자동으로 닫혔습니다. 더 이상 새로운 답변을 남길 수 없습니다.