Slug Bundle Laravel Package

Product Decisions This Supports

• Slug strategy for content and routes. Whether titles auto-generate slugs, whether editors can override them, how collisions are resolved, and whether slugs are immutable after publish. This package only covers string-to-ASCII-slug conversion; uniqueness, redirect history, and editorial override workflows remain product-owned decisions.
• Build vs. buy vs. use in-core. A concrete data point for the “library or a few lines?” question. In Laravel, Str::slug() already covers the core need, so this package rarely changes the decision — and when it does, it argues against adding a dependency.
• Roadmap and legacy triage. If this package appears in a dependency audit, treat it as a signal about the codebase — Symfony2-era, PHP 5.x, Twig-coupled — not as a feature decision. That points to a modernization initiative, not product roadmap work.
• Internationalization scope. Any requirement for transliterated slugs (Cyrillic, CJK, Arabic, diacritics) must be scoped outside this package. It is ASCII-oriented, unmaintained, and not suitable as the foundation for i18n URL strategy.
• SEO and URL permanence. Decisions about stable public URLs, slug changes, and 301 redirects are product-level concerns. The package does not enforce uniqueness, preserve slug history, or handle redirects.
• What it does not support: security patching, PHP 8+ / Laravel compatibility, vendor support, community answers, or a maintained release cadence. Do not let it anchor a decision that assumes any of those exist.

When to Consider This Package

Adopt only in a narrow legacy case:

• You maintain an existing Symfony2 application on PHP 5.x where the bundle is already installed and working. Leave it in place; replacing it is churn with no user-visible benefit.
• You need a trivial Twig slugify filter in that same legacy app and are unwilling to add a Composer dependency.

Look elsewhere in nearly every other case:

• Laravel, or any greenfield PHP work. This is a Symfony2 bundle — bundle registration and service-container wiring do not map to Laravel. Use Laravel’s Str::slug(), optionally with a maintained package such as spatie/laravel-sluggable when persistence and uniqueness are needed.
• Symfony 4+. Use symfony/string’s AsciiSlugger; it is in-core, locale-aware, and maintained.
• Framework-agnostic PHP. cocur/slugify is better maintained and supports transliteration rules.
• Any requirement involving i18n slugs, uniqueness enforcement, slug history/redirects, PHP 8.2+, Laravel service providers, or a security patch SLA.

Diligence flags: zero stars, zero dependents, Symfony2-only, no visible release or license signal in the summary, and score 0. Treat it as end-of-life and unsuitable for new Laravel work.

How to Pitch It (Stakeholders)

Executives: Slug generation is a commodity capability — Laravel, Symfony, and standalone PHP libraries all provide it in-core or through maintained packages. We recommend against adopting rudak/slug-bundle: it is a Symfony2-era bundle with no stars, no dependents, and no sign of maintenance. Adding it to a Laravel product buys nothing and introduces supply-chain, compatibility, and upgrade risk for functionality we already get free. If it exists in a legacy service, keep it running and fold its replacement into that service’s next modernization pass. If it appears in a new proposal, reject it.

Engineering: This is a Twig filter plus a small slugifier for Symfony2 — narrow scope, no maintenance, and no Laravel integration path. Do not add it to new work. Use Str::slug() in Laravel; use spatie/laravel-sluggable if you need database-backed uniqueness; use AsciiSlugger on Symfony 4+; use cocur/slugify for framework-agnostic needs. All are strictly better on transliteration, locale handling, and support. Action: log it as an EOL dependency in the SBOM, attach a remediation ticket to replace it with Laravel-native slugging the next time the owning service is touched, and stop new references to it.