Diff for Flarum (New)

huseyinfiliz

📜 Diff for Flarum

📝 Description

Diff allows you to view post edit histories on your Flarum forum. Track changes, compare revisions, and even rollback to previous versions.

This is the maintained fork of the original the-turk/flarum-diff extension. Both Flarum 1.x and Flarum 2.x are supported — install the version that matches your Flarum.

✨ Screenshots

Screenshots

📊 Post-Stream Item

Post-Stream Item

📋 Revision Dropdown List

Dropdown List

🚀 Key Features

✅ Multiple Detail Levels - Line (default), word, and character level diffs
🎨 Three Render Modes - Inline, Side by Side & Combined views
📦 Archive Old Revisions - Save storage with automatic compression
⏪ Rollback Support - Revert to any previous revision
🗑️ Delete Revisions - Remove unwanted edit history
🌙 Dark Mode Support - Native Flarum 2.x dark mode compatible
⏰ Cron Job Support - Automated archiving with scheduler
🔇 Quiet Edits Support - Works with the-turk/flarum-quiet-edits

📥 Installation

Flarum 1.x:

composer require huseyinfiliz/flarum-diff:"^1.0"
php flarum migrate
php flarum cache:clear

Flarum 2.x:

composer require huseyinfiliz/flarum-diff:"*"
php flarum migrate
php flarum cache:clear

⚠️ Upgrading from the-turk/flarum-diff

Note on settings: Extension settings won't transfer automatically due to the namespace change (the-turk-diff.* → huseyinfiliz-diff.*). Simply reconfigure your preferences in the admin panel after installation. Your revision history is not affected.

⚙️ Configuration

After installation, go to Admin Panel → Extensions → Diff to configure:

Detail Level - None, Line, Word, or Character level
Neighbor Lines - How many context lines to show
Merge Threshold - For Combined renderer (0-1)
Archive Options - Automatic archiving with A, m, b parameters
Cron Jobs - Enable scheduled archiving

🗄️ Archive Old Revisions

If x ≥ A (where x is post's revision count), first y=mx+b revisions will be stored as merged & compressed. Configure A, m, and b values in settings.

For automated archiving, enable cron jobs and add this to your server:

* * * * * php /path/to/flarum schedule:run >> /dev/null 2>&1

Or run manually: php flarum diff:archive

🔐 Permissions

Configure in Admin Panel → Permissions:

View edit history - Who can see revision history
Delete own/others edit history - Who can remove revisions
Rollback own/others edit history - Who can revert to previous versions

♻️ Updating

composer update huseyinfiliz/flarum-diff
php flarum migrate
php flarum cache:clear

📋 Requirements

Flarum 1.x: PHP ≥ 7.4, ext-iconv
Flarum 2.x: PHP ≥ 8.1, ext-iconv

🔗 Links

🙏 Credits

Original Extension: Hasan Özbey (the-turk)
Fork & Maintenance: Hüseyin Filiz

If you find this extension helpful, feel free to ⭐ star the repository and share your feedback!

Capybara

Checked it — it works. Thank you very much for updating such an important extension 🧡

Umutcan

You'r awesome @huseyinfiliz 💝

navindra

huseyinfiliz Brilliant work!

Thank you so much for bringing over such a core and essential extension to Flarum 2!

👏

navindra

Heads up, but there's definitely a bug of some sort that will delete all the post history from Diff 1.x.

I thought I had done something wrong the first time. On the second time I did this:

Dropped my DB.
Restored DB from scratch. Confirmed post history is all there.
Installed Flarum 1, confirmed post history is there.
Upgrade to Flarum 2.
Install Diff for 2.x following steps.
Confirm post history is still there.
However, Diff for 2.x does not show any edit history.
As soon as I make an edit, new edit history is shown, but rest of the entire table is dropped.

How can the contents of an entire table get dropped like that? Different schema or something? AuthZ issue between different extensions sharing same table?

I think this has happened before (and I've experienced it) when extensions have changed namespace.

Flarum is very touchy about this, but it shouldn't result in catastrophic data loss. Is this a general Flarum issue or something else?

navindra

This is what's needed to avoid catastrophic data loss before upgrading to 2.x:

UPDATE migrations 
SET extension = 'huseyinfiliz-diff' 
WHERE extension = 'the-turk-diff';

Make sure to do this early enough before moving to 2.x.

This is really an unfortunate and dangerous situation with so many extensions about to change owners/namespace. I hope the Flarum devs can build in some safeguards here.

Now that I'm unblocked though, I'll plan to do some more testing later! 🙂

GreXXL

navindra the namespace of the extension has changed as the author changed. In order to make a transition possible it would need a migration. The easiest way would be to have a v1 compatible version in the new namespace that migrates data and then a upgrade to a v2 version.

huseyinfiliz

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!

huseyinfiliz

GreXXL Thanks for the suggestion! However, I believe simply skipping the migration if the tables already exist should be sufficient here:

if ($schema->hasTable('post_edit_histories')) {
    return;
}

The table schema is identical between versions - only the namespace changed, no structural modifications. So there's no need for data transformation or a v1 intermediate version.

What do you think?

huseyinfiliz

Diff

🔧 v2.0.0-beta.2 - Critical Migration Fix

This release fixes a critical data loss issue reported after beta.1.

🐛 Bug Fix

Fixed: Revision history data loss during upgrade

When upgrading from the-turk/flarum-diff, the migration was dropping and recreating tables even when they contained existing revision data. This caused complete loss of all revision history.

The migration files now check if tables contain data before any operations:

✅ If table has data → preserve it, skip recreation
✅ If table is empty → safe to recreate for clean schema
✅ Proper foreign key handling when recreation is needed

✅ Automated Migration Testing

We've added a comprehensive GitHub Actions workflow that tests the complete upgrade scenario:

Install Flarum 1.8 + the-turk/flarum-diff
Create revision data via API
Upgrade to Flarum 2.x
Install huseyinfiliz/flarum-diff
Verify all revision data is preserved

Every release is now automatically tested for data safety.

Check it: huseyinfiliz/flarum-diffactions/runs/20090483428

🔧 Installation

composer require huseyinfiliz/flarum-diff:"*"

🔄 Update

composer update huseyinfiliz/flarum-diff
php flarum migrate
php flarum cache:clear

🔗 Links

💡 Feedback & Suggestions

Feel free to share your ideas, report bugs, or request features in the discussion thread!

⚠️ If you lost data with beta.1, unfortunately it cannot be recovered. We apologize for this issue and have implemented safeguards to prevent it from happening again. navindra

navindra

huseyinfiliz Wow, that's quite an unintentional booby trap... destroying the table on creation. I really appreciated your in-depth explanation as well, it all makes sense now!

Thanks a ton for your fix, I can confirm it works great and preserves my data!

The rollback functionality isn't quite working correctly.

I created an original post and edited it with #1, #2, #3 in the content. Then I rolled back the last revision. In the history, #3 is now gone, and weird new entries are created:

These are the two last log entries... it should just show a regular diff and it should not truncate the last #3 change from the list. I confirmed on Diff 1.x that it works as expected.

This is not trivial work, so thanks a ton!

huseyinfiliz

navindra While upgrading to Flarum 2.x, many functions had to be rewritten from scratch. There’s probably a silent error somewhere. It seems more action tests need to be added. Thanks for reporting it.

huseyinfiliz

Diff

🔧 v2.0.0-beta.3 - Rollback Fix

This release fixes a rollback functionality issue reported after beta.2.

🐛 Bug Fix

Fixed: Revision history corruption during rollback

When rolling back to a previous revision, the revision being rolled back from was not being preserved correctly in the history. This caused the rolled-back revision's content to disappear from the history. (navindra )

Example of the bug:

Post edited: 123 → 456 → 789
Rollback to original (123)
❌ Before fix: History showed 123 → 456 → 123 (missing 789)
✅ After fix: History shows 123 → 456 → 789 → 123

Root cause: In Flarum 2.x, the EditPost command was removed and replaced with the new Resource-based API. The previous implementation wasn't capturing the correct oldContent value before dispatching the Revised event.

Changes made:

RollbackToDiffHandler.php: Now captures current content before modification and dispatches Revised event with correct oldContent
PostActions.php: Now prefers $event->oldContent from the Revised event for more reliable revision tracking

🔧 Installation

composer require huseyinfiliz/flarum-diff:"*"

🔄 Update

composer update huseyinfiliz/flarum-diff
php flarum cache:clear

🔗 Links

💡 Feedback & Suggestions

Feel free to share your ideas, report bugs, or request features in the discussion thread!

navindra

huseyinfiliz It's working! Yay!

Very very cool. I rolled back, rolled forward, did edits, rolled back... everything worked.

And I appreciate your in-depth explanations a ton as well.

Thank you so much for this excellent work! 👏

navindra

I'm back with another small bug. I just noticed that this extension changes the colors of PianoTell. Mainly the grey parts are not expected:

Without the extension, PianoTell looks like this:

huseyinfiliz

navindra I think the reason for this is not this extension but Stickiest. If that's the case, please report this reply and move it to the Stickiest discussion. It's important for tracking bugs correctly and informing other users accurately.

navindra

huseyinfiliz I thought so too, however the colors go back to normal when this extension is disabled. I'm not referring to the highlight from Stickiest.

huseyinfiliz

navindra Now I understand the issue. I got confused because you highlighted the gray section in the other extension as well. The fact that this hero section is gray is actually a bug in the Diff extension, and I’ll release an update today that fixes it.

Capybara

@huseyinfiliz Hi! In the first days of January, I’ll be re-releasing my extensions, and one of them uses a database to store dice roll values. I vaguely saw that you had dealt with a database migration issue before. Is there anything I need to do before releasing the extension?