[Website Template] Revalidate the Archive Block data automatically

[concreo]

Describe the Bug

To prevent caching issues, it's crucial to note that updating or creating a new post does not automatically refresh pages displaying the Archive Block. This could lead to outdated information being presented to users.

Link to the code that reproduces this issue

https://github.com/payloadcms/payload/tree/main/templates/website

Reproduction Steps

Use the basic website template.

1. Create a post
2. Add the Archive Block to your home page
3. Build your website
4. Update the post OR create a new one
5. The Archive Block on the home page is outdated

Which area(s) are affected? (Select all that apply)

area: templates

Environment Info

# Database connection string
DATABASE_URI=mongodb://127.0.0.1/your-database-name

# Or use a PG connection string
#DATABASE_URI=postgresql://127.0.0.1:5432/your-database-name

# Used to encrypt JWT tokens
PAYLOAD_SECRET=YOUR_SECRET_HERE

# Used to configure CORS, format links and more. No trailing slash
NEXT_PUBLIC_SERVER_URL=http://localhost:3000

# Secret used to authenticate cron jobs
CRON_SECRET=YOUR_CRON_SECRET_HERE

[schlesingermatthias]

Can confirm the issue. I could modify revalidatePost to revalidate the pages that use posts as well, but that doesn't really scale if blocks are moved to different pages etc.

export const revalidatePost: CollectionAfterChangeHook<Post> = ({
  doc,
  previousDoc,
  req: { payload },
}) => {
  revalidatePath("/posts")
  revalidatePath("/author/[slug]/posts", "page")
  if (doc._status === 'published') {
    const path = `/posts/${doc.slug}`

    payload.logger.info(`Revalidating post at path: ${path}`)

    revalidatePath(path)
  }
  ...

what would be an official solution to achieve revalidation of pages that use certain collections?

[fancier21]

Same problem. Archive Block does not re-evaluate collections when deploying a project.

[concreo]

@fancier21 @schlesingermatthias
FYI, I've decided to create a new tag called latest_posts that I'm revalidating inside the revalidatePost hook and I've created a getCachedLatestPosts function to get them from the cache:

revalidateTag('latest_posts')

async function getLatestPosts() {
  const payload = await getPayload({ config: configPromise })

  const posts = await payload.find({
    collection: 'posts',
    draft: false,
    limit: 3,
    ....
  })

  return posts.docs
}

export const getCachedLatestPosts = () =>
  unstable_cache(async () => getLatestPosts(), [], {
    tags: [`latest_posts`],
  })

[ed-dev-pro]

concreo It works, but only after manually reloading the page. I wonder if it is possible to refresh the data, for example, when switching from one page to another?

[concreo]

@ed-dev-pro, This happens because client-side navigation with Next Link is reusing a cached (or prefetched) version of your page that wasn’t refreshed after the cache tag was invalidated. When you trigger revalidateTag('latest_posts'), the server cache is cleared so that on a hard refresh the server fetches fresh data. However, during client-side transitions Next.js use a version that was prefetched earlier and doesn’t automatically refetch the new data.

Refer to this doc

To address your issue, you can take a look at the next/link prefetch option or play with the experimental staleTimes feature.

Alternatively, you can fetch the latest posts only on the client, in a useEffect, for instance.

Note that your question is a Next.js concern, not a payload one.

[fancier21]

Got it, thank you!

[abulava]

In addition to this issue, I've noticed the website template is also missing revalidation for the Meta > Related Posts field. Publishing or unpublishing a related post does not invalidate the cache for the parent post that references it.

Furthermore, the problem is particularly acute for Media collection items. Since they are used in countless places (like rich text fields, hero images, and SEO meta tags), ensuring proper cache invalidation for them is especially challenging.

These specific examples highlight a broader challenge: the template requires a deep understanding of cache invalidation patterns. To improve the developer experience, especially for those new to Payload, would it be possible to:

1. Implement revalidation for these missing cases?
2. Or, perhaps more effectively, create documentation that explicitly addresses how to handle revalidation for related posts, media, and other common entities?

I believe this would significantly reduce the learning curve and prevent frustrating caching issues.

[abulava]

@concreo @fancier21 @schlesingermatthias I've been looking into the caching behavior and noticed that the /posts and /posts/page/[pageNumber] routes are revalidated every 600 seconds, but other page routes are not.

To mitigate issues like #10750, I propose a workaround by adding the export const revalidate = 600 line to the following pages:

• templates/website/src/app/(frontend)/[slug]/page.tsx
• templates/website/src/app/(frontend)/page.tsx (this is a home page)
• templates/website/src/app/(frontend)/posts/[slug]/page.tsx

While this is not a perfect long-term solution (as it applies a one-size-fits-all revalidation period instead of on-demand updates), it has the significant advantage of making the revalidation behavior consistent across all major pages of the site, which improves predictability and user experience.

If I don't hear any objections by EOW, I will proceed with creating the PR.

[JessRynkar]

Thanks for the detailed discussion and proposed approaches. The issue with pages not automatically revalidating when posts are updated is a caching / Next.js behavior challenge. Workarounds like revalidateTag or client-side fetching help, but there’s no perfect out-of-the-box solution.

Overall, this is more of an enhancement to the template than a bug, so I am going to convert it to a feature request. We would be happy to review and accept a PR to improve the template in this area

[rasitakyol]

I opened draft PR #17405 using an Archive query cache tag plus publish/unpublish/delete invalidation. The PR explicitly documents the one-line access-control overlap with #15944 and will be rebased if that lands first. Focused tests pass; the remaining template CI matrix is still running.