Page Link Type Extension Laravel Package

Technical Evaluation

Architecture fit. This is not a general-purpose Laravel package — it is a PyroCMS (Anomaly Labs) Streams Platform extension. It registers a page link type with the Navigation module so that menu items can resolve to entries managed by the Pages module. It will only fit a codebase already running PyroCMS 3.x with anomaly/navigation-module and anomaly/pages-module present. In any other Laravel application it contributes nothing callable; it is an addon that plugs into the host CMS's link-type registry, service provider boot sequence, and module contracts.

Integration feasibility. Straightforward if the host is PyroCMS: composer require anomaly/page_link_type-extension, then php artisan addon:install anomaly.page_link_type-extension. The package is MIT, small, and follows the standard addon layout (service provider, link type class, lang/config). Feasibility outside PyroCMS is effectively zero without a rewrite of the equivalent link type against your own navigation abstraction.

Technical risk. High, dominated by ecosystem abandonment rather than code quality. Signals: 0 stars, 0 dependents, no community, PyroCMS itself is in maintenance/limbo and its next-generation Streams work is stagnant. The package is tightly coupled to the Navigation module's link-type contract; a contract change or a PHP/Laravel bump in the host breaks it with no upstream maintainer to fix it. Because there are no tests and no releases to inspect, the link resolution behavior (does it store a URL or resolve page URI at render time?) must be verified by reading the source. Rendering surface is a menu link, so the security exposure is low but not zero (stale or injected URIs, 404s for deleted pages).

Key questions.

• What PyroCMS/Laravel/PHP versions does our host run, and does the package's composer.json constraint on anomaly/navigation-module resolve against our installed version?
• Does the link type resolve the page URI dynamically at menu render, or persist a URL at authoring time? This determines the failure mode when pages are renamed or unpublished.
• Is there a graceful fallback when the referenced page is deleted or deactivated (link suppressed vs. rendered 404)?
• Who owns this upstream, and are we prepared to fork and maintain it under MIT?
• Is Navigation + Pages actually in scope for our roadmap, or is this package being evaluated as a pattern rather than a dependency?

Integration Approach

Stack fit. Laravel (PyroCMS 3.7–3.9 era, Laravel 8/9, PHP 7.4/8.x). It is a first-class fit only inside PyroCMS. For teams not on PyroCMS, its value is as a reference implementation of a custom navigation link type — the pattern is portable, the code is not.

Migration path. If we are on PyroCMS and currently hardcoding menu URLs, the path is: adopt the Navigation module, install this addon, then migrate menu content from static URLs to page-backed link items. That is a content migration, not a code migration, and should be scoped and owned by whoever manages site content. If we are not on PyroCMS, there is no migration path — build the equivalent link type against our own nav contract, which is typically a single class implementing a resolve(): string interface.

Compatibility. Pin the addon and its module dependencies to exact versions in composer.lock; verify the constraint graph in staging before any production step. Because the license is MIT, a vendor fork is permissible and likely necessary if the host is upgraded past the package's supported range.

Sequencing.

1. Confirm host PyroCMS version and confirm Navigation and Pages modules are installed and healthy.
2. Read the addon source to determine link resolution semantics and fallback behavior before committing.
3. Require and install in staging; smoke-test menu rendering, page rename, page deletion, and unpublished-page scenarios.
4. Decide fork-vs-consume; if forking, add tests around the link type contract in the same sprint.
5. Only then migrate real menu content, with a rollback that restores static URLs.

Operational Impact

Maintenance. Treat as effectively unmaintained. Budget for a small internal fork the moment the host framework or Navigation module moves. The code footprint is small, so ongoing ownership cost is low — but it is not zero, and it cannot be deferred indefinitely.

Support. No community, no issue triage, no dependents to lean on. Requires a named internal owner; "whoever touches the CMS" is not sufficient.

Scaling. Negligible. Link-type resolution is metadata attached to navigation items and is cached with the menu; it does not add per-request query load beyond what Navigation already does. No scaling concern at any realistic traffic level.

Failure modes.

• Deleted or renamed page leaves a stale or 404 link in the menu.
• Unpublished page still resolves and links to a hidden route.
• Version-constraint mismatch blocks addon:install or breaks on a host upgrade.
• Navigation module removed/upgraded independently → class-not-found at boot.
• Upstream abandonment means a future PHP/Laravel bump has no fix path except our fork.

Ramp-up. Low in absolute terms, high relative to package size: a developer unfamiliar with the Streams/Addon architecture spends more time learning the host CMS than the package. For an existing PyroCMS developer this is a half-day to a day of work; for a Laravel-only developer, plan 2–3 days including the architecture learning curve.

TPM verdict. Low-leverage dependency. Pursue only if the product is already committed to PyroCMS and the Pages/Navigation combination is on the roadmap; otherwise harvest the pattern — a thin, testable link type — and implement it against our own navigation abstraction. The 0-star, 0-dependent signal is not a reason to avoid the idea, but it is a reason not to take a maintenance obligation we have not explicitly staffed.