#12491 closed enhancement (wontfix)
add a pre_template_include filter, so as to allow caching of the template file
| Reported by: | Denis-de-Bernardy | Owned by: | |
|---|---|---|---|
| Priority: | normal | Milestone: | |
| Component: | Themes | Version: | 3.0 |
| Severity: | normal | Keywords: | |
| Cc: | Focuses: | performance, template |
Description
rather than running file exists all over the place in the template loader, we should offer the possibility for a plugin to cache the information for use in subsequent pages.
Attachments (1)
Change History (13)
#2
@
16 years ago
re 404, the point would be to write a plugin that looks up the available template files, caches that accordingly, and knows, based on what the WP Query tells it, what file to use without needing to do a file_exists() call.
template_redirect works fine too for this, up to a point:
- it would mean the plugin needs to handle robots, feeds, etc. it would also mean the plugin would need to manage whatever we add in there in the future.
- it would re-introduce the inflexibility that led us to introduce the 2nd hook in the first place, i.e. the plugin itself would not be plugin-able.
#3
@
16 years ago
Additionally, and that is not that visible in the trac patch browser, pre_template_include is building a good pair to template_include, a principle that you can find more and more often within the codebase.
#4
@
16 years ago
Apparently I had misread the diff, and thought 404 was processed before the filter. Obviously, filter comes first in the diff.
![(please configure the [header_logo] section in trac.ini)](/chrome/site/your_project_logo.png)
Patch looks fine, though I'm wondering why you didn't place it above 404 as well, just cause.
More so, couldn't you write to cache on the template_include hook and pull from cache on template_redirect?
Seems like a worksforme, considering that the two hooks now seem more than flexible enough for what you're going for.