Supportamic Laravel Package

Getting Started

mitydigital/supportamic is a Statamic 6 addon that layers Mity Digital's support-oriented features (support/help surfaces inside the Control Panel plus supporting routes, views, and config) onto a Statamic site. It is early, low-adoption software: zero stars, zero dependents, and a single recent release. Treat the source as the documentation until a README with usage details is available.

Minimal path to a first working install:

1. Confirm platform fit. Statamic 6 implies Laravel 11/12 and PHP 8.2+. Check composer.json in the repo for exact statamic/cms and laravel/framework constraints before committing.
2. Install into a scratch site first, not a client project.

   composer require mitydigital/supportamic
   

   If it is not on Packagist yet, add the VCS repository entry and require dev-main.
3. Inspect what the service provider registers. Open src/SupportamicServiceProvider.php (or similarly named) and note:
   • boot() / register() calls: publishes, routes, view namespaces, CP nav registration, Blade components, Antlers tags, middleware.
   • Any $this->publishes([...], 'supportamic-config') style tags — these tell you exactly what to publish.
4. Publish and read config.

   php artisan vendor:publish --tag=supportamic-config
   php artisan vendor:publish --tag=supportamic-assets
   

   Read config/supportamic.php end to end. In addons of this shape the config usually controls enabled features, CP nav label/icon, route prefixes, mail recipients, and permission handles.
5. Run migrations only after reading them.

   php artisan migrate --pretend
   

   Confirm table names and whether any existing tables are altered. Then migrate locally.
6. Clear caches and log in to the CP.

   php artisan optimize:clear
   

   Look for a new nav item or a support/help entry in the user menu. That is the fastest signal the addon booted.

First use case to validate: an authenticated CP user opening the support surface, submitting a piece of content (ticket/request/feedback), and confirming where it lands (database table, notification email, or Statamic entry). If you can trace that flow end to end, you understand the package.

Where to look first, in order: README.md → composer.json → service provider → config/ → routes/ → resources/views/ → database/migrations/ → tests (if any).

Implementation Patterns

Because the addon is undocumented and unproven, the practical patterns are about containment and extension rather than clever usage.

Isolate it behind config. Wrap every behavior you rely on in a config flag you control. If the package ships a support widget, submission endpoint, or CP panel, gate it in config/supportamic.php and in your own config/custom.php so you can disable it per environment (APP_ENV) without forking.

CP-integrated help/support surface. The most likely day-to-day use is dropping a support entry point into the Control Panel for editors. Typical wiring:

• Register or confirm the CP nav item and restrict it with a permission handle (e.g. view supportamic). Grant via a Statamic role in resources/users/roles.yaml rather than editing users individually.
• If submissions are stored, expose them to editors either through the addon's own CP listing or by mirroring into a Statamic collection so existing publishing workflows and permissions apply.
• Keep the admin surface read-mostly; don't let editors delete submissions unless the package explicitly supports it.

Front-end support form. If the package exposes routes, mount them under a prefixed path in config rather than the root, and front it with your own Blade view or Antlers template that posts to the package endpoint. Validate with a Form Request on your side and forward only sanitized input. This keeps your public surface stable if the package's routes change between releases.

Notification flow. Support features exist to notify someone. Pattern:

// config/supportamic.php
'recipients' => array_filter(explode(',', env('SUPPORTAMIC_RECIPIENTS', ''))),

Then verify the package dispatches mail synchronously or via queue. If synchronous, wrap submissions in a queued job yourself or set the queue connection so a slow SMTP host cannot block a CP request.

Events as the integration seam. If the addon fires events (submission created, status changed), listen rather than subclass:

Event::listen(SupportSubmissionCreated::class, function ($event) {
    // forward to Slack, CRM, or a Statamic entry
});

This is the safest extension point in a zero-dependency addon: your listener survives package upgrades better than an overridden controller or view.

Testing pattern. Add a feature test that hits the endpoint or CP route and asserts the DB row and the Mail::fake() assertion. Because there are no dependents, you are effectively the integration test suite. A single SupportamicTest covering the happy path and the unauthenticated case is worth more than any documentation you'll find.

Version pinning. In composer.json, require an explicit constraint ("mitydigital/supportamic": "0.1.*" or a commit hash) and commit composer.lock. Do not use ^ on a pre-1.0 addon with no downstream usage.

Gotchas and Tips

• Zero dependents means zero field reports. Any bug you hit is likely unreported. Budget time to read the package source; don't expect Stack Overflow answers.
• API instability. A single release in 2026 and no stars strongly suggests breaking changes. Anything you extend (controllers, views, models, config keys) may move. Prefer events, config, and published views over class extension.
• Publish tags are guesswork. If vendor:publish --tag=supportamic-config does nothing, list available tags:

  php artisan vendor:publish --provider="MityDigital\Supportamic\SupportamicServiceProvider"
  

  or inspect the provider's publishes() calls directly. Publishing without a tag and choosing interactively is the fallback.
• Route collisions. A support route like /support can collide with an existing page or a Statamic route. Check php artisan route:list --path=support after install and move the prefix in config if needed.
• Config cache traps. After editing config/supportamic.php in staging or production, run php artisan config:cache — otherwise behavior silently differs between local and deployed environments.
• Migrations in production. Run migrate --pretend first. If a migration modifies an existing table (users, entries), take a backup. For an unproven addon this is not optional.
• Permissions. If the CP nav item appears for everyone, that's a security/UX bug, not a feature. Check for a permission registration in the provider and add the handle to your roles. Users may need to log out and back in for Statamic to pick up new permissions.
• Mail configuration. Support features almost always send mail. Verify MAIL_* is set for the environment and that the recipient config is non-empty; an empty recipients array often fails silently. Use MAIL_MAILER=log locally to confirm the message is composed before chasing SMTP.
• Queue vs. sync. A synchronous notification inside a CP request can time out against a slow mail server. Check whether the package implements ShouldQueue; if not, prefer a listener that dispatches your own queued job.
• Front-end escaping. If the package renders submitted content back into the CP or a page, confirm it escapes output. Audit any {!! !!} or {!! $submission->body !!} in published views.
• Statamic version drift. Statamic 6 is recent; a package released in mid-2026 may target a specific 6.x minor. If you see odd container or nav errors, check the statamic/cms constraint and align your app's version rather than patching the addon.
• Missing docs is a signal, not a blocker. The practical workflow is: read the provider, publish everything, write one feature test, then decide whether the package earns its place. If the feature set is small, a 200-line in-house implementation backed by a Statamic collection and a notification may be lower risk than carrying an unmaintained dependency.