[pmwiki-users] How use lowercase in Group Names

Waylan Limberg waylan at gmail.com
Wed Sep 28 12:47:05 CDT 2005

On 9/28/05, Patrick R. Michaud <pmichaud at pobox.com> wrote:
> On Wed, Sep 28, 2005 at 09:35:03AM -0600, Spare Room wrote:
> >    Curently I can create groupnames only with first letter capitalized.
> >    ie: sitename.com/Whatever/PageName.
> >    Can I also make groupnames in lower case?
> >    sitename.com/whatever/PageName
> This can be done, but it requires changing quite a few configuration
> variable settings.
> >    Or.....is there a way so that if a user types it in lowercase, it doesn't
> >    throw an error but finds the capitalized version?
> Well, on servers that have case-insensitive filenames (e.g., Windows),
> PmWiki already understands lowercase pagenames.
> On Unix-based servers PmWiki can already understand urls that
> don't begin with a capital letter -- for example, see
> http://www.pmwiki.org/wiki/test/homePage .  Note that this isn't
> true case-insensitivity for the entire name -- the "P" would still
> have to be capitalized.
> Getting true case-insensitivity on case-sensitive filesystems might
> require a fair bit of work or slow down the overall system a bit,
> especially when doing backlinks, categories, or searches.
> Although, come to think of it, for this we don't need case insensitivity
> throughout the system -- only at the point where we're processing
> url information.  We might be able to come up with a reasonably
> fast method for converting a case-insensitive url into a case-sensitive
> pagename.

I've explored the possibilities here before as well, but gave up (ok,
not really, just moved it to the very back burner) when I realized how
intertwined the uppercase group and page names are in the core. If
this could be done, that would be excellent. The problem as I saw it,
was that much the url resolution code is before config.php is included
so the work was already done before I had a chance to manipulate it
with my own code, unless I altered the core somehow. Of course, if you
built in the ability, my issues would (more) easily be solved.

> One last point -- your specific question was:
> >    Can I also make groupnames in lower case?
> >    sitename.com/whatever/PageName
> I'm assuming from this that you're using CleanURLs of some form --
> note that several of the CleanURL approaches rely on the fact that
> the first character of the group is uppercase.  In particular,
> there has to be a way to preserve access to the pub/ and uploads/
> directories; if http://sitename.com/whatever/PageName needs to
> download a .css file from http://sitename.com/pub/skins/pmwiki/pmwiki.css,
> then the webserver will need some way of knowing that the "pub/"
> here refers to a normal directory and not a PmWiki group.
I noted this issue when exploring the possibilities as well. I was
sure there was some other way to format the rewrite rules in .htaccess
to avoid this situation, but given the other factors I didn't really
pursue it at the time. Anyway, later I came across another project
that used an interesting approach to the rewrite rules. They were in
part as follows (modified for PmWiki):

RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)$ phwiki.php?n=$1 [QSA,L]

The key is the "!-f" part which essentially means: 'If the requested
file name does not exist use this rewrite rule, otherwise proceed as
normal'. So, if the request is for a style sheet, image, attachment
etc., and the file exists, then that file is served. If not, then the
request is passed to PmWiki. And, say someone has created a group
named 'pub'. The server gets a request for .../pub/HomePage, but the
file doesn't exist (obviously), so the request is passed onto PmWiki.
Conversely, a request is made for .../pub/HomePage.html and that file
has been added to the system for whatever reason. The file gets served
(the fact the the file has been put there lets us assume it is
supposed to be served). The only thing I'm not sure about is what
happens if the file exists, but access has been restricted (such as in
the local dir). Do we get an Apache error or does it get passed to
PmWiki? Seeing that PmWiki already handles error messages, I don't see
this as much of a problem. Either way, it's something I think is worth
exploring (I should note that I have not tested this yet in my install
of PmWiki). Your thoughts??

> Pm
> _______________________________________________
> pmwiki-users mailing list
> pmwiki-users at pmichaud.com
> http://host.pmichaud.com/mailman/listinfo/pmwiki-users

Why does all this matter? Well, IMHO, while the MixedCaseUrl is
certainly easier to read, it can cause problems when being typed
directly into the browsers address bar perhaps from a print
publication or a note from a friend. Consider email addresses. We've
all seen them formatted something like the following:
"JoeShmoe at HisCompanyInc.com". This is definitely easier to read and
helps with memory retention. However, no matter how you mix upper and
lower case characters when typing his address, it is always sent to
"joeshmoe at hiscompanyinc.com". All the user has to do is get the right
characters in the right order and it works. Requiring the proper
capitalization in a URL only adds more room for error. "You mean
'thisepage.html' is different that 'ThisPage.html'?" Or how about:
"Was that 'MixedCaseURL' or 'MixedCaseUrl'?" Personally, I'd consider
the first more correct, but the wiki would more likely generate the
second. And what happens with words like 'the', 'a' etc. that do not
normally get capitalized even in a heading? If I'm not mistaken,
PmWiki converts them to uppercase for the URL, which could add one bit
more confusion to the user. Sure, PmWiki can store the pages in
whatever format you want, and generate the URLs in whatever format the
admin wants (well, it would be nice if this was more configurable),
but all requests should be case insensitive IMO.
Waylan Limberg
waylan at gmail.com

More information about the pmwiki-users mailing list