[pmwiki-users] Putting ".html" extensions onto pages
jo at durchholz.org
Fri Mar 3 15:00:01 CST 2006
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
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
> 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
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:
(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."
>> 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
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
More information about the pmwiki-users