Skip to content

Practical collective.xdv

Last year I published an overview of collective.xdv. A new and very promising way of theming Plone. Now that we’ve used it a few times I thought I’d document some the process we went though.

Firstly read the documentation:

It’s very good and shows you the best way to structure your theme.

Our setup:

  • Plone 3.3.5
  • CMF 2.1.2
  • PIL 1.1.6

Setting Up Collective.xdv Best Practice

The collective.xdv documentation has a very good description of the best way to setup  collective.xdv read it. I won’t go in to the full details as they are well documented but the basic points are:

  • Setup a Plone product
  • Use css registry to serve the css, instead of serving through XDV. This gives you the all the advantages of managing CSS through CSS registry (compression etc).
  • Create your html/css templates.

In our setup I turned off all stylesheets but kupustyles.css, authors.css, kupuplone.css, kupudrawerstyles.css when serving through XDV. I also created a new stylesheet to pull in what we needed from the admin theme. By adding back in on a case-by-case basis you can avoid CSS conflicts with your themes styles. Of course if you’re completely mad you could decide to restyle the admin interface (good luck with that).


There were a few snags we ran into. Here’s how we fixed them:

no styling with portal_factory

We ran in to an issue with our Plone setup and portal_factory. The transformation stopped working when you added content, leaving you seeing the default plone theme. Very confusing. Apparently it’s fixed in 3.3. but for whatever reason we had to use this monkey patch:

Here are some great tips for using collective.xdv as well:

IE conditionals

By default I was removing comments from both the theme and content. (<rules />) . As the IE conditionals are wrapped in comment tags I had to add them back based on their order.

<append theme='/html/head' content='/html/head/comment()[3]' />
<append theme='/html/head' content='/html/head/comment()[4]' />

Lack of applyPrefix support for Plone 3

Plone 4 has a option to parse a stylesheet for relavtive URLs and apply an absolute prefix. You’ll have to do this manually with Plone 3.

Styling the Search Box

I’m not a fan of Plone search box so it was nice to be able to just pull out the action attribute to use:

<prepend theme='//*[@id="search-form"]' content="//*[@id='portal-searchbox']/form/@action" />

Using Conditionals to Select Templates

Using Plone’s default body classes or defining your own you can specify which template to use based on class name. This is a big win as you no longer have mess around with macros or the main template. For example:

<theme href="one-column.html" css:if-content="" />
<theme href="two-column.html" css:if-content="body.two-column" />
<theme href="three-column.html" css:if-content="body.three-column" />

Pulling in Content

You could bring in content piece-by-piece – writing rules for each element. I found this was time consuming and difficult. In the end it made more sense to pull in the all content from each column. If you want to re-work the HTML of a standard portlet it’s better to use inline XSL (more on that in the next article)

<replace content='//*[@id="portal-column-content"]/div/*' theme='//*[@id="content"]' />


From my perspective:

  • It gives control of the templating to the front-end dev / designer.
  • It allows working in parallel with Plone devs rather then them waiting for templates to be completed.
  • Using collective.xdv dramatically sped up the time we had a skinned site we could show to the client.
  • We cut the time we spent doing donkey work and increased the time we could spend on worthwhile development.

I’ll leave it to the Senior Developer to give the pros from an experienced Plone developer:

  • No mangling of reference HTML templates as they are implemented in TAL by Plone Devs
  • improved team workflow as HTML/CSS Designer/Dev can work in parallel with Plone Devs
  • lighter workload for Plone Devs as there is much less HTML to implement in TAL
  • reduced need to explicitly remove unwanted elements from TAL templates – they can mostly be ignored by xdv
  • flexibility in layout between pages – i.e. one-column, two-column, three-column layouts don’t require a mass of macros and modification of main_template to achieve. This can instead be pushed up to the XDV layer.