Laravel Slugify Laravel Package

Getting Started

• Confirm runtime compatibility first: v2 requires PHP 8.4+ and Laravel 11 / 12 / 13. Apps on older PHP or Laravel should stay on v1.x.
• Install with composer require oliwol/laravel-slugify:^2.0. For existing v1 apps, composer update is generally enough, but still read UPGRADE.md.
• Start with the docs pages “Why Laravel Slugify?” and “ID-Anchored Slugs”, then the quickstart. The v1 → v2 upgrade guide is the first stop only if you are coming from v1.
• First use case: add slugging to a Post-style model, generate a slug from title, and use the model in route model binding. Begin with the #[Slugify] attribute for the simple case; move to slugConfig() only when the slug source or rules need to be dynamic.
• If you use Laravel Boost, check that the bundled slugify-development skill is discovered — it is useful as an in-editor reference for package conventions and common patterns.

Implementation Patterns

• Attribute-first for simple models. Use #[Slugify] where the slug source is static and the same for every record. This keeps model code declarative and is the lowest-friction path for standard blog posts, pages, categories, etc.
• slugConfig() for conditional behavior. Use the fluent SlugConfig API when the slug source depends on runtime state: locale, tenant, fallback columns, or feature flags. Keep the closure small and deterministic — it should describe how to derive the slug, not perform unrelated business logic.
• Use appendId for editable public content. Enable ID-anchored slugs on models whose titles/slugs are likely to change. Route keys become {slug}-{id}, resolution happens by ID, and stale slugs receive a 308 canonical redirect. This is a good default for public marketing pages, product pages, and CMS content where SEO continuity matters.
• Keep route generation model-based. Generate URLs with route('posts.show', $post) rather than hand-building /{slug} strings. This lets the package control the route key shape and keeps links correct if you later opt into appendId.
• Plan the Spatie v4 migration separately. If you are moving from Spatie’s package, follow the updated Spatie v4 migration guide rather than improvising. Verify slug generation, unique constraints, and route binding after migration.
• Test the redirect behavior explicitly. For ID-anchored models, add feature tests for: current slug returns 200, stale slug returns 308 to the canonical URL, and the model resolves by ID even when the slug segment is outdated.
• Roll out appendId deliberately. Treat it as a routing change: update sitemaps, canonical tags, hard-coded links, API responses, and any external integrations that assume /{slug} URLs.
• Use Boost as a development aid, not a dependency. The slugify-development skill is auto-discovered by Laravel Boost and helps with scaffolding and conventions; it does not change runtime behavior.

Gotchas and Tips

• v2 is not for older stacks. PHP 8.4+ and Laravel 11+ are hard requirements. Check CI matrices and deployment images before upgrading.
• “No breaking changes” still means opt-in behavior changes. appendId changes route keys and URL shape. Existing apps are unaffected until enabled, but enabling it is a public URL change.
• Be careful with 308 during rollout. 308 is permanent and aggressively cached by browsers. If you are testing redirect behavior in staging or behind a proxy, verify cache headers and consider testing with a temporary redirect strategy before shipping.
• ID-anchored slugs expose IDs. Resolution by ID means IDs appear in URLs. For most content this is fine, but consider enumeration, authorization, and soft-deleted records before applying it broadly.
• Closures in slugConfig() can capture request context. Tenant IDs, locales, and authenticated user state may not exist or may differ in queued jobs, console commands, and scheduled tasks. Pass explicit context or make the closure resilient to missing request state.
• Watch for query overhead. Conditional slug configuration that performs database lookups can add queries on every save. Cache stable lookups or keep conditions limited to attributes already on the model.
• Debug route binding with php artisan route:list. Confirm whether the route key is {slug} or {slug}-{id} and that the correct model binding is registered. If a stale slug is not redirecting, check route registration before debugging the package.
• Read UPGRADE.md even for a “composer update” upgrade. It is short, but it documents the intended v1 → v2 path and any configuration changes worth verifying.
• Extension point to keep in mind: if the built-in slug generation rules do not fit, prefer the SlugConfig fluent API or a small custom closure over forking package internals. Keep custom logic close to the model and covered by tests.