- What is saucebase/breadcrumbs used for in Laravel?
- It is a minimal Laravel package for defining breadcrumb trails as structured data rather than HTML. You register named trails with a fluent API, attach them to routes, and get back a list of crumbs you can render however you like. It suits Inertia apps, JSON APIs, and custom Blade components where you control the markup yourself.
- How do I install saucebase/breadcrumbs?
- Run composer require saucebase/breadcrumbs and Laravel package auto-discovery will register the service provider for you. An optional config file can be published with the vendor:publish command to change separators and other defaults. After that you create your breadcrumb definition file and start declaring trails.
- Which Laravel and PHP versions does saucebase/breadcrumbs support?
- Support is determined by the illuminate/support and php constraints in its composer.json, so check that file before planning an upgrade. Because the package is a fork of diglactic/laravel-breadcrumbs, its constraints reflect whichever upstream tag it diverged from. Confirm it covers your Laravel major version, since upstream compatibility fixes will not reach the fork automatically.
- How do I get breadcrumbs as an array or JSON in Laravel?
- Generate a named trail and convert it to an array, which gives you a flat list of crumbs with their title, url, and active state. That array can be shared as an Inertia prop or returned directly from a JSON endpoint such as /api/breadcrumbs. Pin the serialized shape with a contract test, because key names and url nullability are easy to break accidentally.
- Does saucebase/breadcrumbs include Blade views for rendering?
- No, the package deliberately drops the Blade rendering layer and treats breadcrumbs as data only. You loop over the generated crumbs inside your own Blade component, or pass them to a JavaScript front end. If you want ready-made accessible markup out of the box, upstream diglactic/laravel-breadcrumbs is the better fit.
- Is the namespace Diglactic\Breadcrumbs or Saucebase?
- That is the first thing to check in composer.json and the package source, because it determines whether the swap is drop-in. If the Diglactic namespace is preserved, your definition files and facade imports keep working unchanged. If it has been re-namespaced, every import in routes/breadcrumbs.php and every manager call site must be updated in one commit.
- Can I install saucebase/breadcrumbs alongside diglactic/laravel-breadcrumbs?
- Not safely, because both register a breadcrumb manager and a facade alias, and a duplicate-load scenario fails hard at boot. The fork should declare a replace or conflict entry against diglactic/laravel-breadcrumbs in its composer.json, so verify that before installing. Always remove the old package in the same commit as the swap rather than letting both sit in the lock file.
- How do I migrate from diglactic/laravel-breadcrumbs to saucebase/breadcrumbs?
- Pin the fork to a tag or commit SHA, diff its composer.json against upstream for namespace and constraint changes, and update imports if required. Remove diglactic and delete any published views or render calls you no longer use. Add tests that pin the array output, then boot the app with both packages absent and present to confirm the replace behaviour.
- Is saucebase/breadcrumbs safe to use in production?
- The code footprint is small and it sits at the edge of the request lifecycle, so the architectural risk is low. The real risk is maintenance: it is a single-maintainer fork with no stars, dependents, or issue history, and upstream fixes will not flow to it automatically. Treat it as internal code you own, pin a version, and decide up front who bumps it when a new Laravel major ships.
- How do I customize breadcrumb separators and labels?
- Separators and default options live in the publishable config file, while individual crumbs carry their own titles when you define the trail. Because rendering is your responsibility, the separator is typically just a value you read from config inside your own template. Publish the config and read through the available keys before you hardcode anything in your views.