Customising plone templates

[J Cameron Cooper]

Reinout van Rees wrote:

> Often, the client wants us to change some of the plone templates. When
> that is a large-scale replace/rebuild of the main_template, ok. But what
> I see most often in our practice is a small tweak here and there. An
> added textual explanation to a form. Adding a dropdown to the search
> box. In most of the cases, the majority of the template remains intact.
> 
> Then a new plone release arrives. Has anything changed in the templates
> we've adapted? Do the changes conflict? Do we need to adapt some more?
> At least, that are the questions I'm confronted with.
> 
> The reason? Quite simply copying the templates to a customizing
> product's skin directory and modifying them there. At least, that's the
> practice I'm using myself. It strikes me as sub-obtimal.
> 
> How do you all handle this?
> 
> I just did some braintorming and came up with the following rough idea:
> 
> * Have some directory with diffs to the original plone template.
> 
> * Have a small script copy the original plone templates and apply the 
> diffs.
> 
> * If there's a .metadata file, copy that right along.
> 
> * Check the page template for validity (i18ndude is a great validator)
> 
> * With a new plone release you can easily spot the templates that have
> conflicting patches.
> 
> 
> Just brainstorming :-)

I wrote a product once that, instead of creating FSPageTemplates from 
whole files created them based on a patch. It works, but I discovered 
quickly that when Plone does (biggish) upgrades, usually the patches 
won't apply cleanly. Certainly it didn't work for our 2.0->2.5 jump.

http://rhaptos.org/cgi-bin/viewcvs.cgi/DifferenceEngine/trunk/

It also has a simple "patchlib" that uses the system patch command, 
since Python has a difflib but no way to go the other way round. So it's 
pretty much Unix-only, though I suppose you can get 'patch' on Windows 
in a few ways.

But, like I said, I don't think it's practical. Maybe it could be with a 
little more work, but I think it's easier to:

   1) insist that any change to a template from somewhere else be noted 
in a comment on that template

   2) on upgrade, reapply those changes, if necessary

It's annoying, but not too hard. I wrote a little script to more quickly 
gather the information I needed for this: 
http://rhaptos.org/cgi-bin/viewcvs.cgi/devsets/plone25/updiff?view=auto

Give it the file you want to upgrade, and it creates:

   X.diff - what you changed between the orig file and the customized one
   X.stock - the new stock file
   X.new - same as above, but meant to be modified
   X.old - the stock file from the old version
   X.patch - if possible, X.diff applied to X.new

Generally, if X.patch is successful (it hardly ever was, for me) then cp 
X.patch to X and check in. After making sure it was right, of course. 
Otherwise, apply the changes in X.diff to X.new, referring to the 
comments and other reference files if necessary, and then cp X.new to X 
and check in.

The metadata files need the same treatment, by the way. They can change. 
Also, if a file moves between the old version and the new (like all the 
stuff in plone_login now) then you have to do a lot of this by hand.

Not super-advanced, but it worked. Requires a lot of edit buffers, though.

              --jcc
-- 
"Building Websites with Plone"
http://plonebook.packtpub.com