Filament Meta Laravel Package

Getting Started

• Install the beta explicitly: composer require <vendor>/filament-meta:0.1.1-beta.1 (or the package’s documented constraint). This release fixes a deploy-time crash, so avoid older 0.1.0 builds in CI/CD.
• Look first at:
  • README.md for panel registration and meta field usage.
  • The package service provider for the filament-meta views namespace and config merge.
  • config/filament-meta.php (if published) for defaults, model/resource mappings, and rendering options.
  • Any Blade views/components under the filament-meta namespace for how tags are rendered.
• First use case: add SEO/meta fields to a Filament resource or page, register the plugin on a panel, then render the resulting meta tags in your frontend layout.
• After install, run php artisan filament:optimize or php artisan optimize in a staging environment to confirm the previous view:cache/Finder.php:663 crash is gone.

Implementation Patterns

• Register the plugin/panel integration in the relevant Filament panel provider, typically alongside other panel plugins. Keep registration environment-agnostic so local and production panels behave the same.
• Publish config and views only if you need to override defaults. Prefer config overrides for simple changes; publish views only when markup must change.
• Model/resource pattern: attach meta fields to the Filament form schema, persist meta values through the package’s model/trait or your own relation, and resolve them when rendering the public page.
• Blade integration: use the package’s component/directive in your frontend <head> rather than manually assembling tags. This keeps escaping and fallback behavior consistent.
• Multi-panel setups: register the plugin per panel and verify each panel’s view namespace resolution. Avoid relying on a global namespace if panels have different layouts.
• Deployment workflow: run composer update, php artisan optimize:clear, then php artisan view:cache and php artisan optimize in CI before shipping. Add a smoke test that boots the app with cached views.
• If you maintain custom views, keep them in your app’s resources/views and reference the package namespace only as a fallback. This reduces breakage when the package changes its internal view paths.

Gotchas and Tips

• The v0.1.1-beta.1 fix addresses an empty filament-meta views namespace being registered even though the directory was absent from the release archive. If you are on 0.1.0, php artisan optimize/view:cache can fail with “directory does not exist” at Finder.php:663. Upgrade before deploying.
• This is still a beta release. Pin the exact version in composer.json and review changelogs before bumping, especially around view namespace and config registration.
• If you still see view-cache errors after upgrading, check for stale package discovery or cached config: run php artisan package:discover, php artisan config:clear, and php artisan view:clear.
• Do not manually create the package’s internal filament-meta views directory in vendor/; it will be lost on Composer updates. Override views in your app instead.
• Watch for namespace collisions if you already use a filament-meta view namespace or have a similarly named plugin. The service provider registration is the first place to inspect.
• For debugging rendered tags, dump the resolved meta data before the Blade component renders, then compare with the final HTML. This separates data-resolution issues from view/markup issues.
• Extension point: prefer published config and app-level view overrides. Avoid subclassing package internals unless the README documents it, since beta internals may change.
• Add a regression check to CI that runs php artisan view:cache on a fresh install without published package views. That is the exact failure mode this release fixes.