[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 mailing list