1

I've started to play around with content migrations and have been following the Craft Quest course on the subject.

I'm not sure if this is a situation you should ever find yourself in, in an ideal work flow, but just encase its worth asking.

I created some generic content migration files which were flawed. I could spin them up using migrate/up but was unable to remove them with migrate/down - I then realised it was because of an error with the previous migration content file.

So I was left with no way to remove these fields, so I deleted them in Craft (I know not very elegant) and decided to start fresh. I also deleted the files from the migrations folder (this might have been a mistake - and not recommended as a workflow).

But these files are still referenced in Utilities > Content Migration

enter image description here

So... Is there another way to remove these files from Craft? This is just dummy data but I'm interested as if it was real data then this could be an issue.

Would you delete these inputs from the Database directly? If so how?

Or, would you take the file names and re create them again in the migrations folder and write the correct spin/down function and run that? Or is there a command that can be issued in the migrate/down command that tells craft to invalidate this file.

Or, is there a way to get Craft to clear its cached to see these file no longer exist?

I did find this answer helpful, but in this use case it would boil down to revert to a prior DB import.

Thanks for any help offered here, I know it's a hypothetical but has a real use case for future debugging.

1 Answer 1

2

Even after deleting the file, the migration will still show up in the UI because the migration history is stored in the database. You can use the console command migrate/mark to set the migration history to a specific migration. First, reset the migration history:

php craft migrate/mark m000000_000000_base

This will remove the migration history and mark all migrations that still exist in the file system as pending. Now you can reset the migration history to the latest migration that you do want to keep and have already executed:

php craft migrate/mark m220727_164614_add_contact_form_group

This will mark the migration as having been executed so it won't show up as pending anymore.


As a sidenote, for any changes to fields, sections, global sets and everything else related to the Craft configuration, I would heavily recommend using the project-config instead of migrations.

2
  • 1
    Amazing! Thanks as always for your input! Right, yes I was keying up between those two options (migrations, project config), but that makes it a bit easier to make the switch!
    – Wally
    Commented Jul 28, 2022 at 11:08
  • @Wally If you're still on the fence, project config is amazing, it will save you so much time compared to writing everything manually in migrations. We use project config for everything and only use migrations for actual content migrations (i.e. populating an installation with default content, moving content between fields etc). Saves so much time compared to other systems and works really well with version control, especially if you're working in a distributed team using git and a pull request workflow.
    – MoritzLost
    Commented Jul 28, 2022 at 11:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.