CE Cache Template Layouts Compatibility
Developer Preview
The native EE layouts have a requirement that the template declaration has to be on the very first line, and that no other exp tags can come before them. From what I can tell by looking through the Template class, the reason for this is because it makes it easy for people to know which layout they’re extending.
The issue I’m up against is that CE Cache can not play well with template layouts, because it cannot wrap the entire page (including the layout) in cache tags.
After further troubleshooting, it look as though using CE Cache around the entire template for a layout page wouldn’t work (even if exp tags could show up before a {layout=…} tag), because the {layout=…} and {layout:set} tags have already been processed by the time the CE Cache tag runs. The template class is on it’s way to parsing content and piping it to the next template.
I think the root of the problem is that the layouts are parsed before exp tags, so there is not really a way for CE Cache to get in there before they’re processed. Most every tag in EE is processed by the parser when it is reached, which has traditionally allowed CE Cache to work. However, the layouts tag seems to be parsed beforehand. When I was testing this a few months ago, there wasn’t even a way to see which layout was being used with the template_fetch_template hook when dumping the EE super object; the layouts tag was already stripped out.
In order for the two add-ons to play well, CE Cache would need to be able to have an entry point to the content before the parser was already doing the heavy lifting. It would need to be able to intercept the template content (and/or parts of it) before it’s processed, and decide whether or not to serve up previously cached content, or to process the template content and then cache it. That’s how everything worked for a long time.
Is there any way that layouts could be processed when they are reached in the template by the template parser–as opposed to before anything else is parsed–so that the content could still be optionally wrapped in other exp tags?
Thanks Aaron for writing that up. Wrapping layout tags in other tags I think opens doors to complexity that shouldn’t be there, particularly for a feature that’s supposed to make working with templates even easier. It opens nesting rabbit holes that could be a nightmare, that’s just not needed to accomplish the task.
It sounds like the best solution for you and others that need to see the whole ball of wax before we start doing things is a pre-parse hook. Does that sound about right?
Hi Derek!
A pre-parse hook would be nice. It would only be useful in the case of CE Cache if it could be hijacked though, which might open up an entirely different can of worms as far as add-ons are concerned. Know what I mean?
If the proposed hook cannot be hijacked, then the parser would parse everything whether or not CE Cache saw the pre-parse contents, which would defeat the purpose of the add-on. It would be amazing if CE Cache could see the pre-parse content and act on it, even if that meant grabbing and returning a previously cached item and manipulating the content. However, I can see why that could get messy if a bunch of add-ons were all doing the same thing. It would be very powerful, but potentially messy. I imagine that’s why the template_fetch_template is a read-only hook.
Would you guys be willing to make the proposed pre-parse hook hijackable (eg: able to modify and return the template content before the parser runs with it)?
Yeah that’s typically why we haven’t had a hook there, because it’s too close to the gears and add-ons could very easily make EE behave in an unexpected and hard-to-nail-down-who’s-to-blame manner. I’m not set on an implementation yet, we were just batting around some rough ideas today. There is probably a fair compromise somewhere that will just need to take some further thought.
Yeah, I can see that. Perhaps logging (in the template debugger) which add-ons returned modified content to the hook could alleviate some of the potential issues. Being able to see the hook trail could make it easier to troubleshoot if something came up.