Installer Laravel Package

Product Decisions This Supports

• CMS platform selection — the real decision hiding inside this package. photoncms/installer is not a standalone tool; it is the entry ramp to Photon CMS. Adopting the installer means adopting the CMS, its config layout, its admin/auth model, and its migration history. The PM question is therefore "do we want Photon CMS in our stack?" and everything about this package says no: zero stars, zero dependents, a heuristic score of 0, and framework constraints from the Laravel 5.x / PHP 7.x era. That is a vendor-and-viability call, not a code-quality nitpick.
• Roadmap sunset and legacy cleanup. If Photon CMS appears in an old spike, an inherited codebase, or a "we should look at this someday" backlog item, this package is the artifact that closes it out. Unmaintained installer plus unmaintained CMS means every future PHP/Laravel upgrade becomes an internal fork-and-repair project you did not budget for. Kill it explicitly so it stops consuming roadmap attention.
• Build vs. buy for our onboarding flow — informs, does not decide. The one durable asset here is the pattern: publish config, run migrations, seed an admin user, write environment values, optionally load demo content, then self-disable. If your roadmap includes a one-command setup or a browser-based install wizard for a Laravel product, mine this source for the shape of the flow and then build your own against a Laravel version you control. Do not take a dependency to learn a sequence of Artisan commands.
• Support and SLA modeling. There is no maintainer to escalate to, no CVE feed, no issue triage, no security contact. Any product commitment that assumes a patch cadence, a compatibility guarantee, or a vendor relationship is unsupported by this package. If your org requires a named owner for every production dependency, this fails that gate on day one.
• Supply-chain and security review scope. Installer-class packages typically register HTTP routes and/or Artisan commands that write .env, create the first admin user, and run migrations. An unauthenticated installer endpoint left reachable after deployment is a privilege-escalation path. Zero dependents does not mean "safe and simple" — it means nobody has audited it. Treat the Composer install as untrusted code and price the review accordingly.
• Use cases it is genuinely good for (both internal): a disposable local sandbox to evaluate Photon CMS's content-modeling concepts, and a teaching reference for how Laravel installers are structured. Nothing customer-facing, nothing with persistent data, nothing touching real identities.

When to Consider This Package

Consider it only if all of the following hold:

• You are evaluating Photon CMS specifically — not "a Laravel CMS" in the abstract — and you want the fastest route to a throwaway local instance to see whether its content-modeling ideas are worth copying.
• The environment is disposable: a local container or a spike branch with no persistent data, no real user records, and no deploy target.
• You have already accepted, in writing, that the underlying CMS is unmaintained and that your team will own every future security patch and framework bump.
• You are reading it as reference source, not adding it to a require block.

Look elsewhere — decisively — if any of these are true:

• Any production traffic, staging environment, or shared database is in scope. Installer seeds credentials and writes config; that is exactly the surface you do not want unowned.
• You need current Laravel compatibility (Laravel 9/10/11, PHP 8.1+). Expect hard Composer resolution failure first, then a cascade of removed framework APIs, helper relocations, and PHP 8 type-strictness errors even after hand-relaxing constraints. Estimate this as a fork-and-repair project, not an install.
• You want a CMS you can hire for. Compare against maintained options with real dependents and release cadence — Statamic, October CMS, Winter CMS, or plain Laravel plus Filament.
• Your actual goal is "ship an installer for our own product." Then the answer is build, and copy the pattern from a maintained source (Laravel's first-party installer conventions, or mature product setup flows) rather than from a package nobody uses.
• You are assessing supply-chain exposure. No dependents means no downstream scrutiny, no bug-fix inheritance, and no one to tell you when something breaks.

Minimum due diligence before any hands-on time — roughly 20 minutes of reading:

1. composer.json — the type field (project vs library) tells you whether this is a create-project template or a require + Artisan command, and php / illuminate/* constraints tell you if it resolves at all on your baseline.
2. Source scan for HTTP routes and file writes: does it register a reachable installer route, does it overwrite .env or config on re-run, is the flow idempotent?
3. Last commit date and any upstream Photon CMS maintenance signal.

How to Pitch It (Stakeholders)

For executives — one line: This is the installer for a CMS nobody maintains. It has no stars, no downstream users, no vendor, and no patch path. Recommendation: do not adopt. If Photon CMS is on our books from an earlier experiment, this is our cue to retire it and budget the migration instead of the install.

For engineering — the useful part: Ignore the package as a dependency; keep it as a reference. It demonstrates a conventional Laravel installer sequence — config publishing, migration execution, admin seeding, environment writes, post-install self-disable — and that sequence is worth mirroring in our own onboarding flow, built on a framework version we control with a maintainer we can page. Also flag it as a security reference: any installer that writes .env and seeds an admin must be unreachable after install, and this package is a good example of the surface to review.

The tradeoff in plain terms: Adopting costs us a platform we own end to end, a recurring fork-and-patch burden on every PHP/Laravel bump, and a security surface with no upstream. Not adopting costs us a few hours of writing our own installer scaffolding. The second number is smaller, and it is the only one that stays small.

Ask: Close the Photon CMS evaluation as "no-go — unmaintained," record the rationale so it is not reopened, and if onboarding friction is a real product problem, open a small, time-boxed ticket to build our own installer using this package as the pattern rather than as the dependency. Gate any further investment on a separate, explicit decision to adopt Photon CMS itself — the installer decision is downstream of that and cannot be made independently.