Laravel Folklore Laravel Package

Product Decisions This Supports

• Build vs. buy vs. inherit. This isn't a package you "buy into" — it's Folklore's internal platform kernel published as a Composer package. The real decision it informs is inherit: for any Folklore-built or Folklore-adjacent Laravel site, adopting it means inheriting content modeling, media handling, and auth conventions wholesale instead of rebuilding them. For anyone else, it's a "vendor conventions" decision, not a feature decision.
• Content-model commitments. The Core module hard-codes a pages-and-blocks model plus entities/repositories and medias (via folklore/laravel-mediatheque). Adopting it pre-decides how editors compose pages and how media is stored — a product-shaping choice that is expensive to reverse later. Decide this before the roadmap is locked, not during sprint 3.
• Auth strategy. The repository auth provider replaces the default Eloquent user provider. That's a product decision about user identity and multi-site login, and it should be ratified by whoever owns account/security requirements.
• Roadmap optionality at near-zero cost. Customer.io, Google (Maps/Places/Drive), PubNub broadcasting, PubSubHubbub, organisations, Panneau fields/resources, and make:* generators are opt-in with "no side effects at boot, no heavy mandatory dependency." That means features like marketing automation, store locator, realtime updates, or RSS/WebSub distribution can be scheduled on the roadmap without a new infrastructure line item — they become configuration and integration work.
• Platform upgrade cadence is a portfolio decision, not a per-site one. v1.1.7 accepts Guzzle 8, which is the gate on Laravel 13 adoption: any site that wants to move to Laravel 13 is blocked until this kernel allows it. The practical takeaway for planning is that framework upgrades across the portfolio are paced by this package's release cadence, so roadmap planning should treat "kernel supports framework version X" as a dependency milestone — and budget a maintenance window for it rather than discovering it mid-sprint. Sites on Laravel 11/12 are unaffected and see no change.
• Security floor is inherited, not re-litigated per site. The new Guzzle floor (^7.15.2|^8.0.1) is set specifically to include the fix for GHSA-v5mv-p594-2x33, which the media download host checks depend on. For a portfolio owner, that's the argument for inheritance in one line: a patched dependency floor applied once propagates to every site instead of being tracked site by site.
• Portfolio standardization. One entity/repository contract, one auth provider, one media layer across every site lets you reuse admin tooling, cross-site reporting, and engineer onboarding. This is the strongest product argument: the value compounds across N sites, not within one.
• Use cases this fits: agency/client site portfolios, brochure-plus-editorial sites with page/block composition, projects needing CMS-adjacent media management, sites bolting on marketing automation or mapping, and any build where teams already run Panneau for admin.

When to Consider This Package

Consider it when all of the following hold:

• You are Folklore, a Folklore partner, or you are taking over maintenance of a Folklore-built Laravel application — the package is designed as the shared foundation of those sites.
• You're on PHP ^8.3 and Laravel 11–13; older stacks are out of scope. Note the Guzzle split: only Laravel 13 accepts Guzzle 8, while Laravel 11 and 12 stay on Guzzle 7. Both minimums include the GHSA-v5mv-p594-2x33 fix, so pinning to the accepted floor is a security requirement, not a preference.
• You need the bundle — entities, repositories, pages/blocks, medias, users, auth provider — not a single utility.
• You're already or willing to be on folklore/laravel-mediatheque and, if you want the admin layer, laravel-panneau 1.3.
• You can pin a version, read the source, and assign an internal owner. There is no external documentation beyond AGENTS.md, no community, and 0 stars / 0 dependents means zero third-party validation or Stack Overflow surface.

Look elsewhere when:

• You want a community-supported CMS or admin — Statamic, Filament, Nova, Craft — or a single-purpose, well-maintained package for one concern (e.g., a standalone media library, Sanctum/Passport for auth).
• You need one small utility. Pulling in an entire foundation with pages, blocks, medias, and an auth provider for a helper is over-scoped and buys you coupling you didn't ask for.
• You require an SLA, vendor support contract, or external contributor community. This is a single-vendor internal asset; treat it that way.
• You're not on the supported Laravel/PHP matrix, or you need localization coverage and user-facing text the package doesn't ship.
• Your team has no relationship with Folklore and no appetite for reading source to understand behavior — the package explicitly optimizes for backwards compatibility with existing sites, not for newcomer ergonomics.

How to Pitch It (Stakeholders)

For executives: This is not a product we sell; it's Folklore's shared platform layer, and its value is amortization. Every site that uses it inherits the same content model, media pipeline, and authentication instead of paying to rebuild them, which shortens time-to-launch and lowers long-term maintenance cost across the portfolio. Optional modules (Customer.io, Google, PubNub, PubSubHubbub) let us add marketing, mapping, and realtime capabilities to the roadmap without new infrastructure. The latest release (v1.1.7) is a good illustration of why the model works: it lets sites move to Laravel 13, and it raises the minimum Guzzle version to one that carries a published security fix — one change, applied once, benefiting every site on the platform, with no upgrade work for sites that stay put. The cost of the strategy is vendor concentration: one internal codebase underpins many sites, so it needs a named maintenance owner and disciplined version pinning, and framework upgrades across the portfolio are paced by this package's releases. Recommendation: adopt on new builds and migrations where we're already inside the Folklore ecosystem; do not position it externally as an open-source dependency.

For engineering: The package is a deliberately conservative foundation. Its working rules are additive, opt-in changes with defaults that preserve current behavior, deprecate-before-remove, and modules that cost nothing when unused — no boot side effects, no heavy mandatory dependencies. v1.1.7 holds to that: Guzzle is now ^7.15.2|^8.0.1 (Laravel 13 only takes Guzzle 8; Laravel 11/12 stay on 7), Google Places no longer throws under Guzzle 8 when app.url is null, MakesRequests no longer fails on a Guzzle request exception (exceptions without a response are handled, and on Laravel 11 requestJson()/requestData() now receive a Laravel response rather than PSR-7, so redirect overflows no longer break them), and CI now exercises the lowest accepted Guzzle 7 and 8 releases with the installed versions printed per job. There are no upgrade steps for sites staying on Guzzle 7. Quality gates are real: PHPUnit via Orchestra Testbench across PHP 8.3/8.4 × Laravel 11–13, plus MySQL and lowest-Guzzle matrices in CI, with Pint and Larastan enforced (no new baseline errors). Requirements are PHP ^8.3 and Laravel 11–13, active development on v1.1. The trade-off to accept going in: zero external adoption (0 stars, 0 dependents) means we are the only readers of this code — budget for internal documentation and code review, and keep an escape hatch so no single module becomes load-bearing without a fallback.