buzzsaw
Hi All
I have installed DokuWiki onto an Apple Xserve running OS Tiger Server 10.4.10
For the majority this works fine with the exception that when I log in as myself as a member of the @admin group the browser slows to a crawl.
All others users have no speed issues regardless of what they are doing (reading or editing), pages and edits load into the browser in seconds but when I (or anyone else who I make a member of the @admin group) logs in, the browser takes minutes to load pages, this is not just logging but also when viewing or editing pages
Any suggestions please
andi
Interesting. I have no immediate idea what could cause this. Could you please open a bug report?
buzzsaw
Hi Andi
Have logged it at bugs.splitbrain.org - Hope that is what you meant
rainer
I have a similar (or maybe the same) issue: dokuwiki slows down and takes about 5 or more seconds to display a link.
I played with the acl.auth.php settings and had some errors (e.g. no acl set). But also for some seconds the normal fast dokuwiki behaviour.
dokuwiki version is the latest with Pagelist and indexmenu.
but I think it has something to do with the acl
I would like to deny reading and everything to ALL. then add users/groups with special privileges.
I also just had the message: "no valid authorisation system in use" above "Sorry, username or password was wrong." and can not login.
the strange thing is that the same dokuwiki run pervertly fast on my local os x. I copied the file to a opensuse 10.1 server. on the server it was slow. on my desktop it is fast.
stoffell
I once had speed issues, then I disabled these options in admin and it was resolved:
Disabled: Compact CSS and javascript output
Disabled: Use gzip Content-Encoding for xhtml
cheers
rainer
Thank you Stoffell,
but disabling the options does not change anything for me.
I upgraded to the latest dokuwiki release and upgrade also the plugins (, but logged in as admin makes the pages really slow. browserindependent. (safari, ff3, camino).
Any other hints?
* I only use 3 groups at the moment: readonly, user and admin.
* used nonstandard-plugins: blog, indexmenu, pagelist, tag,
hitch-ropers
I had the same/similar problem (version: Release 2009-02-14b). Everything was working fast, except when logged in as admin. But for me, it was the badbehaviour plugin. I disabled that, now it works great again. (kind of ironic, given the name)
rmgregory
This is actually an issue and I personally can't determine why (and should be able to do so).
When logged in as a member of the admin group, more specifically when maintained login as a member of the admin group, all pages incur a delay. The delay is more pronounced when "Use gzip Content-Encoding for xhtml" is enabled. The delay is actually at the end of rendering: content is returned to the browser, but the transaction doesn't complete (in the browser's opinion) and ultimately the browser times out. A Firefox add-on allows visualization of the behavior.
rainer
hello again ;o)
I recently did a fresh install on the same server with the lates dw (2009-12-25c "Lemming").
Then I added the monobook template/theme and some plugins: indexmenu, tag, blog, pagelist, include.
Everything was ok so far.
The I added a .htacces file to force users to login before displaying content.
and from now on the wiki is as slow as before when my login belongs to the admin group.
turnermm
I have seen this kind of behavior on other than Dokuwiki sites, when using an Apache authentication login to access a web site. It's been a while, but I seem to recall that this significantly slows down the processing of scripts, producing a noticeable lag. The same web site, with the same scripts, on the same server, but not protected by Apache's authentication, is immediate by comparison. I found this out when I was developing software for a web site and had one public installation and one, for testing, in an Apache password-protected directory.
rainer
after I had some trouble with the dokuwiki-installation it is fast now fast.
What happened:
after I checked the "broken_iua" option in the config I was not able to do configuration from within the wiki: the whole top part with "username, admin, mytalk, update profile, logout" was missing.
instead there was the red alert message ""Command unavailable: admin".
I don't know what it was exactly, but after I figured out how to reset this option in the /config/default.php (first try) and in /config/local.php (second try ) it somehow not only repaired my "unavailable admin problem" but also made the wiki as fast as it should be. even with admin logins.