Kirby Db Laravel Package

Product Decisions This Supports

• Platform currency / upgrade unblocking: The headline is Kirby 5.x support. If your roadmap includes a Kirby upgrade (or you're evaluating Kirby for a content surface alongside a Laravel app), this release is the gate that lets you proceed rather than fork or patch the integration yourself.
• Runtime floor planning: Dropping PHP 8.1 moves the minimum to PHP 8.2+. This should feed directly into your hosting/CI baseline decision and your Laravel version floor (Laravel 11+ is already 8.2+, so this release aligns the package with a modern stack rather than fighting it).
• Build vs. buy: The integration surface here is narrow (a compatibility shim between a Laravel/PHP application and a Kirby content layer). Before committing, size the glue code you'd actually own — if it's a few service providers and a content-mapping layer, maintaining it in-house is a real option; if it's deep routing/templating/plugin interop, buy.
• Risk register entry: A PHP support drop shipped in a patch release (4.0.1) is a SemVer signal worth noting. It means the maintainer treats platform-floor changes as non-breaking. Plan to pin exact versions and read every release note rather than trusting caret ranges.
• Maintenance-health signal: The PHPUnit→Pest migration and GitHub Actions refresh indicate an actively maintained project with modern tooling — a positive input to the "is this dependency safe to depend on for 2+ years" call, even though neither change is user-facing.
• Support matrix documentation: These notes give you the data to publish an explicit supported-combination table (package version × Kirby version × PHP version × Laravel version) for your own teams, which is the artifact that prevents most integration incidents.

When to Consider This Package

Consider adoption when:

• You are running (or planning) Kirby 5.x in a PHP application and do not want to own the compatibility layer.
• Your runtime is already PHP 8.2+ (or you're willing to move — this release makes 8.1 a hard blocker).
• Your need is integration/compatibility, not a full CMS replacement — you want Kirby's content model available to a Laravel-style codebase, not a Laravel-native CMS.
• You want a dependency whose maintenance cadence is visible (recent CI, test-framework, and platform updates are all good proxies).

Look elsewhere — or stay on the prior major — when:

• You are pinned to PHP 8.1 with no near-term upgrade path (shared hosting, legacy deploy images, long-lived LTS constraints). This release is a hard stop for you.
• You need first-party vendor support, SLAs, or security backport guarantees — this is a community package; the patch-level platform drop shows versioning discipline is not contractual.
• You need a Laravel-native CMS (statutory content workflows, admin UI, permissions) rather than a bridge to an external CMS.
• The glue code you'd need is genuinely small — a handful of bindings and a content mapper is often cheaper to own than to track across Kirby major versions.
• You need Kirby 4.x and 5.x simultaneously across products; verify whether a single package version spans both or whether you'll be maintaining a version matrix across your fleet.

How to Pitch It (Stakeholders)

To executives: This is a small, low-risk dependency release, not a feature launch. Its business value is that it keeps our CMS integration current with Kirby 5.x, which removes a blocker from any planned content-platform upgrade and avoids a bespoke fork we'd otherwise have to maintain. The one decision it forces is a runtime baseline: we need PHP 8.2 or newer, which is already where modern Laravel sits, so the cost is CI and hosting alignment rather than application rework. Recommendation: adopt, pin the version, and treat future releases as "read the notes before bumping."

To engineering: Version 4.0.1 adds Kirby 5.x support, drops PHP 8.1 (minimum is now 8.2), and modernizes the project's own tooling (Pest, updated Actions). Nothing here changes our integration code paths, but two things need checks before merge: (1) confirm our CI images, local dev containers, and deploy targets are all on 8.2+; (2) walk our Kirby templates/plugins against Kirby 5's own breaking changes — this package supports Kirby 5, it does not shield us from Kirby 5. Because the PHP floor moved in a patch release, use exact version pinning and an explicit upgrade ticket rather than auto-merging dependency updates. Run the full suite on the bumped version and capture the resulting package × Kirby × PHP combination in our support matrix.