navindra Hey, thank you so much for the detailed bug report and for taking the time to test this thoroughly! 🙏
You're absolutely right, and I apologize for this critical issue. Here's what happened:
I was thinking of Flarum migrations like Laravel migrations (which are framework-global), so I assumed the original migration files wouldn't run again since the tables already existed. I didn't touch the original migration files from the-turk/flarum-diff because I thought they'd simply be skipped.
What I missed: Flarum tracks migrations per-extension namespace. So when the namespace changed from the-turk-diff to huseyinfiliz-diff, Flarum saw these as completely new migrations that needed to run. And unfortunately, the original migrations have dropIfExists() at the beginning (likely from early development iterations), which caused the catastrophic data loss you experienced.
The SQL workaround you found is exactly right for anyone who's already in this situation:
UPDATE migrations
SET extension = 'huseyinfiliz-diff'
WHERE extension = 'the-turk-diff';
I'll push a fix within the next few hours that updates the migrations to check if tables already exist before doing anything:
if ($schema->hasTable('post_edit_histories')) {
return; // Table exists, skip migration
}
This way, existing data will be preserved automatically without requiring manual SQL intervention.
Again, really sorry about this - I should have caught it during testing. Thanks for helping identify the issue and for sharing the workaround with the community!
