Statamic Rss Feed Laravel Package

Getting Started

Feedamic is a Statamic addon (not a standalone Laravel package) that generates RSS/Atom/JSON feeds from your collections. Treat it as a thin routing + serialization layer on top of Statamic's entry query builder.

1. composer require mitydigital/statamic-feedamic
2. Publish the config: php artisan vendor:publish --tag=feedamic-config (or copy config/feedamic.php manually — check the README for the exact tag in your version).
3. Define a feed in config/feedamic.php, pointing it at a collection handle and choosing a format (rss, atom, json).
4. Visit the generated route (typically /{feed-handle} or the configured prefix) in the browser and confirm you get XML, not a 404 or the CP.
5. Clear caches: php artisan route:clear && php artisan config:clear && php artisan cache:clear.

Where to look first:

• config/feedamic.php — every feed is declared here; this file is the source of truth for routes, formats, limits and caching.
• php artisan route:list --path=feed — confirms what Feedamic actually registered. Do this before debugging anything else.
• The package README on GitHub for the current config schema; the keys have shifted between major versions.

First real use case: a blog RSS feed tied to a blog collection, linked from your layout's <head> via <link rel="alternate" type="application/rss+xml" href="{{ url('/blog/feed') }}">. Second most common: a podcast feed where you need per-entry enclosure/media fields — verify the field mapping supports your blueprint before committing to the addon.

Implementation Patterns

Config-declared feeds, not code-declared. The idiomatic pattern is one array entry per feed. Keep the handles stable — they become URLs, so renaming a handle is a breaking change for subscribers and for anything you've hardcoded in templates.

Multiple feeds per collection. Common split: a full feed, a "latest 20" feed for syndication, and a category- or taxonomy-filtered feed. Declare each as its own handle rather than adding query-string parameters; feed readers handle distinct URLs far more reliably than parameterised ones.

Caching is the main performance lever. Large collections will happily serialise thousands of entries on every hit. Enable the addon's cache setting per feed and pick a TTL that matches your publish cadence. If you publish rarely, a long TTL plus a manual purge on save (via a Statamic event listener or an entry saved hook calling Cache::forget) is usually better than a short TTL.

Multisite: one feed per site. With Statamic multisite, routes are registered per site and the feed resolves entries in the context of the active site. In 3.0.13 the routing behaviour for multisite was tweaked, so after upgrading re-verify:

• Each site's feed URL resolves to that site's content (not the default site's).
• Entry permalinks inside the feed point at the correct site's domain, not the primary domain.
• Any hardcoded feed URLs in templates use {{ url }} / {{ site:url }} rather than absolute strings.

Integration points. Link feeds from <head> in your Antlers layout, and expose them in sitemap.xml-adjacent tooling if you have it. If you're behind a CDN or reverse proxy, set the right Cache-Control at the edge rather than relying solely on the addon's internal cache.

Testing. Write a feature test that get()s each feed route and asserts a 200 plus a content-type header (application/rss+xml, application/atom+xml, application/json). This catches route-cache and multisite-domain regressions cheaply — exactly the class of bug 3.0.13 addresses.

Gotchas and Tips

Route caching will bite you. After editing config/feedamic.php or deploying to a new site, php artisan route:clear is mandatory. Stale route caches produce 404s that look like a broken config.

Multisite routing changed in 3.0.13. The release is a targeted fix to how routes behave across sites. If you run multisite, treat this as a patch to test rather than assume: check every site's feed URL, check the <link> and <guid> values inside the output, and check that a feed for a secondary site doesn't silently serve primary-site entries. If your feeds are cached, purge after deploy — cached responses generated under the old routing will persist.

Feed URLs are public API. Once a reader has subscribed, the URL is effectively frozen. Treat handle renames and route-prefix changes as breaking changes and add redirects when you must move one.

Content-type and status matter. A feed served as text/html gets rejected by some readers. If you're proxying or rewriting responses in nginx/Cloudflare, verify the header survives.

Empty feeds are ambiguous. A collection with no published entries may produce a valid-but-empty feed or a 404 depending on config. Decide which you want and test it; readers sometimes unsubscribe on repeated empty responses.

Config cache in production. php artisan config:cache will freeze your feed definitions. Any deploy that changes feed config needs a config clear + recache step in the deploy script.

Extension points. Beyond config, the practical levers are: the entry query (limit, collection, taxonomy filters), caching, and the format. Check the README for the current event/hook surface before reaching for a decorator — this addon's extension story has been config-first across versions, so fighting it with custom controllers usually costs more than it saves.

Upgrade discipline. Pin to a minor and read the changelog before bumping. The 3.0.x line is patch-level, so 3.0.13 should be safe, but any multisite-related patch deserves a smoke test of the feed URLs on every site before it goes to production.