Dave Fisher wrote on Mon, Dec 17, 2012 at 10:20:05 -0800:
>
> On Dec 17, 2012, at 9:29 AM, Kay Schenk wrote:
>
> > On Sun, Dec 16, 2012 at 3:54 PM, Dave Fisher <dave2w...@comcast.net> wrote:
> >> Hi Andrea,
> >>
> >> On Dec 16, 2012, at 2:44 PM, Andrea Pescetti wrote:
> >>
> >>> Dave Fisher wrote:
> >>>> I think that we can purge these *.htm duplicates, but if we do it
> >>>> will be a "sledgehammer" build.
> >>>
> >>> It will also be a problem, unless we accompany it with other changes: for
> >>> example, http://www.openoffice.org/pt/ would completely break, and all
> >>> external sites that now link to some of our .htm files would break too.
> >>
> >> Got it.
> >>
> >>>> It was intentional. Before doing so we would need to make a group
> >>>> decision about how to treat the two types of files.
> >>>
> >>> Regardless of what templates we apply, the best solution should:
> >>> 1) Allow a .htaccess redirect/rewrite from .htm to .html (to preserve
> >>> existing internal and external links)
> >>> 2) Have the SVN file names match the URLs: editing a file named
> >>> "news.htm" in SVN should not result in a change in a page with URL
> >>> ".../news.html". The current handling confuses the CMS too (for example,
> >>> no diff is reported). So either we mass-rename files from .htm to .html
> >>> and rely on 1) above, or we don't change .htm to .html but publish .htm
> >>> URLs.
> >>
> >> We need only do (1) and I would do it within the httpd config like our
> >> existing redirects. Regardless if there are both file1.htm and file1.html
> >> in the source, one of these must be removed from the source svn.
> >
> > Dave, Andrea --
> >
> > Only ONE copy is in source, the "htm" file. The duplicate gets
> > generated from CMS -- but the new "html" is the most recent copy (on
> > the actual web tree) -- generated from "htm".
> >
> > Could we fix our templating to just continue to allow for "htm"
> > instead of combing them as we're doing now?
>
> It can be tried on a local copy. The prospective changes are required in
> lib/view.pm, but exactly what these changes are I am "guessing" at this point.
>
> It will be something about determining which type of page htm vs. html and
> then make the appropriate call here:
>
> I think, but do not know. If someone wants to experiment on a local build
> then I'll give pointers, but I may not have time to check for a day or two.
I think you could define:
sub htm_page {
my (@r) = html_page @_;
$r[1] = 'html' if $r[1] eq 'htm';
@r
}
and then use that in path.pm.
