Bios Laravel Package

Getting Started

This package is a Laravel/Nova add-on from the ArminCMS ecosystem. Note that the metadata is inconsistent: the tagline calls it "the nova tool for configurations storage" while the description frames it as biography/profile management. Treat the source as the source of truth before designing around it.

1. Confirm compatibility before installing.

   • Open composer.json in the repo and check require for laravel/framework, php, and laravel/nova constraints. A 2021 release will not support current Laravel/Nova majors without adjustment.
   • Confirm you actually run Laravel Nova — the "tool" half of the package is meaningless without it.

2. Install and publish.

   composer require armincms/bios
   php artisan vendor:publish --provider="ArminCMS\Bios\BiosServiceProvider"
   

   Publish tags are not documented, so run php artisan vendor:publish interactively and inspect what is offered (config, migrations, assets, views). Publish into version control so you can diff future changes.

3. Run migrations and register the Nova tool.

   php artisan migrate
   

   Then add the tool to app/Nova/NovaServiceProvider.php inside tools():

   public function tools()
   {
       return [
           new \ArminCMS\Bios\Bios(),
       ];
   }
   

4. Where to look first.

   • vendor/armincms/bios/src/ — the service provider, the Nova Tool class, models, and any config repository.
   • The published config/bios.php (or similarly named file) — table names, cache keys, and defaults.
   • database/migrations/ — the real schema tells you what a "bio" or "configuration" record actually is, which resolves the description ambiguity faster than any README.
   • The Tool class boot()/renderNavigation() methods to see what UI it injects.

5. First use case. The safest first integration is the read path: fetch a stored configuration/bio value through the package's model or repository and render it in a Blade view. Do this on a non-critical page before wiring it into the Nova admin UI, so you can isolate data-layer problems from Nova registration problems.

Implementation Patterns

Resolve values through the package, not raw SQL. Use the published model or config repository class rather than querying the table directly in controllers. That keeps you compatible if the package changes its storage strategy, and it centralizes caching behavior.

Wrap the read path in your own cache decorator. The 0.3.2 release fixed a wrong caching value, which tells you the package caches internally. Do not double-cache blindly. Either trust the package's cache and add explicit invalidation on your writes, or bypass it and cache at the application layer with your own keys:

$bio = Cache::remember("bios.{$key}", now()->addHour(), fn () => Bios::find($key));

Invalidate on write with model events. If you create or update records outside the Nova UI (seeders, imports, API endpoints), hook saved/deleted to flush whatever cache layer you control:

static::saved(fn ($model) => Cache::forget("bios.{$model->key}"));

Extend via published migrations. Add columns by publishing the migration and editing it, or by creating a follow-up migration. Do not edit vendor files. If the model uses $guarded = [], be deliberate about which new fields are mass-assignable from Nova.

Use Nova as the admin surface, not the data layer. Day-to-day, editors use the Nova tool; your application reads through the model. Avoid calling Nova tool internals from your application code — those APIs are the least stable part of a 2021 package.

Scope keys for multi-tenant or multi-site setups. A configuration tool almost always stores global rows; if you have more than one tenant or site, prefix keys (site:eu:footer_text) at the application layer rather than assuming the package scopes for you.

Test against the array cache driver first, then the production driver. Behavioral differences between array, file, and redis (especially tag support) are common sources of "works locally, stale in production."

Pin the version. Use "armincms/bios": "0.3.2" rather than ^0.3 — with low release cadence, an unpinned minor bump is a bigger risk than a stale patch.

Gotchas and Tips

• Pin >= 0.3.2 and flush caches on upgrade. The only documented change is a caching correctness fix. Any cache written by an older version may be wrong. Clear the relevant cache store during deploy, not after you notice inconsistent values.
• Low maintenance signal. Two stars, last release July 2021. Budget for forking or vendoring. Check open issues and whether the repo supports current Nova; if not, expect to patch composer.json constraints and possibly Nova API calls yourself.
• The description and package name disagree. "bios" reads as biography, but the tagline says configuration storage. Read the migration and model before writing any feature around it — designing for the wrong domain is the most expensive mistake here.
• No --provider flag means guessing publish tags. Run php artisan vendor:publish without arguments and read the menu. If a tag is offered, prefer --tag=bios-config over --provider, so you don't overwrite unrelated published assets.
• config:cache can mask config edits. After changing the published config, run php artisan config:clear in local development. A stale bootstrap cache looks exactly like "the package ignores my settings."
• Nova tool registration failures are opaque. If the tool does not appear, verify the class exists in the installed version, that tools() returns an instance (not a class string), and that Nova's assets were re-published (php artisan nova:publish) if the package ships its own JS.
• Cache driver divergence. If the package uses cache tags, file and database drivers will throw or silently degrade. Confirm the driver before assuming invalidation works; test hit, miss, expiry, and invalidation explicitly.
• Migration collisions. Common table names (settings, configurations) collide with other packages. Check the migration filename and table name before running migrate on an existing database.
• Extension points to prefer, in order: published config → published migrations → model subclassing → service container binding override → vendor patch. Anything past subclassing should be a fork you own.
• Debugging checklist: php artisan tinker against the model to confirm the table and columns; Cache::getStore() to confirm the driver; php artisan route:list | grep bios if it registers routes; check storage/logs/laravel.log after opening the Nova tool, since tool render exceptions are often swallowed into a generic Nova error page.
• Write your own regression test. There is almost certainly no test suite you can rely on. One feature test that stores a value, reads it back, clears the cache, and re-reads it will catch the failure mode the 0.3.2 fix addressed and protect you through future upgrades.