Admin Kit Articles Laravel Package

Getting Started

The v3.3.4 release is a small, additive feature drop: the Filament navigation group for the articles resource is now configurable. There are no breaking changes, so existing installs only need composer update ibec-box/admin-kit-articles to pick it up.

1. Install and publish (skip if already installed):

   composer require ibec-box/admin-kit-articles
   php artisan vendor:publish --tag="admin-kit-articles-config"
   php artisan vendor:publish --tag="admin-kit-articles-migrations"
   php artisan migrate
   

2. Register the plugin on the Filament panel you want articles to appear in:

   public function panel(Panel $panel): Panel
   {
       return $panel
           ->plugin(AdminKitArticlesPlugin::make());
   }
   

3. Configure the navigation group (the new v3.3.4 surface). Look in config/admin-kit-articles.php for the navigation entry and set the group label there rather than editing the resource — this is the first place to check whenever the menu placement looks wrong:

   'navigation' => [
       'group' => 'Content',
       // likely also: 'sort', 'icon', 'cluster'
   ],
   

4. First use case: load /admin and confirm the Articles resource now renders under your chosen group, then create a single article end-to-end (title, body, publish) to verify the resource, policy, and any media/relations wired up by the package are all functioning.

If the group key does not exist in your published config after upgrading, re-publish the config file and diff it against your existing copy — the new key is added by the package, and a stale published config will silently keep the old hard-coded group.

Implementation Patterns

Config-driven navigation instead of resource overrides. Before v3.3.4 the group was effectively fixed, so teams commonly subclassed the resource or used navigationGroup static overrides. Now the intended pattern is to leave the package resource untouched and drive placement from config. This keeps upgrades clean and lets you change grouping per environment without touching code.

Multi-panel setups. If you run separate panels (e.g. Admin and Editor), register the plugin only on the panels that should expose articles. Because the group is config-driven, the simplest way to give panels different labels is a small service provider tweak before the panel boots:

// AppServiceProvider::register()
config(['admin-kit-articles.navigation.group' => 'Editorial']);

Guard this so it only applies to the relevant panel, otherwise both panels inherit the last value set.

Grouping alongside other admin-kit packages. Set the same group string across the sibling admin-kit packages so Articles, and whatever else you install, collapse into one sidebar section. Rely on the package's sort key for intra-group ordering rather than reordering resources yourself.

Extending the resource. For custom fields or table columns, prefer Filament's resource extension/override hooks or subclassing the package resource and swapping it in config, rather than editing vendor files. Keep customizations in app/Filament so the config remains the only integration point.

Seeding and testing. Factories and seeders shipped by the package are the fastest way to populate a dev environment; use them in test setup to assert navigation visibility (assertSee('Content')) rather than asserting exact menu ordering, which is brittle.

Gotchas and Tips

• Config cache. After changing the navigation group, run php artisan config:clear (and re-run config:cache in production). A cached config is the single most common reason the new setting appears to do nothing.
• Stale published configs. Upgrading does not overwrite config/admin-kit-articles.php. If the navigation key is missing from your copy, the new feature is inert. Diff published configs after every minor bump.
• Translations. If you pass a translation key as the group label, ensure the key exists in your lang files; Filament renders the raw key otherwise, which looks like a bug but is a missing translation.
• Upgrade safety. v3.3.4 is additive — no deprecations or removals are implied by the changelog. A standard composer update plus config diff is sufficient; no data migrations are involved.
• Debugging placement. If the resource vanishes entirely rather than moving, check panel registration and policy visibility before blaming the group setting — canViewAny failures hide the item regardless of navigation config.
• Extension point to watch. The navigation config array is the intended customization seam. Prefer adding keys there (once the package supports them) over subclassing; subclassing the resource to change a label will conflict with future package changes to the same property.
• Version pinning. Given the rapid patch cadence (v3.3.3 → v3.3.4 in days), pin to ^3.3 and review changelogs on each bump; the project is clearly still actively shaping its configuration API.