Layouts Core Laravel Package

Product Decisions This Supports

• Unblocks the PHP 8.0 platform upgrade. Release 1.4.14 republishes the 1.4 line as se7enxweb/layouts-core (replacing netgen/layouts-core) and widens the constraint to php ^7.4 || ^8.0. This is the dependency that lets Platform 2.5 (CJW Exponential Platform Nexus) run on PHP 8.0. Treat it as an enabler on the upgrade critical path, not as a feature delivery.
• Confirms "keep, don't rebuild" for page layout. Block-based layout composition is retained at the Netgen Layouts 1.4 API surface. No migration of templates, block definitions, or layout config is required — so no scoping of a replacement CMS/page-builder effort in this cycle.
• Establishes a fork-ownership decision. The 1.4 line now has a new package identity and a downstream maintainer. That converts an implicit dependency on Netgen's release cadence into an explicit dependency on ours (or a partner's). Product should record who owns patching this fork and what the trigger is to move off it.
• Introduces a version-reporting requirement. Because Composer keeps no version for a replaced package, bundles that read the installed version of the layout core fail — and the container build failed on exactly this. Health checks, admin "about" screens, support bundles, and telemetry must tolerate an unknown/absent version for this package. Plan a small work item to audit version-reading code, otherwise support triage and incident response lose a diagnostic signal.
• Sets a roadmap ceiling to plan around. The fork is based on 1.4.13 and is a compatibility bridge, not a modernization. PHP 8.0 is itself end-of-life, so this buys time rather than resolving the underlying platform-currency question. Put "exit the fork" (upgrade to a supported Netgen Layouts line or remove the dependency) on the roadmap with a dated checkpoint.

When to Consider This Package

Adopt when all of the following hold:

• You are pinned to Platform 2.5 / PHP 8.0 and cannot move the runtime first; the widened constraint is the specific blocker this resolves.
• You need the Netgen Layouts 1.4 API and existing layout/block configuration to keep working unchanged — i.e., migration cost is the dominant constraint.
• You can accept a community/downstream-maintained fork: no vendor SLA, patching driven by the fork owner, and upstream 1.4.13 as the feature baseline.
• You have a named internal owner for the dependency and a plan to re-test on each fork release.

Look elsewhere when:

• You are already on PHP 8.1+ — go to a supported upstream Netgen Layouts line rather than a 1.4-era fork.
• You require vendor support, a CVE response SLA, or security backport guarantees; that is a procurement question a fork does not answer.
• Your code or tooling depends on Composer-reported versions of replaced packages (monitoring, licence scanning, SBOM generation). Expect netgen/layouts-core to report no version and budget for that.
• You need new layout-editing capability or active feature development; this release is maintenance and compatibility, not forward features.
• The platform upgrade can be re-sequenced so the fork is never needed — prefer that path, since every month on the fork accrues exit cost.

How to Pitch It (Stakeholders)

For executives: We were blocked from running Platform 2.5 on PHP 8.0 by a single third-party page-layout library. Release 1.4.14 of that library is now published under a new package name we can install, with the PHP 8.0 constraint opened up, and it keeps our existing page layouts working with no rework. That clears the blocker. Two caveats to note: this is a downstream-maintained fork pinned to the 1.4.13 feature baseline, so it buys us time rather than modernizing us, and PHP 8.0 is itself out of support — so the recommendation is to proceed with the upgrade now while scheduling the follow-on move to a supported line. Cost is low; the main new obligation is naming an owner for this dependency and tracking its releases.

For engineering: Swap netgen/layouts-core for se7enxweb/layouts-core — it declares a replace, allows php ^7.4 || ^8.0, and is based on 1.4.13, so no template or block-definition changes. Watch the replace semantics: Composer records no version for a replaced package, and 1.4.14 exists specifically because bundles reading the installed layout-core version broke the container build. Audit any code, health check, or build step that inspects that version and make it fail-soft. Assume the fork's patching cadence is ours to drive: pin the version, track releases, and keep an exit path to a supported upstream line on the roadmap.