- How do I install and set up Sluggable in a Laravel application?
- Install it with Composer by requiring italofantone/sluggable, pinning an exact version rather than floating on a caret constraint. Publish the package config if the README instructs you to, then add the Sluggable trait to each Eloquent model that needs slugs and point it at the human-readable source column such as title or name. After that, create a record and confirm the slug is written, then run your existing application test suite on a branch before merging. No new infrastructure, queue, or datastore is required.
- Which Laravel and PHP versions does Sluggable support?
- The package is a standard Laravel-ecosystem library aimed at modern PHP 8.x and current Laravel releases, but you should verify the exact constraints in its composer.json before committing. Framework and PHP version requirements can change between releases, and that is one of the first things to check when evaluating an upgrade. If you are on an older Laravel version, test the install in a throwaway branch rather than assuming compatibility from the package description alone.
- How does Sluggable avoid duplicate slugs?
- It applies collision handling so that two records with the same source value do not end up sharing a URL, typically by appending a numeric or hashed suffix to the generated slug. The important detail for your application is the exact suffix strategy, because changing from -1 to -2 or to a hash will break existing links. Verify the behaviour by creating several records with identical titles in a test database and inspecting the stored values. Also check how it treats reserved words, empty source values, and very long titles, since those are common fallback paths.
- Will upgrading to version 2.1.0 change the slugs my application already generates?
- The release notes describe a refactor of the slug generation logic plus updated tests, which is the package core behavioural output even though the version bump is minor. A minor release promises the public API is unchanged, but it does not guarantee byte-identical strings for edge cases such as unicode, transliteration, case folding, punctuation collapsing, length truncation, and collision suffixes. Build a regression harness that generates slugs for a representative corpus of real titles under your pinned version and again under 2.1.0, then diff the output. Treat backward compatibility as an assumption to prove rather than a fact to rely on.
- Do I need to backfill slugs for records that already exist in my database?
- Slugs are generated when a model is saved, so rows created before you installed the package will not have one until they are touched. Write a one-off backfill command or job that iterates existing records and saves them, ideally in batches and inside a transaction you can monitor. Because slugs are load-bearing for routing, permalinks, sitemaps, and inbound links, plan redirects or keep old URLs working if the backfilled value differs from anything already published.
- How does Sluggable handle non-ASCII characters, emoji, and non-Latin titles?
- Transliteration, unicode normalisation, emoji stripping, RTL text, and case folding are exactly the input classes where slug generation refactors tend to drift. Test the package against a corpus of your real multilingual titles rather than a handful of English examples. Check whether it relies on an external transliteration library or on PHP intl extensions, since a new or dropped dependency is a common source of silent output changes. Record the resulting slugs as fixtures so future upgrades can be diffed against a known baseline.
- Is Sluggable safe to use in production, and how should I test it?
- The install is low blast radius, but the change is not, because slugs feed routing, canonical URLs, sitemaps, and any external link already pointing at a page. Pin the exact version, install on a branch, and run your application test suite with a couple of real feature tests that assert the stored slug string. Generate slugs for a read-only export of production titles under both versions and diff the output before deploying. Green CI in the package repository only shows internal consistency, not backward compatibility with your data.
- Can I customise the source column, separator, or slug format?
- Configuration is normally handled through the trait property or the published config file, letting you choose which attribute is used as the slug source and how the string is assembled. Check the published config schema in the README for the exact key names, because guessing them is a frequent source of confusion. Whatever you customise, capture the resulting output as snapshot tests so a future minor release cannot silently alter your URLs.
- How actively is italofantone/sluggable maintained, and what are the alternatives?
- The available evidence here is only a single line of release notes for v2.1.0, with no changelog, dependency manifest, or repository history supplied, so maintenance status still needs verifying. Check release cadence, open issue responsiveness, license, and whether a security policy exists before adopting it for anything customer-facing. If you need a more established option, spatie/laravel-sluggable and cviebrock/eloquent-sluggable are widely used, and Laravel built-in Str::slug plus a small model observer can cover simple cases without a dependency. Compare on maintenance activity and slug edge-case behaviour, not just feature lists.
- What happens to a slug when the model title is edited later?
- The package handles slug creation and updates, so an edited source column can produce a new slug on save depending on how it is configured. Decide deliberately whether published URLs should be immutable or should follow the title, because changing an existing slug breaks inbound links and any SEO equity attached to it. A common pattern is to freeze the slug after creation and add a redirect or canonical tag when the title changes. Whichever you choose, cover it with a feature test so an upgrade cannot quietly flip the behaviour.