Closed apermo closed 1 year ago
Since the hook is designed to allow redirects, hooking into it, with prio 0 does not sound like a good idea to me.
I think there should be no problems. AFAIK when you trigger redirect after output buffering has started, buffer contents are silently discarded.
One reason why Cachify has to hook very early is that its handler for output buffer has to be executed as the last handler. There may be multiple output buffer handlers registered (*), performing various transformation of content and Cachify must be capable of grabbing output of all such transformations, otherwise cached and uncached contents differ.
(*) One example of a plugin that uses output buffering to perform transformation of content is Autoptimize - by default it hooks to template_redirect
action with priority 2.
Btw. starting from WordPress 6.1 on, a better place to make redirects is send_headers
action. The send_headers
method and related hook is executed after query is parsed, so all contextual information necessary for most redirects should be available at the time the hook runs: https://make.wordpress.org/core/2022/10/10/moving-the-send_headers-action-to-later-in-the-load/
Understood, and thanks for the notification about the new action. But I'm no longer responsible for that plugin, and actually the template_redirect hook is the exact use case for what I did.
The plugin uses the filter 'template_redirect' to initiate the caching with priority 0.
https://github.com/pluginkollektiv/cachify/blob/09bdf189e7c85701fa7f4b817bdbb8043f8c1ba2/inc/class-cachify.php#L163
Since the hook is designed to allow redirects, hooking into it, with prio 0 does not sound like a good idea to me.
I wrote a plugin, using this filter, that will try to fix broken URLs for pages that would otherwise deliver a 404 page.
I would suggest to raise the priority to 99, to allow any other plugin to perform redirects, before the caching is initiated.