flarum / flarum/framework

[2.x] Conditional / Skipping Migrations

Open
#4,923 0 comments 0 reactions 0 assignees View on GitHub
type/bug
Dominant language
PHP
Stars
6.7k
Forks
883
Avg merge
15h 16m
Merged PRs (30d)
73

Description

Developers writing migrations for Flarum can get the false impression that they can use the newly implemented migrations feature in Flarum 2 the same way they would in Laravel 13, e.g. [skipping a migration](https://laravel.com/docs/13.x/migrations#skipping-migrations), since many migrations use `Illuminate\Database\Schema\Blueprint` and `Illuminate\Database\Schema\Builder`. However, Flarum has implemented a fully custom migrator: Flarum migrations aren't Laravel migration class instances at all.

One feature I was looking forward to was [skipping migrations](https://laravel.com/docs/13.x/migrations#skipping-migrations), which becomes relevant when an extension integrates optionally with two or more other extensions and needs to run DDL only when certain tables or columns exist.

Until now we've usually added guard clauses in the `up` migration itself to prevent it from erroring when, e.g., the underlying table or column doesn't exist. The consequence is that the migration runs through successfully and gets logged in the `migrations` table, but it won't run again once the optional extension is installed afterward. The only clean fix in a production scenario is to manually delete that migration entry from the `migrations` table and re-migrate.

Given Flarum's extensible ecosystem and general architecture, I consider this a significant issue where a core-level solution would help a lot.

My first instinct was to follow a similar approach to what we did for [migration/command isolation](https://github.com/flarum/framework/pull/4864) and reimplement it ourselves. But that made me wonder whether we'd be preempting the [Laravel refactor planned for Flarum 3](https://github.com/flarum/framework/issues/4112), and whether a feature like this should wait until then. At the same time, it reinforces my sense that Flarum should keep moving closer to Laravel.

Contributor guide

Open the contributing guide

Research direction

Start by reading the migration/command isolation pull request and the Laravel refactor issue linked in the report, then trace Flarum's custom migrator and its migration logging behavior. Done means a core-level approach to conditional or skipped migrations is defined and validated against optional-extension scenarios without assuming Laravel migration classes.

Written by the indexing model from the issue text.

Assessment

Tech stack
laravel, php
Domain
database
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Needs clarification
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.