Weave Code
Icons Laravel Package
orchid/icons
Laravel package for Orchid Platform that adds a flexible icon system for admin interfaces. Render icons in Blade, manage a consistent icon set, and customize usage across your application with a simple Composer installation and straightforward configuration.
Simple and Minimal Line Icons
Frequently asked questions about Icons
- How do I install orchid/icons in a Laravel application?
- Install it with a single Composer require of orchid/icons. Laravel package auto-discovery registers the service provider, so no manual wiring is needed. You can optionally publish the config and assets with vendor:publish if you want to customise paths or the default icon set. After that, icons are available in Blade through the component or helper.
- Does orchid/icons work outside the Orchid Platform admin?
- Only loosely. The package is a presentation-layer dependency built for Laravel and Blade and is first-class inside Orchid admin surfaces such as menus, form fields, table actions and layouts. In a plain Laravel app you would have to consume the raw SVG paths yourself, which loses most of the benefit. Treat it as an admin-UI dependency rather than a general-purpose icon system for customer-facing frontends.
- How do I render an icon in a Blade template with orchid/icons?
- Rendering is a one-line Blade call such as the icon component with a name like tabler.home, or the equivalent helper. Icons inherit sizing and currentColor, so they match surrounding text and buttons without extra styling. The same call site is used across menu builders, table row actions, empty states and modal headers.
- Which Laravel, PHP and Orchid Platform versions does orchid/icons support?
- Check the Composer constraints in the package before adopting it, because the package has essentially no external production validation behind its API surface. Version drift against a pinned orchid/platform, Laravel and PHP combination is the main practical risk. Pin the package version, run a short spike against your real admin screen, and confirm compatibility in CI before wider rollout.
- What licence applies to the bundled icon sets in orchid/icons?
- The package bundles icon sets such as Font Awesome, Bootstrap Icons and Tabler, and each of those carries its own licence terms. The package licence does not automatically override the terms of the bundled assets. Confirm commercial use and redistribution rights for every bundled set before shipping them in a distributed or client-facing product.
- What happens if I use an unknown icon name in orchid/icons?
- Unknown identifiers render an empty SVG rather than throwing an error, which leaves a blank gap in the UI that easily survives code review. That silent failure mode is the most likely day-to-day bug with this package. Validate icon names in tests or wrap the component so missing icons are caught during development.
- Do orchid/icons SVGs render under a strict Content Security Policy?
- This is unverified and should be tested against your actual policy. Inline styles or unsanitised SVG paths can violate CSP directives or widen the injection surface. Run a spike on a real admin screen with your production CSP headers before committing to the package.
- Are orchid/icons icons accessible to screen readers?
- Accessibility semantics are not documented, so treat decorative versus semantic handling as unverified. Decorative icons should be hidden with aria-hidden while meaningful icons need a label, and the package does not clearly guarantee either out of the box. Audit a representative screen with a screen reader and add attributes at your wrapper level if needed.
- How do I publish orchid/icons config and assets for production?
- Use the standard vendor:publish command to copy the config and any assets into your application. Be careful in production caching and CDN setups, because missing or unpublished assets fail quietly and produce blank icons. Verify rendering after every deploy and include an asset check in your release process.
- Is orchid/icons actively maintained, and should I vendor the SVGs?
- The package has no meaningful external validation, so release cadence and long-term maintenance intent are unproven. The good news is reversibility: the real value is portable SVG files behind a single Blade call site, so exiting is a sprint rather than a migration. Vendoring or forking the SVG set up front keeps future upgrades independent of upstream and is a reasonable default for a production admin.
Weaver
How can I help you explore Laravel packages today?