[pmwiki-users] PmWiki seems to "hang" on overloaded boxes
Patrick R. Michaud
pmichaud at pobox.com
Sun May 22 23:17:40 CDT 2005
On Sun, May 22, 2005 at 10:22:34PM +0200, Joachim Durchholz wrote:
> >Yup, that's likely the issue. There may also be issues with
> >interactions between session-based authentication and the .flock
> >file; beta30 takes care of these also.
> Ah, I didn't know that.
> Would that apply to the situation at hand? That wiki is configured with
> the same password for 'admin', 'edit', and 'upload' (i.e. nothing
> fancy); I don't know whether that's cookie-based or session-based auth.
Session-based auth is a cookie-based auth.
> >FWIW, in terms of "when things are converted to HTML", it's page,
> >header, left sidebar, right sidebar.
> Hmm... not sure what you mean here. The template in question has a CSS
> layout, and the template code lists both sidebar sections before the
> main page section, so I'd gather that's the order in which things are
> being processed.
PmWiki first converts the main page contents to HTML first, then it
begins sending the template. When it encounters any <!--wiki:...-->
items in the template, they're converted into HTML at that point.
> Two buglets I noted in passing:
> The first call to StopWatch is done immediately at the start of
> pmwiki.php, before config.php had a chance to set it. It might be a
> better strategy to collect raw timing data as returned by PHP, and
> postpone the (more CPU-intensive) formatting to DisplayStopWatch().
I originally tried doing it this way, but it turns out that collecting and
storing the raw timing data ends up being about as much work as formatting
> The 'varlink' pattern (in scripts/vardoc.php) says $WikiWordPattern to
> determine what a valid PHP variable name is, and that's a bit too
> strict: it doesn't recognize (for example) the $Skin variable.
Yes, I'm just not sure I want to reduce its strictness for the sake
of the few non-wikiword variables that exist.
More information about the pmwiki-users