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

[Joachim Durchholz]

H. Fox schrieb:
> On 3/2/06, Joachim Durchholz <jo at durchholz.org> wrote:
>> 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?
> 
> It would be a minimal problem, if any at all.  Besides, the filename
> would be LICENSE.txt and that wouldn't conflict with a LICENSE.Txt
> wikipage.

Neil already answered that.

>> Or future changed group/page
>> naming conventions
> 
> That's what release notes are for.

Most people don't read release notes. It's far too much text, and 
administrators have far better things to do than read release notes. 
They expect to upgrade with minimal hassle.
PmWiki did that quite well in the past, and should continue to do so.

>> - should PmWiki's future path be constrained by
>> CleanUrls,
> 
> Point #1) It already is.

???

> Point #2) Both solutions are susceptible to a change in naming
> conventions.  Take "names can now start with numerals" as an example.

No, digits should be part of the wikipage namespace.
If you really want to serve files with numbers, you have two options:
1) Transcribe the file to a wiki page.
2) Manage the namespace from outside PmWiki. (On Apache, that would mean 
mod_rewrite.)

PmWiki shouldn't attempt to solve namespace collisions. That's something 
for the WWW server administrator.

PmWiki shouldn't have to worry about collisions. Which, in turn, means 
that the only places where the PmWiki directory should contain 
non-distributed files are:
* local/
* pub/
* wiki.d/
(and farm directories).
In other words, if there are files served directly from the PmWiki 
directory, that should be an exception. Not something where PmWiki 
should worry about "making it work" - it would also be making PmWiki 
less predictable. (Predictability is exceedingly important. Particularly 
predictability for people who're doing routine activities without 
understanding all the details.)

>>> 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.
> 
> That's what the documentation and mailing list are for.

One of PmWikis tenets is: "Easy to administer."
Please reconsider.

>> 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).
> 
> It's a lot easier just to use the .htaccess from the new recipe. :-)



>> Maybe the different ways to divide up URL space should be listed as
>> equally-ranked alternatives on the CleanUrls page.
> 
> IMHO adding another equally-ranked paradigm for solving the problem
> would make an already-confusing subject even more confusing.

That's exactly the issue I'm having.
Serving existing files is adding to the confusion in the long term, even 
if it solves some short-term problems.

Fallback strategies like "serve it if it's a file, try the wikipage if 
it isn't" definitely fall in this category - fallbacks are *bad*, 
because if things don't work that should, you have to revisit the entire 
chain of fallbacks and find out where it *should* have worked. Not an 
issue if you know all of the configuration by heart, but consider 
maintaining somebody else's site... or revisiting your own site three 
years later.
I have had the dubious honor of "debugging" systems that use fallbacks, 
and the fun factor of such an endeavour diminishes exponentially as the 
lengths of the fallback chains increases. (The only reason to do 
fallbacks is for backwards compatibility. Such as Site.SideBar and 
Main.SideBar. I still recommend choosing a single policy and sticking 
with it, else you'll perpetually wonder why your changes didn't make a 
difference, or why your changes had unanticipated side effects.)

 > The most
> we should do is add a note that points to the divided-up-URL-space
> solution on the old page or maybe a newly-created alternate page.
> 
> Whatever you decide to do, I hope you don't negate the large amount of
> work I've put into the new CleanUrls recipe.

I'm not going to rewrite CleanUrls in the foreseeable future. Too many 
other things to do. Nor am I "appointed editor" of that page.

I just happened to have some serious CleanUrl problems, took the 
opportunity to read up on the subject on the Apache docs, grok enough of 
them (and of mod_rewrite, which has all the flexibility and obscurity of 
a sendmail configuration), and rewrote the page (mostly from scratch, 
though I'm pretty sure that a few paragraphs have survived).

I also quickly found out that my writing was tailored towards my 
specific situation; the page almost immediately filled with questions 
and "it didn't work for me" messages that I couldn't answer. My 
experience is limited to one or two specific setups, so I can't answer 
questions for every situation, or easily separate useful from dangerous 
approaches; somebody with a far wider experience should rewrite that 
page (and probably from scratch again). (There are a few things that I 
*can* say aren't good long-term solutions. Unfortunately, it's not 
enough to positively identify those solutions that will work for any 
reasonable configuration.)

Regards,
Jo