- How do I install marshmallow/sluggable in a Laravel application?
- Install it with Composer using composer require marshmallow/sluggable, then rely on Laravel package auto-discovery for the service provider. Publish the package config and migration, run the migration to add your slug column, and add the package trait to the Eloquent model that needs slugs. From there you declare which attribute the slug is generated from, such as a title or name column. Realistic effort for a single pilot model is roughly one to three developer days including tests.
- Which Laravel and PHP versions does marshmallow/sluggable support?
- Version 1.12.0 widens the illuminate constraints to cover roughly Laravel 10 through 13, with PHP 8.1 or newer, so confirm the exact PHP floor for Laravel 13 before relying on it. The important caveat is that a widened constraint is not the same as tested support. Check whether the CI matrix actually installs and runs against a real Laravel 13 application, because an untested constraint bump can invite installation on an unsupported combination.
- How does marshmallow/sluggable handle duplicate slugs and collisions?
- The package advertises built-in duplicate handling, typically appending suffixes such as -2 and -3 when a slug already exists. Before adopting it, verify whether uniqueness is enforced by a database unique index or only by an application-level check, since that difference matters under concurrent writes. Also confirm what happens on a duplicate: an exception, a silent overwrite, or a suffixed retry.
- Does marshmallow/sluggable work with Eloquent models and route model binding?
- Yes, the package is built around an Eloquent trait, a slug column, and Laravel model events, so slugs live on the persistence model and can be used as route keys alongside Route::resource and implicit binding. Treat any framing around Laravel Resources carefully: if that means API Resources, that is the presentation layer and the wrong place to store slugs. Confirm the trait attaches to models rather than JsonResource classes, and check whether it hooks resolveRouteBinding and supports Route::bind overrides.
- Is marshmallow/sluggable safe to use in production?
- The dominant risk is maturity rather than code quality. The repository has zero stars and zero dependents, which means no production evidence, no third-party bug reports, and a single-maintainer bus factor. Version 1.12.0 is a mildly positive signal of activity, but two merged pull requests are not a support commitment. Pilot it on a low-traffic model such as Tag or Category in a feature branch before committing it to production.
- What happens to existing slugs when the source title or name changes?
- This is the behavior you must validate first, because silently regenerating slugs on update breaks live URLs and damages SEO. Look for a documented immutability policy or a configurable update behavior that lets you freeze the slug after creation. If slugs do change, you need a redirect story, ideally a 301 mapping from old to new slugs, before you enable regeneration anywhere that matters.
- Can I have unique slugs scoped per tenant, parent category, or locale?
- The overview does not document scoped uniqueness, so treat it as something to test rather than assume. In multi-tenant, nested category, or multi-locale applications you need a uniqueness rule scoped to the parent, and you need to confirm how the package interacts with soft deletes. Verify both the generated collision suffixes and the database index are scoped the same way as the application check.
- How does marshmallow/sluggable compare to spatie/laravel-sluggable?
- Spatie's package is the established option with broad adoption, third-party bug reports, and ecosystem pressure on the maintainer, while marshmallow/sluggable is a thin, lightweight trait that has to earn its place through ergonomics rather than capability. Many applications are already served by hand-rolling Str::slug in a model mutator plus a getRouteKeyName override. Before switching, weigh the exit cost: if the package is abandoned, how much of your slug logic and data has to be reimplemented?
- How do I backfill slugs for existing records that already have none?
- Plan backfilling as separate work from the initial integration, because it is not part of the one-to-three-day pilot estimate. Generate slugs in chunks over existing rows, handle collisions deterministically, and add the supporting index before the column goes live on large tables. During the transition, keep your existing ID or UUID URLs resolving in parallel so both keys work until redirects are proven in staging.
- Does it support custom slug columns, separators, and Unicode titles?
- Yes, the package supports custom slug columns and source fields as well as a configurable separator, which is useful when a title field is not the right source. The open questions are transliteration and Unicode handling for non-Latin titles, plus how the database collation affects case sensitivity in uniqueness checks. Test these with real content from your application before rolling the trait out across models.