== Description ==

Every WordPress project with custom tables reinvents migrations badly, usually as a version option and a chain of if-statements in an activation hook that nobody dares reorder. Ratchet gives you numbered migration classes, a state table, and a CLI runner.

Migrations declare whether they are reversible. One that drops a column is not, and Ratchet refuses to pretend otherwise rather than writing a down step that recreates the column with the data gone.

It runs inside a transaction where the storage engine supports one, and takes an advisory lock so two deploys landing at once cannot both migrate.

== Screenshots ==

Numbered the way they ship in /assets/. Click any one to see it full width.

== Installation ==

Install and activate the plugin, or require it through Composer as a project dependency.
Generate a migration: wp ratchet make add_entries_table.
Run wp ratchet migrate in your deploy script.

Migrations live in your project, not in the plugin. Ratchet only runs them.

== Frequently asked questions ==

Does it touch core tables?

It will let you, and it will warn you loudly. Core tables change between WordPress versions and your migration will not be told.

What about multisite?

Migrations run per site or network-wide, declared per migration. The runner iterates sites for you.

== Changelog ==

= 1.4.0 = February 19, 2026

Advisory locking, so two concurrent deploys cannot both run the same migration.
Added --pretend, which prints the SQL and executes nothing.

= 1.2.0 = September 15, 2025

Migrations declare reversibility explicitly instead of every migration getting a generated down step.