Re: [Phpwiki-talk] browse page and plugin/WikiAdminSelect.php show different owners for a page - and sometimes neither is what I expect

[Reini U. <ru...@x-...>]

Charles Corrigan schrieb:
> On Thu, December 2, 2004 10:38, Reini Urban said:
>>Charles Corrigan schrieb:
>>>Just to clarify, I had problems with page ownership since I started
>>>playing with 1.3.11pre - my previous patches were chipping away at bits
>>>of the problem. 
>>
>>oh. Sounded like the cache problem I was working at.
>>
>>>What I am testing is from CVS as on Saturday - I will upgrade
>>>to latest over the weekend.
> 
>>You have been warned. The pagedata and versiondata cache revamp is not 
>>finished, it's dirty, and I want to clean it up without using too much 
>>memory.
> 
> With a clean install, the steps to reproduce this problem are:
> 1 - change the owner of the page PageGroupTest/Four from CarstenKlapp to
> another user
> 2 - view the page - will correctly show the new owner
> 3 - view PhpWikiAdministration/Chown - it will still show Carsten as the
> owner.

Ah, a PageGroupTest subpage! I've found out those subpages have a 
pagedata cache problem as well as importing problems.
This is on my TODO list.

> I have traced this problem through the call stack to WikiDB_Page->getOwner()
> and WikiDB_Page->get() -  get() does not find a value for 'owner' in the
> metadata of the page and it falls back to 'author_id', staring from the
> first available version of the page.

thanks, looks easy to fix.

> As Reini suggested, it does appear that this is related to caching - when
> the page is actually being displayed, all of the data is correct. However,
> when the page is referred to indirectly (via lib/plugin/WikiAdminChown.php,
> lib/plugin/WikiAdminSelect.php and lib/PageList.php in this case), the
> cached data is incorrect or incomplete.
> 
> So far, I have been working around the periphery. I do not really know how
> all of this works, so it may take me a while before I find anything. Given
> that Reini are working on the caching, is it worth me investigating further?

if you want to help I'd appreciate it.

I'm just considering putting out the _cached_html field to an extra sql 
field in the sql backends. To simplifiy the cache logic and the sql 
handling and at most to improve memory usage. This field is only needed 
for the current page, rarely used, and we could fetch it extra when 
needed. So far we fetch it, process it, store it in the pagadata cache 
and undef it then when it's not the current page. (failing memory release?)
my simplification would need to undef only for the non-sql backends.

and then I might be simplifiying version_data cache by adding some short 
logic and removing space. so far we store it twice. one version with 
content and one without.

current TODO:
FixMe:
* test httpauth, and reported personalpage auth problems
* test against php-5.x
* test against apache2 and IIS problems
* finish ModeratedPage (2/3: deferred action. mimic post somehow)
* iniconfig helpers: config.ini creation and converter,
                      install => configurator (2/3)
* wait for sf.net fc1 update.

Improvements:
* collapse page change notification on LoadAny (2/3, missing: ?)
* restrict certain action to groups: RawHtml (could be a define)
* store less versiondata_cache (memory)
* refactor _cached_html for sql backends (memory and simplification)
* more antispam
* refactor WikiDB remove to enable revert

-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/