Recent News Widget Extension Laravel Package

Getting Started

Confirm the environment before touching the package: this is a PyroCMS 3 (Anomaly) addon, not a generic Laravel package. It expects anomaly/dashboard-module and the CMS addon loader to be present. On a plain Laravel app there is nothing here that will run.

Minimum steps:

composer require anomaly/recent_news_widget-extension
php artisan addon:install anomaly.recent_news_widget-extension

Note the naming split that will waste your first ten minutes: the Composer package is anomaly/recent_news_widget-extension, but the repository is anomalylabs/xml_feed_widget-extension. Treat the Composer name as authoritative and verify it exists on Packagist before planning around it; if it is not published you will need a VCS repository entry:

{
  "repositories": [
    { "type": "vcs", "url": "https://github.com/anomalylabs/xml_feed_widget-extension" }
  ]
}

Where to look first, in this order:

1. composer.json — confirm "type": "pyrocms-extension" and the require block. The Laravel/CMS version constraint tells you immediately whether it fits your install.
2. src/*ExtensionServiceProvider.php — registration, config merging, any bindings.
3. src/Widget/ — the widget class (feed URL, cache TTL, parsing logic, and the view it returns all live here).
4. resources/views/ — the Blade template you will almost certainly want to override.

First use case: log in as an admin, open Dashboard → Widgets, and add the "Recent News" widget to a dashboard. It renders a list of headlines pulled from the PyroCMS.com XML feed. That is the entire feature — it is a decoration on the admin dashboard, so judge it as a reference implementation of the widget pattern rather than as infrastructure.

Implementation Patterns

Per-dashboard, per-user placement. Dashboard widgets in PyroCMS are assigned to dashboards, and dashboards are assignable to roles. Practical pattern: create a dedicated Admin dashboard, add the news widget there, and leave operational dashboards (support, content, billing) free of it. Do not attach it to a dashboard shared with client-facing roles — a broken remote fetch there looks like your app is broken.

Wrap the remote fetch. The widget is a thin wrapper around an HTTP call to a third-party XML document. If the class does not already cache, add it in a subclass or a fork:

$items = Cache::remember('recent_news_widget.feed', now()->addHours(6), function () {
    // fetch + SimpleXML parse, return array of ['title' => ..., 'url' => ..., 'date' => ...]
});

Cache the parsed result, not the raw response, and give the cache a hard TTL. A dashboard should never block on a remote origin.

Swap the feed source rather than forking blindly. If the URL is a property or config value, point it at your own changelog, status page, or internal release feed. This is the highest-value use of the package: an org-news widget fed by an XML document you control. If the URL is hardcoded, override the class binding in your own service provider or extend the widget and register your subclass — check the service provider for whether widgets are resolved from the container or instantiated directly.

Use it as a template. The most realistic day-to-day value is copying it: cp -r vendor/anomaly/recent_news_widget-extension src/addons/..., rename the namespace, and build StatusFeedWidget, ReleaseNotesWidget, OnCallWidget against the same three-file shape (service provider → widget class → Blade view). Register each on the admin dashboard.

Vendor it if it matters. With zero dependents and zero stars, do not leave this as a floating ^1.0 requirement. Fork to your VCS, pin to a tagged commit, or path-repo it:

{ "repositories": [{ "type": "path", "url": "packages/recent-news-widget" }] }

Remove it from air-gapped installs. If the app cannot reach PyroCMS.com, drop the widget from the dashboard config entirely rather than letting it time out on every admin page load.

Gotchas and Tips

• Abandoned-by-default assumption. Zero stars, zero dependents, no activity signal. Assume no fixes upstream and budget for owning it. Verify the license file is actually present in the distributable before shipping it in a client build.
• The dashboard is on the critical path. A widget that makes a synchronous outbound HTTP request runs on every admin dashboard render. A slow or dead remote origin becomes a slow admin panel with no obvious cause, because the exception may be swallowed by the widget renderer. Always set a short timeout (2–3s) and a cache.
• Silent failure is the default. Dashboard widgets usually catch and render nothing on failure, so a broken feed looks identical to an empty feed. Add a log line in the catch block during rollout, otherwise you will debug "why is the widget missing" from zero information.
• XML parsing surface. SimpleXML with external entities is a classic footgun, and it dislikes namespaces and malformed feeds. Expect the upstream feed schema to drift without notice — parse defensively, validate that title/link exist, and never eval-style trust the response.
• Package/repo name mismatch. composer require anomalylabs/xml_feed_widget-extension will fail. Search Packagist for the anomaly/ name, or use the VCS repository block above.
• CMS version drift. PyroCMS 3 addons pin against Laravel 5.x-era constraints. On newer Laravel or a migrated PyroCMS, expect the service provider to fail to boot (addon:install errors, class-not-found on the widget interface). Check the constraint before installing, not after.
• View overrides beat edits. Override the Blade view via the standard addon view override path rather than editing vendor/ — Composer updates will silently revert your changes, and composer install on CI will not carry them.
• Debugging checklist when the widget renders blank: confirm the addon is installed (php artisan addon:list), confirm it is attached to the dashboard record, php artisan cache:clear (a cached empty result will look like a broken widget), then tail storage/logs/laravel.log and test egress with curl from the app host — not from your laptop.
• Extension points worth checking in the source: any merged config key for feed URL/TTL, container bindings in the service provider, and whether the widget class is resolved by class name in the dashboard config (in which case you can point a dashboard at your own subclass without touching the package).