Troubleshooting

Composer warns about “Ambiguous class resolution”

Cause: both Showtime and a standalone bundled plugin are installed as Composer packages. Showtime vendors that plugin’s classes, so the same class names exist twice and Composer silently picks one — possibly the wrong copy, which puts the migrator on the wrong path.

Fix: remove the standalone package. This is a required step of upgrading, not a cleanup:

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

“Class not found” when a module boots

Cause: a stale autoload map. This shows up in local development after Showtime’s autoload configuration changes — the project’s installed.json caches it.

Fix: composer dump-autoload is not enough. Update the package:

composer update justinholtweb/craft-showtime

Owl, Stub, and Headcount don’t appear in the plugin list

That’s correct. They are mounted as internal modules, not registered with Craft’s Plugins service — which is exactly why one license covers all three. Their control-panel sections, element types, routes, Twig variables, and console commands are all live.

To confirm they’re running, look for the Showtime section in the sidebar, or hit a module route directly, e.g. /admin/stub/bookings.

Stripe payments fail, or the keys look empty

Work down the resolution order (last wins):

The shared Stripe group at Settings → Plugins → Showtime
The per-module override on Stub’s inlined settings or Headcount’s settings screen
config/stub.php or config/headcount.php, which beat both

A config file wins over anything set in the control panel, so if a value in the CP appears to have no effect, check whether a config file is setting it too.

Two specifics that catch people out:

Webhook secrets differ per endpoint. Stripe issues a separate signing secret for each endpoint you register, and Stub and Headcount have different endpoints. If you run both, one of them needs a per-module override.
Empty means inherit, for shared attributes. Clearing a module’s Stripe field doesn’t blank it — it falls back to the shared value. To give one module genuinely different credentials, set them explicitly rather than clearing the other.

A shared setting isn’t reaching a module

Check whether that module has a non-empty override for the same attribute — an override always beats the shared value. Saving a module’s settings screen is supposed to store only genuine overrides, but a value typed directly into a module’s field is a genuine override. Clear it to go back to inheriting.

Note that Craft’s environment-autosuggest fields render only a disabled preview input server-side — the real named input is created by JavaScript at runtime. Grepping page source for the field name finds nothing even when everything is correct. Test with a save round-trip and a behaviour check instead.

A plugin was adopted but its settings vanished

Adoption re-homes settings from plugins.<handle>.settings to plugins.showtime.settings.<handle> in project config, and that move has to happen after Craft finishes writing its own config node. If you interrupted the install, or restored a project-config file mid-upgrade, the two halves can end up out of step.

Fix: re-run the sync, which finishes any pending adoption work:

php craft showtime/migrate/all

If that doesn’t recover them, the values are still in your pre-upgrade database backup — re-enter them at Settings → Plugins → Showtime.

Recurring events stop appearing after a certain date

Cause: occurrences are materialised only to a rolling horizon (24 months by default), and the command that rolls it forward isn’t running.

0 3 * * * cd /path/to/project && php craft owl/maintenance/regenerate --queue >> /dev/null 2>&1

Run it once by hand to catch up. Raise occurrenceHorizonMonths in config/owl.php if you need to publish further ahead.

Event ticketing isn’t available

Ticketing needs Craft Commerce 5.0+ installed. Without it, Owl’s ticketing stays dormant and everything else works — exactly as it does standalone. The Pro edition itself is always on in the bundle; Showtime asserts it at mount.

A booking is refused with “only available to members”

A member perk marks that service members-only and the booker doesn’t hold a qualifying plan. Remember how the booker is matched to a member: by the Craft user linked to the Stub customer record, or failing that by email address. Someone booking as a guest with a different address from their membership won’t be recognised.

A member isn’t getting their discount

Check, in order: the perk is enabled; it targets the right service; the member’s subscription is active (not trialling-expired or past-due) on that exact plan; and the email or user link resolves as above. If two plans overlap, the one leaving the lowest price wins — a smaller-than-expected discount usually means a second perk is being applied instead.

Schema is out of date after a deploy

Craft’s migrate/all only migrates installed plugins, and the mounted modules aren’t installed. Add Showtime’s command to your deploy — it is idempotent:

php craft up
php craft showtime/migrate/all

“Showtime is already installed” when installing Stub or Headcount

That guard is intentional. A standalone install alongside the bundle would register a duplicate element type and share the same tables. Use the bundled copy — it is the same plugin.

Uninstalling took my data

Uninstalling Showtime runs every module’s uninstall migration in reverse order, which drops all 20 tables. This is correct behaviour for a plugin uninstall, but it is worth saying plainly. Restore from a backup; take one before any uninstall.

Still stuck

Open an issue on GitHub or email me. Include your Craft version, PHP version, which of the three you use, and whether you installed clean or adopted from a standalone plugin.