Getting Started

Before you install anything, resolve the identity of this package. The metadata you have is internally contradictory:

The tagline and repo say "The hottest news right in your Statamic dashboard" — a Statamic Control Panel dashboard widget. That is an addon, not a plain Laravel library, and it is useless outside a Statamic site.
The description.md claims generic Laravel conveniences: "Extra Eloquent helpers", "global helper functions", "publishable configuration", "framework-agnostic".

Both cannot be true. The tagline is almost certainly the real one (the name is a "extra, extra, read all about it" news pun), and the description.md reads like generic filler written without looking at the source. Your first step is a five-minute inspection, not a composer require:

composer show -a sortarad/extraextra     # versions, requires, license, abandoned flag

Then open the repo and read, in this order:

composer.json — the require block is the whole compatibility story (laravel/framework, statamic/cms, php). Also check extra.laravel.providers and extra.statamic to confirm how it registers.
The install doc that release 1.0.1 split out — that is the maintainer's own first-run path.
src/ — look for a widget class, a service provider, a config file, and any Guzzle/Http client. The HTTP client tells you whether this makes outbound calls on every CP page load.

Minimal install (only if step 1 confirms it targets your stack):

composer require sortarad/extraextra:1.0.1
php artisan vendor:publish --provider="Sortarad\ExtraExtra\ServiceProvider"

Pin the exact patch (1.0.1, not ^1.0) and commit composer.lock. There have been no releases since 2020-12-01, so "latest" is not going to move on you — but pin anyway so a fork or a re-tag can't surprise you.

First use case is the only one this package plausibly supports: drop the news widget onto the Statamic dashboard so editors see project news when they log in. In Statamic 3+ that means adding an entry to the widgets array in config/statamic/cp.php; in Statamic 2 it means the dashboard YAML under site/settings/. Confirm the widget handle from the package's own docs rather than guessing — 2020-era Statamic addons frequently ship a README example that is the only accurate reference for the handle name.

If the compatibility check fails, stop. A zero-star addon last released in December 2020 is not worth patching to fit. See the Gotchas section — the replacement is a ~20-line custom widget.

Implementation Patterns

Treat the widget as a display layer, not an integration point

The healthy pattern for any dashboard addon is: the package renders, your code owns the data and the failure mode. Do not let domain logic depend on the widget class.

// app/Support/NewsFeed.php
namespace App\Support;

use Illuminate\Support\Facades\Cache;
use Illuminate\Support\Facades\Http;

class NewsFeed
{
    public function headlines(): array
    {
        return Cache::remember('dashboard.news', now()->addHours(6), function () {
            return Http::timeout(3)
                ->retry(1, 200)
                ->get(config('services.news.url'))
                ->throw()
                ->json('items', []);
        });
    }
}

Then either configure the package to read from your cache, or — more likely, given its age — bypass it and register a small custom widget against NewsFeed. That adapter seam is the entire exit strategy: when the addon stops working on your next Laravel upgrade, you delete a line from cp.php and nothing else changes.

Pre-warm the feed instead of fetching on page load

A dashboard widget that performs a synchronous outbound HTTP request fires on every Control Panel visit by every editor. That is the single biggest day-to-day cost of this class of package. Two mitigations:

// app/Console/Kernel.php
$schedule->call(fn () => app(NewsFeed::class)->headlines())
    ->hourly()
    ->withoutOverlapping();

…and set a short timeout so a dead upstream can't hang the CP:

// config/services.php
'news' => [
    'url' => env('NEWS_FEED_URL'),
],

If the package has no cache/TTL setting in its published config (likely, at this age), the scheduled pre-warm plus a short HTTP timeout is your only lever — which is another argument for the adapter.

Scope it to admins, not everyone

Editors logging in to write content do not need a news panel, and an outbound request per login adds nothing but latency and a third-party dependency in your request path. In Statamic 3+, gate the widget by role/permission configuration in config/statamic/cp.php; if the package's widget doesn't support that, register it only conditionally:

// config/statamic/cp.php
'widgets' => array_filter([
    ['type' => 'news', 'width' => 50],        // only if the handle is confirmed
], fn () => auth()->user()?->isSuper());

Disable it outside production

Non-production and CI environments should never call a third-party endpoint. Guard on config:

// .env.local / .env.testing
EXTRAEXTRA_ENABLED=false

If the package has no enabled flag, do the guarding in AppServiceProvider::register() by conditionally merging the widget into the CP config, or simply omit the widget entry in non-production config.

Test around it, never through it

Because the value of this package is one widget, your test surface should be NewsFeed, not the addon. Fake the HTTP layer and assert the widget renders given a payload; skip asserting anything about the package's internals — you don't own them, and at this age they may not survive a PHP minor bump.

Gotchas and Tips

The metadata conflict is the headline risk. If you cannot determine from the source whether this is a Statamic addon or a Laravel helper library, you cannot assess it. Do not adopt on a README promise — an install guide (the entire content of 1.0.1) is not an API reference. The 1.0.1 release being documentation-only is mild positive hygiene, but it's also the last thing that ever happened on this repo.

Compatibility is almost certainly broken on modern stacks. Released 2020-12-01, which predates PHP 8.1 by a year and Laravel 9 by fourteen months. Expect composer require to fail with Your requirements could not be resolved due to a hard laravel/framework: ^6.0|^7.0|^8.0 or statamic/cms: ^3.0-era constraint. Do not work around this with --ignore-platform-reqs or a replace hack: you'll be running untested code in the Control Panel, and old packages commonly trip on PHP 8.1's implicit-nullable deprecation, ReturnTypeWillChange, or Carbon 2→3 API changes.

Auto-discovery fails silently — and Statamic has its own second gate. Laravel's extra.laravel.providers gets the service provider loaded, but Statamic addons must also be present in the addon manifest (config/statamic/... depending on version) or the widget simply won't appear in the CP's widget picker. Nothing errors; the option is just absent. Check the manifest before you start debugging your install.

Zero stars, single maintainer, no releases in four years. Treat it as effectively unmaintained. Check Packagist for an abandoned flag, check the issue tracker for unanswered PHP 8/Laravel 9 reports, and check the license is one your legal review accepts. Set a calendar review date (e.g. next Laravel major) rather than assuming it will keep working.

An outbound call from the CP is a security and privacy decision, not just a performance one. Every dashboard load tells a third-party host that an editor just logged in, from your server's IP. If that host is unmaintained, its domain could lapse and be re-registered. Pin the endpoint, or point it at a URL you control, or replace the widget.

Debugging order when it doesn't show up:

composer show sortarad/extraextra — did it actually install, or get silently skipped?
php artisan about / Statamic version — does the matrix even overlap?
Is the addon in the manifest and enabled?
Is the widget in config/statamic/cp.php and does the handle match the docs exactly?
storage/logs/laravel.log — Guzzle timeouts and SSL failures surface as swallowed widget-level errors, so the CP looks fine while the log is full of cURL error 28.

Extension points to prefer, in order: (1) view overrides via resources/views/vendor/... if the package ships publishable views — cheapest cosmetic fix; (2) a custom Statamic widget pointed at your own NewsFeed class — cheapest structural fix; (3) forking. Never patch vendor/.

The honest bottom line for day-to-day leverage: this package saves you writing one small dashboard widget, and in exchange you inherit an unmaintained 2020 dependency on a high-visibility page that every editor loads. Unless your team is genuinely blocked on shipping a news panel, the replacement — a scheduled Http::get() into cache, plus a ~20-line Statamic widget template — is an afternoon of work you fully own, with no compatibility surprises on your next upgrade. Adopt only if the compatibility spike passes; otherwise, build the twenty lines.

Extraextra Laravel Package