I'm running into a problem whereby the compiled cached version of a
template is refusing to update due to timestamp problems. This arises in
two ways:
- People are working in different timezones and/or have misconfigured
file transfer programmes and/or their local machine has the incorrect
time set. For example, the Indian office uploads a template to the
server but it keeps the Indian timestamp of +4.5 hours (eg 1800). 30
mins later, I then edit it on the server (or on my local machine) and
the tt2 file reverts to UTC (eg 1400) but the compiled cached version
remains stuck at the old version with a timestamp of 1800.
- Our setup propagates tt2 files across the server network via rsync
(for minor non-urgent edits) or via debian packages (for major edits).
If a server was offline it will install the already out-of-date deb
packages with the current timestamp then will get the newer rsync
version but will change the file to an earlier timestamp, leaving the
compiled cached version stuck at the old .deb version.
Ignoring the task of fixing the faults (and faulty people) in our setup,
is there a reason why the .ttc version only updates if the .tt2 has a
newer mtime? As far as I can tell, the guilty code is the following in
Provider.pm,v 2.88:
if ($compiled && -f $compiled
&& (stat($path))[9] <= (stat($compiled))[9]) {
Assuming the .ttc is always set to the mtime of the .tt2 (can't find the
code that does this, but observations suggest this), could the <=
instead be changed to == thus ensuring the compiled version has to match
(or at least have the same mtime) as the tt2 file?
Thanks,
:Travis
_______________________________________________
templates mailing list
[email protected]
http://lists.template-toolkit.org/mailman/listinfo/templates
