On Dec 17, 2012, at 10:56 AM, Daniel Shahaf wrote: > 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.
Thank you. I'll give that a try in a few hours when I finish my work day. Meanwhile it is likely that you will delay the JIRA issue. I'll keep you posted both here and there. Regards, Dave
