Using migrations to delete table with foreign key

I also faced these kind of issues. Migration file order is the main issue here. The best way is to create migration files one by one. Main entities should be created first. Migration should be refreshed with every migrate file creation. (with php artisan migrate:refresh)

According to @abkrim and @Eric

public function down()
{
    Schema::disableForeignKeyConstraints();
    Schema::drop('tableName');
    Schema::enableForeignKeyConstraints();
}

Or safer:

protected function dropColumn($table, $column) {
    try {
        Schema::disableForeignKeyConstraints();
        Schema::table($table, function (Blueprint $tbl) use ($column) {
            $tbl->dropColumn($column);
        });
    } catch (Illuminate\Database\QueryException $e)
    {
        Schema::table($table, function (Blueprint $tbl) use ($column) {
            $tbl->dropConstrainedForeignId($column);
        });
    } finally {
        Schema::enableForeignKeyConstraints();
    }
}

public function down() {
    $this->dropColumn('users', 'foreign_column');
}

pm_convo_replys has a foreign key that references pm_convo, thus you cannot delete pm_convo first without violating a foreign key constraint in pm_convo_replys.

To delete both you need to delete pm_convo_replys first.

public function down()
{
    Schema::drop('pm_convo_replys');
    Schema::drop('pm_convo');
}

I think this is the most correct approach:

public function down()
{
    Schema::table('[table]', function (Blueprint $table) {
        $table->dropForeign('[table]_[column]_foreign');
        $table->dropColumn('[column]');
    });
}

I think this is a better way to do it:

public function down()
{
    DB::statement('SET FOREIGN_KEY_CHECKS = 0');
    Schema::dropIfExists('tableName');
    DB::statement('SET FOREIGN_KEY_CHECKS = 1');
}