On 11/04/2013 3:18 PM, Owen Winkler wrote:
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.
I like the idea of this filter. In fact is solves my shorttags problem
as well. The markdown plugins et. al would just need to change to this
filter, while still allowing for dynamic content to render (like
shorttags or others).
This would also be useful for comment_content if it has a cached_content
field. Case in point, the at-comment-names plugin; with many comments it
EATS ALL THE MEMORIES! too much looping :(
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.)
The queue would work best, if possible.
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.
This could also lead to many plugins all "invalidating cache" at the
same time. Unless it was a trigger/filter to set a value to run it
later, like in your queue.
--
--
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.
