Upgrading from a standalone plugin

If a site already runs Owl, Stub, or Headcount as its own plugin, installing Showtime adopts it in place. Its settings move under Showtime, its plugin registration is removed, and its tables, rows, and migration history are left exactly as they were.

Do not uninstall the standalone plugin first. php craft plugin/uninstall stub runs that plugin’s install migration backwards, which drops its tables and everything in them. Adoption exists precisely so you never have to do that.

The upgrade, start to finish

1. Back up the database

php craft db/backup

Adoption is designed not to touch your data, and it is tested against live data on every release — but this is a schema-level operation on a production site. Take the backup.

2. Require Showtime

composer require justinholtweb/craft-showtime

At this point both the standalone package and Showtime’s vendored copy of the same classes are on disk. Composer will warn about ambiguous class resolution. That is expected, and step 4 clears it.

3. Install Showtime — this is the adoption step

php craft plugin/install showtime

For each bundled plugin, Showtime works out which of three situations it is in and does the right thing:

  • Installed standalone → adopt it in place, then apply any migrations the bundled copy adds on top.
  • Already migrated under Showtime (its migration track has history) → just apply what’s new.
  • Brand new → run its install migration.

So a site running Stub and Headcount but not Owl adopts two and installs one, in a single command.

4. Remove the standalone Composer packages

composer remove justinholtweb/craft-stub justinholtweb/craft-headcount justinholtweb/craft-owl

Only remove the ones you actually had. This step is required, not tidy-up. While both packages are present, Composer has two copies of the same class names and silently picks one — possibly loading the standalone’s classes instead of Showtime’s vendored ones, which puts the migrator on the wrong path.

5. Verify

Log in and check that your data is where you left it — bookings, services, providers, customers, plans, subscriptions, events, calendars. Then confirm the plugin list at Settings → Plugins shows Showtime and no longer shows the plugin it absorbed.

What adoption actually does

For each adopted plugin, exactly three things change and nothing else:

  1. Its settings are re-homed from plugins.<handle>.settings to plugins.showtime.settings.<handle> in project config.
  2. Its row in the plugins table is deleted, and its plugins.<handle> project-config node is removed — so Craft stops treating it as an installed, separately-licensable plugin.
  3. Nothing else. Its uninstall migration is deliberately not run, and its plugin:<handle> migration track is left intact.

That last point is what makes it safe. The mounted module reuses the same track name and the same table names as the standalone plugin, so after adoption the data is simply still there — and the migration history still says which migrations have run, so the next update picks up exactly where it left off.

Adopting later, when a module joins the bundle

Adoption isn’t only an install-time event. If you are already running Showtime and a Showtime release adds a module you happen to run standalone, that release’s sync migration adopts it during craft up:

composer update justinholtweb/craft-showtime
php craft up
composer remove justinholtweb/craft-owl        # whichever one just got absorbed

Note that migration output is not surfaced by craft up the way it is by plugin/install, so don’t expect to see an “adopting…” line. Check the plugin list and your data instead.

What happens to your settings

Everything the standalone plugin had configured comes across untouched, stored under its handle inside Showtime’s settings. From there you can optionally lift the values that Showtime shares — Stripe keys, from-address, currency — into the shared group, and clear the per-module copies. See Configuration for how the shared/override resolution works.

Any config/stub.php, config/headcount.php, or config/owl.php file you already have keeps working verbatim, and still wins over both the shared and per-module values. Nothing about your deployment config has to change on upgrade day.

Licensing and refunds

Craft’s Plugin Store has no concept of upgrade pricing, so this part is handled by hand. Buy Showtime, then email me with your existing license key(s) and I’ll credit what you already paid for the plugin you’re replacing.

Your old license keys stop being needed the moment adoption completes — Craft never license-checks a mounted module.

Going back

The tables and migration tracks are unchanged by adoption, which means the door swings both ways: a mounted module’s data is exactly what a standalone install of the same plugin expects to find. If you ever want to detach one back into its own plugin install, get in touch and I’ll walk you through it.

← Installation Configuration →