This is an interesting topic. I'd love for the functionality to be
mostly transparent to themes, such that you'd never directly access
$post->cached_content, simply continue to use $post->content or
$post->content_out like always.
I don't think that the cached_content field should work like a
traditional time-expiry cache. The typical use case is much less
complex than what would be required to support time-based cache expiry.
Plugins that wanted to attempt this could still do so, but I'm not
personally sure of the value.
I suggest adding a "post_prerender_content" filter that is executed when
the cached_content value needs to be generated. This would usually be
used in two places: One when the content is changed (so that the new
value can be rendered and stored), and one when the cached_content field
is empty (which would happen for existing content that had not been
pre-rendered). Obviously, this would require a change in the plugins
that offer filters that would be useful to pre-render.
If you want to invalidate the cache, you just delete the value in the
cache field.
This idea could potentially be expensive if no content values are cached
and all of the values need to be both pre-rendered AND stored. I've
been considering a separate system that would queue object writes until
after the buffer is flushed. This is already needed for object writes
from FormUI forms, since each field is saved discretely. (For example,
saving a Post would generate one UPDATE query for each field changed
unless all of these individual writes were queued until the end of
execution.)
As to invalidating cache when plugins are added, this is done simply
with "UPDATE posts SET cached_content = ''" whenever an event occurs
that triggers a cache reset. I think, though, that executing this query
(via some API method) should either be the prerogative of a plugin that
implements the prerender filter, or (if we want to get super-fancy)
Habari should detect when a plugin that uses the prerender filter is
enabled/disabled and execute a cache reset at that time.
I've made some of the changes described above, and pushed them to a new
branch for review:
https://github.com/habari/system/commit/e460d551657ff1c6bc60ae895faa292101ecf01b
Please note that in this code the "internal" filter is something already
used by the publishing form to obtain the raw, unfiltered value out of a
Post field when using __get().
Owen
--
--
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.
