Weave Code
Breadcrumb Widget Laravel Package
friendsofvictoire/breadcrumb-widget
A lightweight breadcrumb widget for PHP applications that builds hierarchical navigation trails from your routes or data. Render customizable, accessible breadcrumbs with minimal configuration and drop them into any Laravel view or Blade template.
At a glance
Frequently asked questions about Breadcrumb Widget
- Is friendsofvictoire/breadcrumb-widget a Laravel package?
- No. It is a Symfony bundle built for Victoire DCMS, a Symfony-based CMS that is effectively discontinued. There is no Laravel service provider, facade, config publishing, or Blade view integration, so it cannot be installed as a drop-in Laravel dependency.
- Can I install this breadcrumb widget in a Laravel application?
- Composer may resolve the package, but the code expects Symfony bundle registration, Symfony DI container conventions, and Victoire widget and DCMS runtime services. None of those exist in a Laravel application, so it will not boot or render without a compatibility shim. That shim is disproportionate work for breadcrumb rendering.
- What does this package actually do?
- It builds hierarchical navigation trails from your routes or content data and renders customizable, accessible breadcrumbs. It also emits structured data using schema.org BreadcrumbList and supports widget-level configuration. The functional surface is narrow: trail structure, label resolution, truncation rules, and markup output.
- How do I install and configure friendsofvictoire/breadcrumb-widget?
- In its native environment you register the bundle in a Symfony kernel and configure it through Victoire's widget and DCMS runtime. There is no Laravel installation path, no publishable configuration, and no Blade integration. Laravel teams should replicate the breadcrumb pattern rather than install the bundle.
- Does this breadcrumb bundle support Laravel 10 or Laravel 11?
- No. The package targets Symfony bundle conventions and Victoire DCMS, and it has no Laravel service provider or version constraints aimed at modern Laravel releases. It is also likely pinned to older Symfony and PHP versions. Assume version drift until verified against your actual runtime.
- What are the best Laravel alternatives for building breadcrumbs?
- Use a maintained Laravel breadcrumb package or, better, a small native BreadcrumbBuilder service bound in a service provider plus an x-breadcrumb Blade component. That gives route-aware trails, label resolution, and JSON-LD output without legacy framework coupling. The reusable asset here is the UX and markup pattern, not the Symfony code.
- How do I migrate from this Victoire breadcrumb widget to Laravel?
- Read the bundle's widget definition and templates to capture the data model: trail structure, label resolution, truncation rules, and JSON-LD output. Reimplement it as a BreadcrumbBuilder service that turns the route or request into a trail collection, plus a Blade component emitting equivalent markup. Add a feature test asserting schema.org BreadcrumbList output to protect SEO parity.
- Is friendsofvictoire/breadcrumb-widget maintained and safe for production?
- It has zero stars, zero dependents, no visible downstream usage, and no security response process. Any CVE or PHP incompatibility becomes your fork to patch, and an unmaintained Composer dependency with transitive requirements is a standing audit finding. For breadcrumb rendering, the upside is minimal and the technical risk is high.
- Does this widget output schema.org BreadcrumbList structured data for SEO?
- Yes. The widget renders breadcrumbs with structured data using schema.org BreadcrumbList and allows widget-level configuration. If you port the pattern to Laravel, preserve the JSON-LD shape and test it so SEO and analytics continuity are protected. The markup conventions are the most reusable part of the bundle.
- Who should use this Symfony bundle instead of a Laravel implementation?
- Existing Symfony or Victoire applications that already have the runtime are the only defensible users. Laravel teams should treat it as a reference implementation to port, not as a dependency. If reuse is mandated, vendor it as a permanent fork, rewrite the Symfony coupling to Laravel contracts, and scope it as an internal library project.
Weaver
How can I help you explore Laravel packages today?