Kirby Db Laravel Package

Technical Evaluation

Architecture fit. Release 4.0.1 lands as a major-version line (4.x), and the notes confirm the headline breaking change: PHP 8.1 support is dropped. Any Laravel application still on PHP 8.1 cannot consume this release and must stay pinned to the prior 3.x line. Applications on PHP 8.2+ (Laravel 11/12 baseline) are the target. Treat this as a floor-raising release, not a feature release.

Integration feasibility. Low-to-moderate effort for greenfield or already-upgraded services; a hard blocker for any service on PHP 8.1. The remaining notes — migrating the package's own test suite from PHPUnit to Pest and refreshing GitHub Actions — are internal to the package's development workflow and carry no runtime, API, or autoload impact for consumers. They are signals of maintenance health, not integration work.

Technical risk. Concentrated in one place: the PHP runtime floor. Because the drop is declared at a major version, the risk is explicit and detectable rather than silent — Composer's php constraint will refuse to install on 8.1, which is the safe failure mode. The secondary risk is interpretive: the release adds "support for [email protected]," and Kirby is a flat-file PHP CMS, not a Laravel component. This strongly suggests the package spans multiple framework integrations under one version number, or that the changelog is aggregating across a monorepo. Until that is confirmed, do not assume the 4.x line is validated against your Laravel version.

Key questions.

1. Does the Kirby 5.x support live in the same package/version line as the Laravel integration, and is it additive or does it change shared internals?
2. What is the package's declared Laravel version constraint (illuminate/*) for 4.x, and is it verified in CI against our current LTS?
3. Is there a documented 3.x → 4.x migration guide, and does 3.x continue to receive security patches (and for how long)?
4. Which PHPUnit→Pest move — if any — affects consumers who extend the package's test base classes or ship its test helpers?
5. Was the PHP 8.1 drop accompanied by removal of any deprecation shims that consumer code might still call?

Integration Approach

Stack fit. This package assumes PHP ≥ 8.2 and, by the major bump, is aligned to the modern Laravel generation. Confirm the illuminate/support (or framework) constraint explicitly before scheduling work — the notes tell us the PHP floor but say nothing about the Laravel ceiling or floor.

Migration path. Two distinct tracks, and they must not be conflated:

• Runtime track: upgrade the host application's PHP from 8.1 to 8.2+ first, validate the app on its current package version, then bump the package. Bumping both simultaneously makes failures unbisectable.
• Package track: pin to ^3.0 where PHP 8.1 is still required; adopt ^4.0 only on services already on 8.2+.

Compatibility. Because 4.0.1 is the first release in the 4.x line cited here, treat it as a .1 — there is no visible 4.0.0 changelog in this data. Confirm whether 4.0.0 shipped additional breaking changes that 4.0.1 inherits silently. Also verify that the package's PHP constraint is not stricter than the host app's (e.g. package requires 8.2 but a transitive dependency caps at 8.1 — Composer cannot resolve that).

Sequencing.

1. Inventory every service using this package and its current PHP version — this produces the blast radius.
2. Freeze new adoption of ^4.0 until the Laravel constraint and the Kirby-integration question are answered.
3. Upgrade PHP on the lowest-risk service first; upgrade the package there; soak in staging.
4. Roll the validated pairing outward; leave PHP 8.1 services pinned on 3.x with an explicit end-of-support date on the calendar.
5. Only after the runtime migration is complete, evaluate whether the Pest/CI changes warrant any change to our own test conventions (they should not).

Operational Impact

Maintenance. The PHPUnit→Pest and GitHub Actions updates are positive maintenance signals: the maintainer is investing in CI and modern tooling. That reduces the risk of stale-dependency drift. The trade-off is that a maintainer willing to drop a PHP minor and bump a major is signalling a fast-moving version policy — expect a shorter support horizon on any given major and budget for recurring upgrade work rather than treating this as a one-off.

Support. The critical operational fact is the support status of 3.x. If 3.x is not receiving security patches, every PHP 8.1 service is running unsupported code, and the PHP upgrade becomes a security workstream rather than a roadmap convenience. Get a written answer before the next planning cycle. Also confirm the package's issue-response posture, since a major bump typically generates a wave of breakage reports.

Scaling. No scaling or performance implications are indicated — none of the four changes touch runtime behaviour for consumers. The one scaling-adjacent concern is version sprawl: if part of the fleet sits on 3.x and part on 4.x, you inherit two support surfaces, two upgrade paths, and a harder time reasoning about behaviour differences across environments. Consolidate deliberately.

Failure modes.

• Loud (preferred): Composer refuses installation on PHP 8.1 due to the php constraint. Safe, immediate, actionable.
• Silent (watch for this): a service upgrades PHP but not the package, or upgrades the package without verifying the Laravel constraint, and a Kirby-related internal change surfaces as a runtime error in a shared code path. This is the scenario worth a regression suite.
• Drift: no explicit 3.x EOL date means the fleet quietly accumulates unsupported services with no forcing function.

Ramp-up. Minimal for engineers — no new APIs or patterns are introduced for consumers, so there is no learning curve. The real cost is coordination, not skill: environment upgrades, dependency pinning, and staged rollout across services. A single engineer can execute this; it needs a TPM to sequence it and to hold the 3.x support question as the gating decision.