Laravel Dashboard Uptime Robot Tile Laravel Package

Getting Started

Release 3.0.0 is a major bump, so treat the upgrade as a migration rather than a patch. Even though the only headline entry is "Added alternative view," a major version number implies breaking changes that may simply be undocumented in the release notes — check CHANGELOG.md, UPGRADE.md, and the diff against the composer.json constraints (PHP and illuminate/* versions) before bumping.

Minimal path in:

1. composer require <vendor>/<package>:"^3.0" in a branch, not on main.
2. php artisan vendor:publish --provider="<Vendor>\<Package>\<Package>ServiceProvider" (or the package's tagged publishes — usually --tag=config and --tag=views).
3. Open the published config/<package>.php first. The new "alternative view" almost certainly surfaces as a config key selecting which view the package renders (something like 'view' => '<package>::default'). That key is the entire feature surface of this release, so it is the first thing to read.
4. Confirm the service provider registers a view namespace (loadViewsFrom, loadViewsFrom + publishes). That tells you the resolution order and where the alternative view lives (resources/views/vendor/<package>/).

First use case: render the package's output once with the default view, then flip the config to the alternative view and diff the two visually. If they are both acceptable, you now have a documented A/B or per-tenant presentation switch for free. If only one works, you have found the first gotcha (usually a view-cache or config-cache issue — see below).

Implementation Patterns

Config-driven view selection. Let the package pick the view via config, and treat that config value as app state, not code. Keep the default in config/<package>.php and override per environment in .env or in a service provider for narrower scopes. Do not hardcode the view name in your own Blade files — reference the package's renderer instead, so future view changes stay a config edit.

Override, don't fork. Publish the vendor view and edit resources/views/vendor/<package>/... for branding and markup. Published vendor views take precedence over the package's own, which means the new alternative view is available only if you either publish it explicitly or stop shadowing the package path. Publish the specific files you actually change rather than the whole tag.

Guard the lookup. When the view name is configurable, wrap it:

abort_unless(view()->exists(config('<package>.view')), 500, 'Missing package view');

A typo'd config value otherwise produces a View [..] not found deep in a rendered page, which is a miserable bug to trace.

Scope it per request. If you want different audiences to see different views, resolve the config key in middleware or a dedicated resolver rather than in a controller — the package may render from queued jobs or notifications where the controller never runs.

Test the contract, not the markup. assertViewIs('<package>::alternative') and assertViewHas('items', ...) in a feature test that hits the real route. That test is your canary when 3.1.0 renames the view.

CI/deploy step. Add php artisan view:cache and php artisan config:cache to your deploy script, and view:clear/config:clear to your rollback script. The alternative view only exists in the container after a fresh publish.

Gotchas and Tips

• Stale published config is the #1 failure mode. vendor:publish does not overwrite existing files. A config file published under 2.x will not contain the new view key, so the alternative view will silently never apply and you will conclude the feature is broken. Republish with --force deliberately, or mergeConfigFrom correctly in the provider.
• View precedence shadows the new view. Published resources/views/vendor/<package>/* wins over the package namespace. Delete stale published copies before deciding the alternative view is missing.
• Clear caches in the right order. config:clear then view:clear, then re-warm. Compiled Blade files from v2 can survive composer update and produce confusing half-old output.
• Octane and long-running workers. Runtime config() mutations persist across requests in Octane and across jobs in queue workers. If you switch views dynamically, scope the change to the request/job or restore it afterwards.
• Don't assume the release is additive. Major version, one-line note. Read the actual diff for signature changes to any class you touch directly, and check whether the default view was renamed or its data contract changed. Bump in a branch, run the suite, then merge.
• Debugging checklist: view()->exists(), php artisan about for the resolved view paths, php artisan tinker to dump config('<package>.view'), and check view.compiled is writable.
• Extension points: the config view key, published views, and (if exposed) a container binding for the renderer. Prefer the config key and published views; binding over internal classes couples you to a package that is evidently willing to break things on majors.
• Discoverability: the alternative view is opt-in and undocumented in the app. Note the config key in your .env.example and a line in the project README, or the next developer will never know it exists.