On Dec 17, 2012, at 12:44 PM, Dave Fisher wrote:
>
> 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.
Actually the r[1] line needed to be reversed.
Here is the patch about to be applied:
Index: view.pm
===================================================================
--- view.pm (revision 1423170)
+++ view.pm (working copy)
@@ -101,6 +101,12 @@
return Template($template)->render(\%args), html => \%args;
}
+sub htm_page {
+ my (@r) = html_page @_;
+ $r[1] = 'htm' if $r[1] eq 'html';
+ @r
+}
+
sub sitemap {
my %args = @_;
my $template = "content$args{path}";
Index: path.pm
===================================================================
--- path.pm (revision 1423170)
+++ path.pm (working copy)
@@ -11,7 +11,7 @@
[qr!rightnav.mdtext$!, single_narrative => { template =>
"navigator.html" }],
[qr!\.mdtext$!, single_narrative => { template =>
"single_narrative.html" }],
[qr!\.html$!, html_page => { template => "html_page.html" }],
- [qr!\.htm$!, html_page => { template => "html_page.html" }],
+ [qr!\.htm$!, htm_page => { template => "html_page.html" }],
) ;
# for specifying interdependencies between the files
We can discuss the cleanup of the old *.html files later.
Regards,
Dave
>
> Regards,
> Dave
>
>
>
