Ah, this is probably why we didn’t use pagination in the first place; it’s going to try and create a second file, also called feed.xml.

Why did we move to using pagination again? Anyway, I think the feed.njk layout will need to be reverted, to something more along the lines of

- {%- for item in pagination.items %}
+ {%- for item in collections.post | limit: size | reverse %}

And the documentation updated to use the following front matter:

---
eleventyExcludeFromCollections: true
layout: feed
permalink: /feed.xml
size: 20
---

I note that we’re using collections.post in that template anyway, so the collection to pull items from was never truly configurable. We can keep it so that you can use a different collection, with something like this:

-   <updated>{{ collections.post | getNewestCollectionItemDate | dateToRfc3339 }}</updated>
+   <updated>{{ collections[collection] | getNewestCollectionItemDate | dateToRfc3339 }}</updated>

- {%- for item in pagination.items %}
+ {%- for item in collections[collection] | limit: size | reverse %}

And use the following front matter:

---
eleventyExcludeFromCollections: true
layout: feed
permalink: /feed.xml
collection: posts
size: 20
---

Want to try that?

Ah, this is probably why we didn’t use pagination in the first place; it’s going to try and create a second file, also called feed.xml. Why did we move to using pagination again?

Yeah, I can’t remember. Maybe it was just to specify the collection (so you could have multiple feeds) or size. But, err, clearly didn’t think ahead to what happens when you overflow the size.

I guess it could be fixed by using a permalink like this:

permalink: "feed{{ "" if pagination.pageNumber == 0 else pagination.pageNumber }}.xml"

...but it's not really necessary to paginate your rss feeds.

Your suggestion sounds better. Have tried it in #333 - although limit: size doesn’t work so used slice instead. Also couldn't remember if collections are reliably already in date order, or if they need to be sorted using the date?