Bug description
Bug description
With STATAMIC_BACKGROUND_RECACHE=true, any page rendered by a background recache request emits pagination links that carry the __recache token:
<li><a href="https://example.com/resources/news?__recache=f452fe13…&page=2">2</a></li>
That HTML is then written to the static cache, so the token is served to every subsequent anonymous visitor until something regenerates the page without it.
Cause. Statamic\Extensions\Pagination\LengthAwarePaginator::withQueryString() overrides Laravel's implementation and appends the raw query string:
// src/Extensions/Pagination/LengthAwarePaginator.php
public function withQueryString()
{
$this->appends(request()->query());
return $this;
}
Laravel's version routes through Paginator::$queryStringResolver, which is the documented seam for filtering query params. Because the override bypasses it, the usual workaround (Paginator::queryStringResolver(...)) silently has no effect — the closure is never called.
How to reproduce
- Statamic 6 site with static caching enabled (half or full) and
STATAMIC_BACKGROUND_RECACHE=true.
- A template with a paginated listing:
{{ collection:blog paginate="12" as="posts" }}
{{ posts }}{{ title }}{{ /posts }}
{{ paginate }}{{ auto_links }}{{ /paginate }}
{{ /collection:blog }}
- Cause that page to be recached in the background — save an entry, or run
php please static:warm.
- Request the page as an anonymous visitor and view source. The pagination
hrefs contain ?__recache=<token>&page=N.
Note this is intermittent by nature: an ordinary (untokened) request regenerates the page with clean links, so the token is only present while the cached copy is the one produced by a recache request. On a site with frequent content edits it reappears regularly.
Logs
Environment
- Statamic 6.29.0 PRO
- Laravel 13.29.0
- PHP 8.4.19
- Static caching: half measure
- `STATAMIC_BACKGROUND_RECACHE=true`
Installation
Other (please explain)
Additional details
Existing site, upgraded from Statamic 5. Only started once background recache was then enabled.
Bug description
Bug description
With
STATAMIC_BACKGROUND_RECACHE=true, any page rendered by a background recache request emits pagination links that carry the__recachetoken:That HTML is then written to the static cache, so the token is served to every subsequent anonymous visitor until something regenerates the page without it.
Cause.
Statamic\Extensions\Pagination\LengthAwarePaginator::withQueryString()overrides Laravel's implementation and appends the raw query string:Laravel's version routes through
Paginator::$queryStringResolver, which is the documented seam for filtering query params. Because the override bypasses it, the usual workaround (Paginator::queryStringResolver(...)) silently has no effect — the closure is never called.How to reproduce
STATAMIC_BACKGROUND_RECACHE=true.{{ collection:blog paginate="12" as="posts" }} {{ posts }}{{ title }}{{ /posts }} {{ paginate }}{{ auto_links }}{{ /paginate }} {{ /collection:blog }}php please static:warm.hrefs contain?__recache=<token>&page=N.Note this is intermittent by nature: an ordinary (untokened) request regenerates the page with clean links, so the token is only present while the cached copy is the one produced by a recache request. On a site with frequent content edits it reappears regularly.
Logs
Environment
Installation
Other (please explain)
Additional details
Existing site, upgraded from Statamic 5. Only started once background recache was then enabled.