On 11/04/2013 12:39 PM, Chris Meller wrote:
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.
In my plugins scenario I would only be updating the cached_content
whenever content is modified. Storing with no expiry, as I don't see a
need to re-cache it every x hours. Idea being I want to store the
filtered content once, and not run markdown et. al every page load.
In this scenario I would need to not cache "shorttags" output; Also
cached_content revisions could be used for something. I had not thought
about revisions.
However there may be a plugin that wants to deal with expiring the
content. Said plugin could store a serialized version of the content
with meta data in this cache store, or store meta data in info fields,
or Cache::set() a token for said post, etc.. It may be more ideal to
have a specific expires field in the post's row, save unserializing or
querying info fields? Assuming this was going to be part of core, and
not handled by plugin.
--
--
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.
