Craft6 Revamp Laravel Package

Product Decisions This Supports

• CMS/platform selection for content-heavy properties. Committing to a Craft 6 starter is effectively a decision to adopt Craft's model — project config as source of truth, Twig templates, Elements instead of an ORM. Frame this as a platform bet, not a package selection.
• Build vs. buy vs. template. This package is a seed, not a dependency: consumed once via composer create-project, then the code is ours. That makes the economic case a one-time time-to-first-deploy saving (scaffolding, env/config wiring, deploy scripts, module skeleton) rather than a recurring licensing or integration cost. MIT license means zero procurement friction.
• Standardization across squads/agencies. If we ship more than one Craft build, a shared scaffold is a governance tool: one opinionated answer to "where does business logic live," "how does deploy work," "what's in config/project/*.yaml." Variance between project repos is the hidden cost this removes.
• Modernization roadmap for existing Craft installs. The stated use case is refreshing existing installations with less boilerplate — a credible target-state reference for teams planning a Craft 5 → 6 upgrade, even if we don't adopt the scaffold verbatim.
• Headless / omnichannel decisions. The accompanying guidance pushes Element API and built-in GraphQL ahead of hand-rolled endpoints. That materially changes effort estimates for a JS-front-end or app-driven roadmap, and it changes them downward.
• Hiring and onboarding strategy. The Laravel-to-Craft translation table (Artisan → php craft, Eloquent → Elements, Blade → Twig, providers → modules) is quietly the most valuable artifact here. It suggests we can staff Craft work from our existing PHP/Laravel talent pool instead of hiring Craft specialists — a real cost-of-team input.
• Roadmap impact: none, and that's a feature. Because it's a scaffold, we take no ongoing upgrade obligation, no transitive dependency risk, and no CVE surface from this repo. The trade is that we inherit Craft 6's own maturity curve.

What this should not drive: any decision to adopt Craft where the deciding factor was "this scaffold looks nice." The scaffold is a convention layer; the platform is the actual commitment.

When to Consider This Package

Adopt as a starting point when:

• Craft 6 is already the chosen platform (or a shortlisted finalist) and the remaining question is how, not whether.
• We are standing up a new build or a deliberate rebuild, not patching a live install.
• The team is PHP/Laravel-fluent — the translation overhead is measured in hours, not weeks.
• Editorial workflow, granular permissions, and multi-site/localization are requirements, not nice-to-haves.
• We want reproducible deploys: project config in git, php craft up in the pipeline, allowAdminChanges => false in production.
• We accept fork-and-own: pin a commit or tag, diff it, and keep our copy current by intent rather than by composer update.

Look elsewhere when:

• Craft isn't chosen yet. This package tells you nothing about whether Craft beats Statamic, WordPress, Payload, or a Laravel + headless stack. Run that evaluation first.
• The site is simple. A brochure site with three content types rarely justifies Craft's licensing, hosting, and project-config discipline over a lighter CMS.
• The team is JS-first. If nobody owns PHP in production, a Yii2-based stack is a staffing liability no scaffold fixes.
• We need vendor support or an SLA. Five stars and pull-request-only maintenance means the effective support channel is "read the source and fix it ourselves." Acceptable for a seed, disqualifying for a runtime dependency.
• We need a library, not a template. There is no API to call here. If the requirement is "add capability to an existing app," this is the wrong artifact.
• Change-tracking rigor is a hard requirement. Release notes for 1.1.2 are a bare changelog link with zero disclosed content. Anyone treating this as a supply-chain input needs to diff config/, composer.json, and CHANGELOG.md between tags before merging — a scaffold release that silently reshapes config/project/ reshapes the content model.

Due-diligence checklist before we commit (one afternoon):

1. Read .env.example → config/general.php → config/project/ in that order; confirm the conventions match how we actually deploy.
2. Diff config/project/ and composer.json between 1.1.1 and 1.1.2 to confirm the patch is inert.
3. Prove the core loop end-to-end: create a section in the CP locally, export project config, commit, have a second machine php craft up. If that round trip is clean, the scaffold is doing its job.
4. Confirm Craft 6 licensing and upgrade path commercially, since the scaffold's value is contingent on it.
5. Check whether the repo's structure still matches the current Craft 6 release — a "6-ready" prepper can lag the platform it targets.

How to Pitch It (Stakeholders)

To executives — one paragraph: We are evaluating a free, MIT-licensed starting template for Craft CMS 6 projects. It is not a vendor dependency and carries no license cost, no subscription, and no ongoing upgrade obligation — we copy it once, own the result, and the risk is bounded to a single project bootstrap. Its value is process, not code: it encodes a deploy model where the content model lives in version control alongside the code, which is the difference between a CMS deployment we can review, roll back, and reproduce, and one that depends on someone remembering what they clicked in an admin panel. The decision in front of us is really about whether we standardize on Craft 6 for content-heavy sites; this template makes that decision cheaper to execute and easier to staff, because our existing PHP/Laravel engineers can be productive on it quickly rather than requiring Craft specialists.

To engineering — the short version:

• Treat it as laravel/laravel, not as a package. composer create-project, then it's our repo. Pin a tag and diff releases; don't track a branch.
• The mental shift that matters is config/project/ as committed state. Local dev allowAdminChanges => true, production false plus php craft project-config/apply --force in the deploy. Never let content-model changes happen in the production CP.
• Project config drift is the dominant failure mode. Expect it, tool for it (project-config/diff in CI), and take a database dump before any --force.
• Business logic belongs in a module registered via config/app.php, not in Twig and not in a one-off plugin. Event hooks on Entry::EVENT_AFTER_SAVE, EVENT_REGISTER_SITE_URL_RULES, Users::EVENT_AFTER_LOGIN cover most integration needs.
• Deploy sequence: composer install --no-dev --optimize-autoloader → php craft up --interactive=0 → clear-caches all → supervised queue worker. Twig compile caches under storage/runtime/compiled-templates may need a manual purge when template paths move.
• Two performance traps to police in review: element queries missing .with([...]), and Entry::find() inside a {% for %}. Also verify devMode is off before anyone investigates a "slow staging environment."
• The Yii service container is not Laravel's — Craft::$app->getFoo(), not app(Foo::class). Any ported Laravel code will fight us at exactly that seam.

The ask: A one-sprint, timeboxed spike: stand up a reference project from the scaffold, prove the project-config round trip across two machines, and produce a short written verdict on whether these conventions fit how we actually ship. Success criteria are the working round trip and a deploy we can reproduce from a clean checkout — not feature delivery. If the spike succeeds, the follow-on decision is platform standardization on Craft 6, which should be made on platform merits with the scaffold treated as a solved implementation detail; if it fails, we have spent one sprint and learned it cheaply rather than discovering it mid-build.