<!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.
I can't tell you how important it is to PmWiki _not_ to introduce
changes that break existing sites, except perhaps on a major
revision number change.
</pre>
</blockquote>
<br>
OK, well I'm for being the guineapig...!!<br>
<br>
I think as Dave says, it starts with "MakePageNamePatterns". I agree
that going lower case would also be desirable<br>
<br>
This then causes a bunch of changes that we might as well try and
thrash out here and see if we can't get a solution worked out.<br>
<br>
For backwards compatibility I think we need to look at the names on
disk. We could do something like look for a dashed name and use that.
If not found then look for backwards compatible name. Two options
spring to mind, either update that old name on page save, or offer an
"action" which renames *all* pages to the new name<br>
<br>
(The nice thing about dashed names is that we don't loose any
information about how to build the old style camel case name. Well,
generally not at least... )<br>
<br>
Final backwards compatible issue is external links in going to the old
style names. I think it's best to issue a 301 redirect to these so
that google etc dont penalise for duplicate content. I guess best to
handle this with a function on the 404 not found page (as per the
Cookbook example for case insensitive URLS - another nice thing that
would be good to have in core...)<br>
<br>
Anyone spot anything I have missed? (At least in big picture terms)<br>
<br>
Ed W<br>
<br>
</body>
</html>