Feedamic Laravel Package

Getting Started

Feedamic is a thin addon: it wires a route to an Antlers-rendered XML template, and you control almost everything through a published config file and overridable views. Expect to spend your first hour in config and templates, not in PHP.

Install and publish

composer require mitydigital/statamic-feedamic
php artisan vendor:publish --tag=feedamic-config
php artisan vendor:publish --tag=feedamic-views   # only when you need to customise XML

Check the README for the exact publish tags — the addon exposes a config tag and (usually) a views tag, and publishing views is the intended extension point rather than editing anything in vendor/.

Where to look first

1. config/feedamic.php — the collection(s) to include, limits, caching, and any per-feed definitions. This is the source of truth; read it top to bottom before writing any template.
2. routes/web.php — you register the feed route yourself. The documented pattern is a single route entry pointing at the addon's Atom/RSS view. Confirm the exact class/tag from the README rather than guessing.
3. The published views — Atom and RSS templates. Open them side by side; they show you exactly which Antlers variables (title, url, date, content, author, etc.) the addon exposes per entry.

First use case: a posts collection feed at /feed so readers and feed readers can subscribe. Add the collection to the config, register the route, hit /feed in the browser, then paste the URL into the W3C Feed Validation Service. If it validates, you're done — that's the whole happy path.

Also add discovery to your layout so browsers and readers find it:

<link rel="alternate" type="application/atom+xml" title="Feed" href="{{ route:feed }}">

Implementation Patterns

One feed per collection or taxonomy term. The common real-world shape is several feeds: a global /feed, plus /blog/feed and /news/feed, or per-term feeds like /topics/laravel/feed. Rather than duplicating config, define the feed in the route and pass parameters through, or keep separate config entries per feed. Term-scoped feeds are where the addon earns its keep — a reader subscribing to one category is a real audience.

Config-driven, template-shaped. The mental model is: config selects which entries, the Antlers view decides what the XML looks like. So when a stakeholder asks for "include the featured image" or "use the meta description as the summary", that's a view edit, not a PHP change:

<entry>
    <title>{{ title | entities }}</title>
    <link href="{{ absolute_url }}" />
    <updated>{{ date | format('Y-m-d\TH:i:sP') }}</updated>
    <summary>{{ meta_description ?? excerpt }}</summary>
    <content type="html"><![CDATA[{{ content }}]]></content>
</entry>

Content for feeds is not content for the web. Relative URLs, lazy-loaded images, and shortcodes all break in a reader. Normalise in the template: absolute URLs, inline styles stripped, and either full content or a deliberate summary — never a teaser that ends mid-sentence.

Caching. Feed generation walks entries and renders Antlers, which is not free. Enable the addon's cache in config for production, and lean on Statamic's static caching / response caching for the feed route too. But pair it with a clear invalidation story: a feed that lags behind publishes is the number one complaint you'll get.

Wire it into your publish workflow. The most effective pattern is to treat the feed as an output of your content model: entries must always have a date field, an author, and a summary field, enforced at the blueprint level. That way the feed template has no fallback logic and no empty tags.

Multi-site. If you run Statamic multisite, scope feeds per site and decide deliberately whether a feed is per-locale (/en/feed, /fr/feed) — readers usually want one language.

Test it in CI-ish fashion. A cheap regression test: curl -s https://your-site.test/feed | xmllint --noout - plus asserting a known title appears. Add it to your smoke checks so an Antlers typo doesn't silently ship an invalid feed.

Gotchas and Tips

• Validation is unforgiving. One unescaped & in a title or a missing <updated> kills the whole document. Run the W3C validator after every template change, not just at launch. Antlers' entities/sanitize filters or CDATA wrapping are your friends — but don't double-escape by CDATA-wrapping content that already contains entities.
• Dates. RSS wants RFC 822, Atom wants ISO 8601. Passing the raw Statamic date through and hoping is the classic bug. Format explicitly in the template and confirm the timezone is correct — an off-by-hours pubDate makes readers re-order or skip entries.
• Nulls cascade. Entries without the configured date or author field will render empty tags or error. Enforce required fields in the blueprint, or guard with {{ if date }}.
• Cache staleness. If a newly published post doesn't appear, check the addon cache before you debug the config. In local dev, disable it; in production, make sure your deploy or publish hook clears the relevant cache keys.
• Route collision. If you already have a /feed page or another addon (Sitemap, SEO Pro) touching feed-ish routes, php artisan route:list | grep -i feed first. Duplicate route names break route:feed in your layout.
• Relative URLs from url. Statamic's url is relative; in XML you need absolute_url (or url | absolute). This silently produces technically-valid-but-useless feeds.
• Extension points, in order of preference: config → published views → a custom route/controller wrapping the addon. Don't fork the package. At 10 stars and a small maintainer surface, you want to stay on released versions; the addon is small enough that wrapping it is cheap.
• Version pinning and risk. This is a low-traffic, single-maintainer package. Pin the major version, keep an eye on the changelog when upgrading Statamic (the release date suggests it tracks Statamic majors), and know your escape hatch: because the output is just Antlers + XML, recreating it as a plain Route::statamic() route with your own template is an afternoon's work if the addon ever stalls.
• Don't forget the boring bits: a <link rel="self"> pointing at the feed's own canonical URL, a stable <id> per entry (permalink, not the numeric ID, if permalinks are stable), and a sensible limit so the first request doesn't render 5,000 entries.