[pmwiki-users] Putting ".html" extensions onto pages

Joachim Durchholz jo at durchholz.org
Thu Mar 2 03:57:51 CST 2006

H. Fox schrieb:
> On 3/1/06, Joachim Durchholz <jo at durchholz.org> wrote:
>>I'd recommend against looking what files are there and deciding what to
>>do later. Say you have a page named LICENSE, and a new version of PmWiki
>>place a LICENSE file in the installation directory...
> A wikipage named SomeGroup.LICENSE would not be affected by placing a
> file named LICENSE in the installation directory.

Sure. How about a group named LICENSE? Or future changed group/page 
naming conventions - should PmWiki's future path be constrained by 
CleanUrls, or are you prepared to cope with a broken installation on 
your server?
I can see all kinds of trouble lurking. I'll admit it's not a common 
problem, or one that's likely to hit you, or me. Or, in fact, anybody 
else - it's just that as soon as PmWiki has acquired a dozen or so 
marginal problems with a 0.1% probability of hitting somebody, the 
probability that one of them will hit is 1-0.999^12=1.2%. Multiply that 
with the number of PmWiki installations, and the thing gets real relevance.

CleanUrls is one of the most murky corners of PmWiki. Unavoidably so, 
since URL rewriting is generally a murky corner (not PmWiki's fault, 
Apache has flexibility all in the wrong places in this issue). However, 
being as conservative as possible tends to keep problems of this kind down.

> I don't see this becoming a problem.  At worst you'd need to add a
> special rewrite rule.

That would be beyond the capabilities of most PmWiki admins.
Besides, the problem would start after installing a new PmWiki version; 
nothing would point towards CleanUrls. PmWiki would suddenly start to 
look "quirky", with obscure bugs.

>>IMHO, it's better if the namespace is clearly divided: lowercase letters
>>for stuff served from the file system, everything else goes to PmWiki.
>>(With the obvious exceptions associated with $EnableDirectDownload.)
> It doesn't work very well when PmWiki is installed on a server that
> already contains files and directories that start with
> other-than-lower-case letters.
> I know this from experience.  I had several .txt files with CamelCase
> filenames on the Qdig site before I switched over to PmWiki.  The old
> rewrite rules broke some URLs, so links that existed in the forums no
> longer reached the files they originally reached.

Argh... blame those Qdig people.

Well, jokes aside, I think you already have a namespace conflict. 
Assuming you have a directory named Foo with a file named Bar, what are 
you going to server if somebody requests Foo/Bar: the file or the wiki 
page? Will you know what happened if the complaint comes?
More importantly: if admins follow your advice, will *they* know what 
happened when the complaint comes, or will they simply drop PmWiki on 
the grounds of "some edits won't get saved", without even looking into 
the problem?

> Even for a site starting afresh it can be inconvenient, not to mention
> confusing, to prohibit serving files or directories with names that
> begin with capital letters or numbers.

Sure. Whatever the rule, it will confuse some people.
I find that a rule like "serve if it's there, run PmWiki if it isn't 
there" has serious maintenance drawbacks. You find that dividing URL 
space across a lettercase argument doesn't work for you.
Personally, I judge your problem as a very specific one that hits very 
few people, and there are better alternatives (see next paragraph); I 
judge my problem as rarely relevant but difficult to diagnose and solve 
if it does happen (I have two and a half decades of experience with such 
things under my belt, and I have seen undiagnosable problems of that 
kind cause project leaders to cancel or restart projects and reject 
tools, binning person-months of work in the process. It's not the kind 
of press I'd like to see associated with PmWiki even once.)

In your case, I'd place the non-PmWiki content in a different directory, 
and use some URL rewriting and wrapper scripting to map PmWiki into the 
existing URL space (or maybe I'd install PmWiki and map the legacy 
content into PmWiki's URL space via some scripting in config.php - 
serving a HTML page from PHP is a two-liner last time I did it).

Maybe the different ways to divide up URL space should be listed as 
equally-ranked alternatives on the CleanUrls page.

Seems like CleanUrls needs yet another rewrite...
(Sorry, no, I won't find the time do it. I'm currently too busy getting 
some software out of the door).


More information about the pmwiki-users mailing list