Posts per page overrides taxonomy templates

Templates, plugins, and probably FSE (not sure about this last one) will override the per page setting through the “pre_get_posts” action hook. If so, you could override the override with your own action callback. The trick is doing so after all other code is finished overriding. If all are using the same hook, ensure yours is last by adding your callback with a very large priority number. The largest possible would be PHP_INT_MAX.

If that doesn’t work for some reason, the actual SQL query is filtered through “posts_request”. You could alter the LIMIT clause value as you wish.

Hi @bcworkz,

Thanks for coming up with that. A bit beyond my coding pay grade, but I can probably fumble through.

That said, what do think of the idea that this is really a bug that should be reported.

My thinking is that the templates should have primacy over the setting in appearances/edit/blog?until a user overwrites a given template in FSE. That’s the case for most other variable and the case with Theme.JSON.

Otherwise why even bother to have the perPage parameter in the query block HTML in a template.

And there’s another aspect to this: Even if I change the perPage parameter in the code editor, it does not work.

Put it all together and it seems to me that this is something that should be fixed in core?

Anyone else have thought on that?

I don’t think it’s a core issue. Expected behavior (and what I observe on my site) is the base setting is essentially a “default” preference when there is no overriding preference. The query loop block’s setting should of course override this and it does when observing my site’s behavior.

The reason you would see a departure from expected is if a theme or plugin is also overriding the “default” but not adequately verifying what it is overriding; we’ll see aberrant, unexpected behavior.

IOW, I think if there’s any bug, it lies within a theme or plugin you are using, not within WP core. Through a process of elimination you could identify which module is the cause. Then report the issue to the appropriate developer through the guilty module’s dedicated support or bug report channel.

I know such reports don’t always result in a patch being as quickly released as you’d like, so I was suggesting a local workaround that could be done in the interim.

Hi @bcworkz,

Thanks for coming up, but I tested and verified the problem with all plugins turned off and on the 2024 default theme. It’s not a theme or plugin issue.

What happening here is that the setting in appearances/edit/blog is overriding all templates and even overrides a manual change in code view when editing a taxonomy in FSE.

I can’t see that as correct since many users will want a different number of posts displayed depending on taxonomy.

Sure we can override this using code as you suggest (thank you) but the whole idea of FSE is to make things easy for #nocode users, so I don’t think that’s the best answer.

You are of course free to report anything you perceive as a deficiency. FSE bugs can be reported by raising an issue at the Gutenberg Github site.

My intent was to try to verify that the issue is indeed a core issue in hopes that you would not just get a “cannot replicate” response when you raise an issue. As it is, I’m not sure where you’re seeing a setting at appearances/edit/blog (same theme, no plugins, just as you’ve done). My uncertainty is irrelevant as long as you provide a step by step description on how to reproduce the issue when you raise it over at GitHub.