I vaguely recall an IRC discussion about cached_content in which the prevailing thought seemed to be closer to #1, handled in core. I'm not sure that we got into the technical details of making sure the cached content then isn't filtered, too, so that's still an issue.
You also have to worry about watching for updated content and "expiring" the cached content (and likely not writing out a new post revision every time), so there's a lot of extra duplicate logic that would have to be included in a plugin if core didn't somehow handle it. On Thu, Apr 11, 2013 at 12:32 PM, Matt Read <[email protected]> wrote: > I've been trying to think of a way to use the cached_content field. My > thinking is that I can stored the rendered output of the post content > ($post->content_out) in here to avoid triggering all the formatting plugins > over and over again, ie. markdown, acronyms, etc.. > > The problem I'm having is in the implementation. > > 1. I could implement filter_post_content_out_0 (0 priority to run first), > check if there is cached content and return that. The problem is, after > returning the cached content, all the the other filters still run, > defeating the purpose. > > 2. I could implement filter_post_cached_content_**out, and if there is > cached_content return it, otherwise return just content_out. The problem > here is that all themes need to call $post->cached_content_out, not > $post->content_out. > > There is also an issue with "shorttags". I would prefer to still run the > shorttag stuff, as the content may be dynamic, and caching it's output not > ideal. > > One idea I had was to modify Post::__get() so that when you called the > content_out, it would first see if there was cached_content_out > ($cached_content = Plugins::filter('posts_**content_out', null);) and > return that result without running filters (other than shorttag). If there > is no result proceed normally with filters. This way, if the plugin doing > the caching is deactivated, cached_content_out will return null (even if > cached_content field contains data) and go on normally with running filters. > > Second Idea was to allow plugins to stop a filter from running any more. > Something like Plugins::deregister('filter', 'post_content_out', > $priority);. But this has far greater implications. > > Any thoughts? > > Discuss... > > -- > -- > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to habari-dev-unsubscribe@** > googlegroups.com <[email protected]> > For more options, visit this group at http://groups.google.com/** > group/habari-dev <http://groups.google.com/group/habari-dev> > --- You received this message because you are subscribed to the Google > Groups "habari-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to > habari-dev+unsubscribe@**googlegroups.com<habari-dev%[email protected]> > . > For more options, visit > https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out> > . > > > -- -- To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/habari-dev --- You received this message because you are subscribed to the Google Groups "habari-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
