[pmwiki-users] Putting ".html" extensions onto pages
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
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
> 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