- What does the nova-worldclock-card package do?
- It is a Laravel Nova dashboard card that renders world clocks for several time zones at once, so you can watch local times across offices and distributed teams without leaving the Nova admin panel. The card is purely presentational: it touches no application domain code, database, queue, or auth path. Adoption is a UI-surface decision rather than an architecture decision.
- How do I install nova-worldclock-card with Composer?
- Run composer require interaction-design-foundation/nova-worldclock-card, then register the card in your NovaServiceProvider so Nova knows to render it on a dashboard. In most setups you will also publish the package config file to define which cities or time zones appear. The install itself takes minutes; the real gating factors are your PHP, Laravel, and Nova versions.
- How do I register the card in NovaServiceProvider?
- Add the card class to the cards() array of your dashboard definition, typically inside the dashboards() method of app/Providers/NovaServiceProvider.php, then confirm the card appears on the dashboard you targeted. If the card renders blank or unstyled after registration, check that Nova's compiled assets were rebuilt and that the package assets are loading correctly.
- How do I configure which cities and time zones are shown?
- Publish the package configuration and enumerate the cities and their time zones there. Assign a named owner for that list once the card is deployed, because curating time zones is an ongoing content responsibility rather than a one-off setup task. Decide up front whether the card should follow DST for each region automatically via the time zone identifier.
- Which Laravel and Nova versions does this card support?
- Check the Nova major constraints actually declared in the package's composer.json rather than relying on changelog language; the 3.4.0 notes mention Laravel 13 support groundwork, which is forward-looking and not a support statement. Your installed Laravel major must be one your Nova release supports, and your Nova release must be one this card supports. Verify against your composer.lock before committing.
- What PHP version is required by nova-worldclock-card?
- Version 3.4.0 raised the runtime floor to PHP 8.4, up from 8.3, which is a breaking change for anyone still on 8.3. On PHP 8.3 dependency resolution fails outright, so a loud, correctly attributed error is the expected outcome. Confirm fleet PHP 8.4 readiness and ownership before adoption, since the delivery path then runs through a platform upgrade rather than the package itself.
- Does the card ship pre-built assets or do I need to compile them?
- This matters more than it looks. If the published artifact ships pre-compiled assets, the webpack and laravel-mix churn is not your problem; if consumers compile from source, you inherit a dependency on a build toolchain in maintenance mode. Confirm which applies before rollout, because it determines whether the pinned webpack version is your concern at all.
- Does nova-worldclock-card make outbound network calls or store data?
- No. The card renders inside the Nova admin surface and makes no outbound network calls, registers no services, and stores nothing in your database. That keeps the blast radius small and means there is no credentials or data-retention surface to review. The only meaningful dependency is your Nova and PHP platform version.
- Is nova-worldclock-card safe for production use?
- Blast radius is low because the card is peripheral UI chrome with no domain logic or network access. The notable risks are a PHP 8.4 minimum, a slowly decaying asset pipeline that can break when webpack or laravel-mix drift, and silent visual regressions after Nova upgrades that produce a blank or unstyled card with no error. Only manual QA catches that last failure mode, since the package has no test coverage for it.
- How do I test or remove the card if I no longer want it?
- Testing is mostly manual: load each dashboard in a browser after any Nova upgrade and confirm the clocks render with correct local times. If the card is not rendered on any dashboard today, removing it is cheaper and lower risk than upgrading it, so check usage first. Removal is simply unregistering the card and dropping the Composer dependency.