eminos/statamic-iconify
Integrate Iconify with Statamic via a searchable fieldtype that lets editors browse and select from thousands of open-source icons. Render chosen icons easily in your Antlers templates, with straightforward installation and configuration for flexible, consistent icon usage across your site.
Architecture fit: statamic-iconify is a Statamic addon on Laravel/PHP that fits naturally into a Statamic-based content stack. v2.1.0 adds a governance layer: a publishable global config (allowed_prefixes, allowed_categories, allowed_licenses, default_store_as) plus field-level filters that can only narrow the global allowlist. This is a useful TPM control because it lets platform owners define approved icon sources and licenses centrally while giving blueprint authors bounded choices. The new CP endpoint GET /iconify/config supports front-end config access and is consistent with an addon architecture rather than a separate service.
Integration feasibility: Integration is low-to-moderate effort. The package is installed/updated via Composer, configuration is published with php artisan vendor:publish --tag=statamic-iconify-config, and filtering is applied through native Statamic blueprint select dropdowns. There are no database migrations called out. The main effort is governance: deciding allowed icon sets, categories, and licenses, then updating blueprints. Feasibility depends on confirming supported Statamic, Laravel, and PHP versions, and on whether the project already uses the Iconify fieldtype.
Technical risk: The primary risk is external dependency on the Iconify /collections API for populating dropdowns and search-modal metadata, cached for 24 hours. Cold-cache or API-outage scenarios could affect editor experience even though cached data mitigates steady-state usage. License filtering is a valuable compliance control but depends on Iconify metadata accuracy; it should not be treated as legal review by itself. The new CP endpoint should be verified as appropriately authenticated/authorized. No breaking changes are announced, and the release adds Pest/Vitest test coverage plus a fix for plain-string field values, which lowers regression risk. Dark mode fixes are UI-only.
Key questions:
GET /iconify/config restricted to authenticated control-panel users?Stack fit: The package fits a Laravel + Statamic stack as a Composer-installed addon. It uses native Statamic blueprint fields, configuration, and control-panel UI, so it should not require a separate icon service or custom front-end integration. The global config provides a central policy point; field-level filters provide delegated, bounded choice.
Migration path: Treat v2.1.0 as a minor feature upgrade from v2.0.x. The expected path is: update via Composer, optionally publish the config file, define global allowlists, then add field-level filters to existing Iconify fields. Existing fields should continue to work if defaults preserve prior behavior, but this must be verified in staging. No database migration is indicated. If the project has not yet used the package, start with a single blueprint field and expand after editor validation.
Compatibility: Confirm version constraints before upgrading. Verify that the project’s Statamic version supports the native select dropdowns and CP endpoint behavior described. Confirm the Iconify API contract used by /collections remains stable. Check that the cache driver used in each environment is shared where needed; a per-node file cache could produce inconsistent dropdown data across control-panel requests. Run the package’s Pest and Vitest suites where practical, and smoke-test in staging before production.
Sequencing:
config/statamic-iconify.php and set global allowed_prefixes, allowed_categories, allowed_licenses, and default_store_as.Maintenance: Ongoing maintenance is mostly configuration governance rather than code maintenance. Platform owners should review allowed icon sets and licenses periodically, keep the config file in version control, and watch for Iconify metadata changes. The 24-hour cache reduces API load but means allowlist metadata can be stale for up to a day. Test coverage in Pest and Vitest improves upgrade confidence, but the addon remains an external dependency.
Support: Content editors should see a simpler, filtered icon experience, but they will need brief guidance on why some icons are unavailable. Administrators need clear ownership of the global allowlist and license policy. The new dropdowns are largely self-documenting, and filter badges in the search modal help explain active constraints. Support should document how to request allowlist changes.
Scaling: Editor-facing calls are cached for 24 hours, which should scale for normal control-panel usage. Large icon sets could make dropdowns or search modal metadata heavier, but filtering narrows the set. For larger teams, consider pre-warming the cache during deploy and using a shared cache backend. The CP endpoint adds a lightweight config surface, but should be monitored for access patterns and authorization.
Failure modes: The main failure mode is Iconify API unavailability with a cold cache, which could prevent dropdown population or fresh metadata. Stale cache is a lesser issue. Misconfigured allowlists can block icons editors need; field-level filters cannot widen the global config, so mistakes require a config change and redeploy/config refresh. License metadata inaccuracies could create compliance gaps if treated as authoritative. The CP endpoint could expose configuration if authorization is misconfigured. The plain-string crash fix removes a known failure path for existing content.
Ramp-up: Ramp-up is low for content editors and moderate for Statamic administrators/developers. Editors mainly need to understand filtered results and badge indicators. Admins need to learn the config file, blueprint dropdowns, cache behavior, and license governance. A staged rollout with one pilot blueprint is advisable before applying filters site-wide.
How can I help you explore Laravel packages today?