Permalink Laravel Package

Product Decisions This Supports

• Marketing autonomy vs. engineering bottleneck. Permalinks and SEO parameters stored in the database mean slugs, URL structures, and meta parameters can be changed by content/ops teams through an admin surface instead of a deploy. This is the core product decision this package enables: do we let non-engineers own the URL layer?
• SEO as a first-class product capability. If organic search is a growth channel, URL governance (canonical paths, redirects, locale-prefixed routes, category hierarchies) becomes a roadmap item rather than a one-off config. Database-driven routing makes SEO changes reversible and auditable without code review cycles.
• Build vs. buy for dynamic routing. The underlying capability — a catch-all route that resolves a path against a permalinks table and dispatches to a controller — is a few hundred lines of application code. Buying (or vendoring) this package is justified only if it saves a sprint and the team lacks bandwidth; otherwise in-house gives you control over caching, tenancy, and redirect semantics that a 2020 package won't.
• Multi-tenant and white-label SaaS. Per-tenant custom URL schemes (e.g., /{tenant}/blog/{slug} vs. /{tenant}/articles/{slug}) are a genuine differentiation feature for CMS, e-commerce, and storefront products. This package is a reference design for that pattern.
• Content migration and URL continuity. Any replatforming decision (legacy CMS → Laravel app) hinges on preserving inbound links. A DB-backed permalink registry with a redirect table de-risks migration — a strong argument in a rebuild-vs-patch decision.
• Roadmap signal, not a dependency. With 65 stars, zero dependents, and no release since December 2020, the package should inform architecture decisions rather than appear as a line item in the tech stack. Treat it as prior art.

When to Consider This Package

Consider it when:

• URL structure is expected to change frequently and non-engineers must own it (content-heavy marketing sites, SEO-driven commerce, directories).
• You need per-entity or per-tenant route customization that would otherwise mean hardcoded route files branching on tenant.
• You are scoping a CMS, blog engine, or marketplace and want a proven pattern for DB-backed route resolution before writing your own.
• You are planning a migration where hundreds or thousands of legacy URLs must map to new paths with redirects.
• You want a small, MIT-licensed reference to evaluate in a spike — a day of engineering time, not a production commitment.

Look elsewhere (or build in-house) when:

• Laravel version is modern. Last release 2020-12-17 predates Laravel 9/10/11; compatibility with the current framework is unverified. Engineering must confirm support before this enters a sprint, and assume it does not.
• You need maintained dependencies. Zero dependents and a single-maintainer project with no recent releases is an abandonment risk. A security or framework-compatibility fix may never arrive.
• Route resolution is performance-critical. DB lookups on every request need a caching layer; if you're at high traffic, a custom implementation with your own cache strategy will outperform retrofitting one.
• You need first-class support for localization, versioned APIs, or GraphQL routing — these are outside the package's scope.
• Your team can spare ~1–2 weeks. At that budget, an in-house permalink resolver tailored to your tenancy and caching model is the lower-risk choice and removes the dependency entirely.

Recommended posture: run a timeboxed engineering spike against your target Laravel version; if it needs patching, vendor the relevant logic into your codebase under MIT terms rather than adding a Composer dependency.

How to Pitch It (Stakeholders)

For executives: This is a small open-source component that lets marketing change URLs and SEO settings from a database instead of filing engineering tickets. It supports a real business outcome — faster SEO iteration and safer site migrations — but the project itself hasn't been updated since 2020 and has essentially no user base, so it is not something we should depend on as-is. The recommendation is to treat it as a design reference: either a short engineering spike to validate the pattern, or a small in-house build (roughly one to two weeks) that gives us the same marketing agility without the maintenance risk. Cost of the in-house path is low; cost of adopting an unmaintained dependency in our routing layer is a latent outage and upgrade risk at every future Laravel upgrade.

For engineering: The pattern is a catch-all route resolving incoming paths against a permalinks table, with SEO parameters and redirects co-located. It is a useful prior-art reference for the resolver and schema, but it predates Laravel 9+. If adopted, expect to fork and vendor it, own the caching layer, and write tests against your tenancy model. Budget for a spike first; do not add it to composer.json without a compatibility and maintenance review.