Re: [Phpwiki-talk] can't unlock pages in CVS build and much more

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

Stefan schrieb:
> in the cvs version it is not possible to unlock pages.

I already said that current pagadata cache is unstable and needs some 
more days to stabilize. This was also reported three days ago by Charles 
Corrigan.

> I've also tried to use the acl to set page permissions. does anyone know 
> how to handle this tool? i can change what i want but nothing really 
> happens. the right managment is much to difficult and buggy to use it.

I see no other bugs than the current pagadata cache problem. I'd be 
happy to receive bugreports.

> sorry that i tell you this, but in my opinion there are to much plugins 
> and features in this wiki but the base and the usefull plugins are to 
> buggy to use them at all. you should first fix bugs in the base system 
> before makeing anything else. i read about new features and themes but 
> the really usefull things are not present or do nut function correct.

The current bug list is pretty empty.
I only have some outstanding php5 and apache2/IIS issues.
See my TODO list which I mailed 2004-12-04.
Subject: "browse page and plugin/WikiAdminSelect.php show different ..."

> -Rightmanagement

There are only outstanding issues with http auth.

> -Changing a lot of pages with sql and update cached versions

This has to be done. Some changes are still pending.
The original architecture was okay for big servers and small wikis:
< 500 pages.
I have to fine-tune the caching system now,
   too much wasted memory <=> too much unneeded db queries.

You reported 2 Gig RAM for a big request. This must be fixed.

> -Backlinks did'nt work when link is part of a plugin

This is an architectural problem. Links created by plugins must be known 
at save-time and are only saved at save-time.
We don't want such dynamic WikiDB hooks yet. It will cost more time and 
more memory with little benefits.

Most plugins are simple and just store normal pages, which are of course 
correctly backlinked.
The only exceptions are Calendar and CalendarList, and I fixed a part of 
the problem yesterday.

> -Seperate database for auth and data (only partially there)

This is fully implemented.

> -HTML Dump stops when plugin needs to much time

Thanks for the report. We will extend the timeout to 20 secs per page. 
and not 240 secs per request.

> -Users homedir is always his userid why there is no subpage like 
> /users/userid to move them from root

Sorry, we will not be able to fulfill this feature request until the 
next major release. You can hack it by yourself. It will be very easy.

> -and a lot more ....
> 
> don't missunderstand me please, i like this wiki, but i use it in a 
> production environment with more than 400 registred Users and there it 
> should be rock solid. I have to decide where to go in the future use a 
> slow good featured system like wikipedia does or the faster one  like 
> phpwiki .
> i really did'nt like to change !!!
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/