FreeLists / dokuwiki / [dokuwiki] Re: Content-dependent Purge/Cache

["Todd Augsburger" <todd@xxxxxxxxxxxxxxxx>]

Chris & Ben, these are great ideas. The multi-cache would be superior to my 
method.

The only thing I cannot figure out is how to tell _which_ cache to use: I do 
not need (or want) to use additional cache files for _all_ pages--only those 
which contain comments. So within PARSER_CACHE_USE I'll still need to 
determine whether or not the wiki page has comments.

The only solutions I can think of:
1) have a duplicate cache for _all_ pages
or
2) re-read the wiki to see if it still contains comments
Or is there a better way?

Todd Augsburger
todd@xxxxxxxxxxxxxxxx
Roller Organs
http://www.rollerorgans.com/

----- Original Message ----- 
From: "Chris Smith" <chris@xxxxxxxxxxxxx>
To: <dokuwiki@xxxxxxxxxxxxx>
Sent: Wednesday, January 10, 2007 9:42 PM
Subject: [dokuwiki] Re: Content-dependent Purge/Cache


Ben Coburn wrote:
>
> On Jan 10, 2007, at 11:35 AM, Todd Augsburger wrote:
>
>> I have a dokuwiki that appears differently to "editors" (those logged
>> in)
>> than to the general public. The editors would like to include
>> comments (on
>> wiki pages) that will be invisible to the general public.
>>
>> So I wrote a plugin which handles the comments properly. However,
>> caching
>> needs to be turned off for pages which contain these comments, since
>> they're
>> user-dependent. My solution (which works) is:
>> 1) A syntax plugin renders the comment as either visible or invisible,
>> depending on the user, then uses p_set_metadata() to set a flag which
>> suggests that the page be purged.
>> 2) An action plugin hooks PARSER_CACHE_USE and uses p_get_metadata()
>> to get
>> the flag. If set, I then set depends['purge'] = true so that the page is
>> refreshed.
>>
>> [...]
>>
>> So ... I have 3 specific questions:
>> 1) Is there a better way to accomplish this? (Is there no other way
>> that the
>> plugin can request that the page not be cached?)
>> 2) Step 3 seems awkward and inefficient, because I re-read the file when
>> it's rarely changed. Is there some other way to tell if the metadata may
>> need a refresh?
>>
>
> This may be entirely too clever to work, but what about this.... Use
> syntax and action plugins that operate independently (without touching
> the metadata).
It does work.  I use essentially the same method in my (as yet
unpublished) update of the include plugin.  The plugin regenerates a
cache name which includes the users ability to view the included pages.
I have posted the code for the cache manipulation at
http://wiki.jalakai.co.uk/dokuwiki/doku.php/tutorials/include_cache -
and although determining the status of all included pages is more
complex than this requirement, the basic logic is the same.  I've
functionalised the inclusion check which determines the additional part
of the cache name so "all" you would probably need to do is replace that
part with your own function for determining visibility of the notes.

As Ben mentions your cache size will increase.  But individual xhtml
files are generally small and disk space is cheap.

Cheers,

Chris
>
> 1) Syntax plugin: Same. Displays notes for users that are allowed to
> see them.
>
> 2) Action plugin - PARSER_CACHE_USE:
> Do not use depends['purge']. Instead, partition the cache by changing
> the cache file name if the user is allowed to view notes. Some
> pseudo-code:
> $cache = $event->data;
> if (user can view notes && $cache->ext=='xhtml') {
>     $cache->cache = $cache->cache . '_notes';  //change cache file path
> }
>
> This would partition your cache of 'xhtml' data into the default
> 'xhtml' cache that does not have notes and the 'xhtml_notes' cache.
> The rest happens automatically, so you retain the speed of cached
> content. The only obvious down side is that this will double the size
> of your 'xhtml' cache.
>
> Note: You may also need to do other things to protect the notes, such
> as preventing guests from displaying the raw dokuwiki markup for
> pages. See disabled actions in the config documentation.
>
> Regards, Ben Coburn
>
>
> -------------------
>   silicodon.net
> -------------------
>

-- 
DokuWiki mailing list - more info at
http://wiki.splitbrain.org/wiki:mailinglist 

-- 
DokuWiki mailing list - more info at
http://wiki.splitbrain.org/wiki:mailinglist