<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Patrick R. Michaud wrote:
<blockquote cite="mid:20090225191542.GA9161@pmichaud.com" type="cite">
<pre wrap="">On Wed, Feb 25, 2009 at 06:16:05PM +0000, Ed W wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Given that I notice PmWiki moving away from CamelCase wiki words, it
seems like there should be little resistance to proposing a change in
the default URL naming convention also...
</pre>
</blockquote>
<pre wrap=""><!---->
I'm fully in favor of this, *if* we can find a way to make the
change without breaking existing sites. But in my experience
ranks up there with "convert PmWiki's default to utf8" in terms
of actual difficulty of achieving the result.
</pre>
</blockquote>
<br>
OK, I changed this in local/config.php<br>
<br>
$PageNameChars='-[:alnum:]';<br>
$MakePageNamePatterns = array(<br>
"/'/" => '', # strip single-quotes<br>
"/[^$PageNameChars]+/" => ' ', # convert everything else
to space<br>
"/(^\\s+)|(\\s+\$)/" => '', # trim whitespaces<br>
'/((^|[^-\\w])\\w)/e' => "strtoupper('$1')",<br>
'/\\s+/' => '-');<br>
<br>
This does most of what people might expect. Couple of issues remain:<br>
<br>
- There are lots of hardcoded CamelCase variables still in the code, eg:<br>
<br>
$RecentChangesFmt = array(<br>
'$SiteGroup.AllRecentChanges' =><br>
'* [[{$Group}.{$Name}]] . . . $CurrentTime $[by] $AuthorLink:
[=$ChangeSummary=]',<br>
'$Group.RecentChanges' =><br>
'* [[{$Group}/{$Name}]] . . . $CurrentTime $[by] $AuthorLink:
[=$ChangeSummary=]');<br>
<br>
The functions using the variable above don't run the name through the
function to make a page name either, so simply editing this array to
have a spaced name doesn't collapse in the expected predefined way<br>
<br>
Patrick - do you have a suggestion on how this could be addressed?<br>
<br>
<br>
- All the existing pages in wikilib.d aren't found (wrong naming
convention)<br>
<br>
This could be fixed with a "backwards compatibility fixup" in either
ReadPage or further downstream in the "read" function for the
pagestore. The idea would be to first search for the expected name,
then generate what the old name would look like and search for that.
Any comments on this?<br>
<br>
Question on what happens if you save - I guess check for the old name
existing and at that point rename the old page to the new format...?<br>
<br>
<br>
Thanks for any thoughts<br>
<br>
Ed W<br>
</body>
</html>