Nova Greeter Laravel Package

Getting Started

Prerequisite check: this package is a Laravel Nova card. Without a licensed Nova install it does nothing — no routes, no models, no config of its own. Confirm Nova is present and note your major version (4 vs 5) before you run anything.

Install and register:

composer require oriondevelops/nova-greeter

Then in app/Providers/NovaServiceProvider.php:

use OrionDevelops\NovaGreeter\NovaGreeter;

public function cards(): array
{
    return [
        (new NovaGreeter)->width('full'),
    ];
}

Read two files before configuring anything. With 8 stars, 0 dependents, and a single 2024 release, the source is the documentation:

• vendor/oriondevelops/nova-greeter/src/NovaGreeter.php — the card class; check component() and whether it exposes any withMeta helpers.
• vendor/oriondevelops/nova-greeter/resources/js/components/Card.vue — the props declaration. This is the authoritative list of configurable keys. Anything not declared there is silently dropped when Nova hydrates the card from meta.

First use case: a full-width greeting strip at the top of the main dashboard — "Good morning, {name}" for the signed-in user — placed above your KPI cards. No migrations, no publishable config, no scheduled work. Your only decisions are placement and copy.

If it registers but renders blank: php artisan nova:publish, clear browser cache, hard-refresh. That resolves the majority of "installed but invisible" reports.

Implementation Patterns

Configure through fluent meta, but verify every key against the Vue props first. The idiomatic Nova card pattern:

(new NovaGreeter)
    ->withMeta([
        'greeting' => 'Welcome back',
        'showName' => true,
    ])
    ->width('1/3'),

Unrecognised keys disappear without warning and without an error. Cross-check each one against props: in Card.vue.

Treat it as a hero strip in the grid. Full-width above metrics, or 1/2/1/3 beside a summary card. Set the width at registration time; retrofitting layout later means touching the provider again.

Gate visibility with canSee. Greeting service accounts and shared admin logins is noise:

(new NovaGreeter)->canSee(function ($request) {
    return $request->user()->hasRole('member');
}),

Policy form works too: ->canSeeWhen('viewGreeter', NovaGreeter::class). This is also the clean seam for "greet only recently provisioned accounts" — combine with a created_at check.

Override the display name via meta, not by editing vendor code. If your user model uses display_name/first_name, or SSO accounts have a null name:

(new NovaGreeter)->withMeta([
    'name' => auth()->user()->display_name ?? auth()->user()->email,
]),

Confirm the prop name in Card.vue first. Edits inside vendor/ are overwritten by the next composer update.

Scope per dashboard. Cards are returned per-dashboard definition, so you can greet on the main dashboard and omit it from admin-only ones:

public function dashboards(): array
{
    return [
        $this->mainDashboard(),   // includes NovaGreeter
        $this->adminDashboard(),  // no greeter
    ];
}

Ordering is array position. Nova renders cards in the order returned from cards(). There is no priority attribute — if the greeter sits below your metrics, move it up in the array.

Fork rather than smuggle business logic into meta. The moment you want a CTA, an onboarding checklist, release notes, or role-specific quick links, stop depending on upstream:

php artisan nova:card acme/greeter

Copy Card.vue into the new card, register that, and own the code. A greeter is small enough to reimplement in an hour, and forking eliminates the compatibility-drift risk entirely.

Keep the greeter purely presentational. For multi-state welcome content, prefer a second card class gated by canSee() over a pile of conditionals in meta. Let Nova's card system handle routing and visibility.

Gotchas and Tips

Blank card almost always means assets, not PHP. Open devtools and look for a failed JS asset or /nova-api/... request, then run php artisan nova:publish and hard-refresh. Check composer.json's nova constraint against your installed major before you assume the code is broken:

composer show oriondevelops/nova-greeter --all | grep -i nova

Nova major upgrades are the real risk. This is a single Dec-2024 release from one maintainer. Nova 3→4→5 shifted card internals and the Vue toolchain; a card built against Nova 4 can install cleanly on Nova 5 and render nothing. Before any Nova upgrade, branch and visually confirm the card still renders. Don't trust composer update to warn you.

Timezone drift on "good morning/afternoon/evening." If the salutation is computed client-side from new Date(), users in other timezones get a greeting that disagrees with your server-side session locale. Check whether Card.vue uses Intl.DateTimeFormat with an explicit timezone or falls back to the browser default. If it's browser-default, decide whether that's acceptable — or override the greeting via meta with a server-computed string.

Null names happen. SSO and provisioned accounts sometimes lack name. Use a meta fallback (see above) rather than patching the Vue file.

Audit the source before deploying to production. Even a cosmetic card runs compiled JS inside privileged admin sessions. Grep for outbound calls and confirm there's no phantom network path:

grep -rE "fetch|axios|http" vendor/oriondevelops/nova-greeter/resources/js

Low adoption means no community has done this audit for you.

Pin the version. One maintainer, one release, no downstream users to shake out bugs. Assume no upstream fix will ever land for your environment, and budget to fork on first need.

Day-to-day reality: you install it once, register it once, and then rarely touch it. The leverage is real but small — a nicer first screen for internal users. Treat it as a scaffold and reference implementation, not a strategic dependency. Removal is symmetric: delete the entry in cards() and run composer update. Don't build anything on top of this card you couldn't delete without a migration.