littled.net

This is a summary of a presentation I gave at the Zope/Plone day at Birkbeck, 12 February 2008. The full presentation is available as a Powerpoint file (sorry) from Plone4Universities.

The presentation is based on the different approaches that can be taken to Plone skinning, based on my own experiences in this area.

I’ve included it here as I hope it will be relevant to some people as an overview of the approaches one can take in skinning a Plone site. More detailed documentation can be found on the plone.org site of course. It’s also outdated in the sense that it doesn’t cover Plone 3 which has a different approach to skinning; not one which I’ve tackled yet.

Background

Last summer I created two high profile Plone sites for the organisation I work for. These were the first Plone sites I’d worked on; previous to this we were using sites created using Zope and the CMF. These sites were in some ways basic, but very flexible. All customisations on these sites were made through the web, in most cases this involved tweaking CSS and images. The outward facing view of the site and the view which editors saw were virtually identical, with some minor additions for site editors. Given our user base, this approach was something I was hoping to replicate in Plone but experienced difficulties in doing.

I wanted to use Plone for these sites as I felt it clearly met the requirements, particularly in the area of having custom content types which is something we’d never found easy to do in our old Zope/CMF set up.

Before work had started on the first of these sites, we’d received a design from an agency which had been converted into XHTML 1.0 strict / CSS.

First steps towards skinning

My initial attempts at achieving a similar set up to our Zope sites were pretty disasterous: I managed to destroy the Plone editors UI pretty quickly. Looking back, I really wished I’d read Limi’s article about creating Plone themes at this stage!

After going back to the drawing board and trying different iterations of ideas, I ended up with a filesystem skin based on DIYPloneStyle. We ended up with two different skins: a view skin based on our template with much of the Plone <metal> calls removed and an “admin” skin for site editors, basically the default skin with some minor amendments. Skins were switched depending on users’ permissions using a Python script. The two views were substantially different, although I added an extra editing tab, “Public view” which allowed editors to preview their page in the public skin — in an <iframe> using a bit of Javascript to swap cookies out.

Advantages of this approach

The advantages of this approach were:

• We didn’t have to shoe-horn our design into Plone’s HTML structure or re-invent our CSS
• Plone’s HTML is pretty verbose: Lots of div, span, dl and h5 tags which is fine in itself but you can create a usable, accessible three-column layout more easily
• Removing some <metal> calls in the public Plone template (e.g. site actions, portal tabs, personal bar, CSS and Javascript) cut down on some of the processing Plone had to do
• Editor had access to the full Plone UI for managing content and workflow, searching etc.
• This didn’t present a problem in a scenario where there were two or three highly-skilled, technically aware site editors.

Skin switching: disadvantages

There are some clear disadvantages of this approach:

• Skin structure can become complex — I ended up with a third skin layer for scripts shared between my admin and public skins
• Inconsistency of view is a problem in terms of restricted publishing — e.g. if a user logs in just to view a restricted page, the Plone skin may switch depending on their permissions
• This quickly becomes a problem on more devolved sites with easily confused, less technically aware editors

Skin switching: a summary

• It’s not ideal, but it’s not in itself “wrong”, especially if your public skin differs radically from Plone’s and you need flexibility
• Not really a problem on smaller sites
• There’s some discussion in the Plone community at the moment about Plone as a content management platform and Plone as a web publishing platform, with some suggestions that it should concentrate on the former rather than the latter. See for instance:
  • Alexander Limi, “18 things I wish were true about Plone“, point 14
  • Martin Aspeli, “Is Plone too hard?“

  So, could a consistent look and feel for editing and viewing be irrelevant? Will web publishing be handled differently in future releases?

There are obvious alternatives to the skin switching model:

Overriding Plone’s CSS

• Keep Plone’s template (i.e. its XHTML structure and CSS) as a basis for your own customisations
• Override the CSS as necessary
• Register your own stylesheets and skins via filesystem product, e.g DIYPloneStyle

Override Plone’s CSS: advantages

• You can take advantage of the best bits in the Plone template — e.g. accessibility and usability, built-in CSS hacks for your IE6 niggles etc.
• Override what you need to in your own stylesheet.
• It can work — I’ve built a site more or less using this approach

Overriding Plone’s CSS: disadvantages

• Your site may differ too much from your original design
• Worse still, your site may look like a Plone site (nothing wrong with Plone’s design as such but do you really want it as your public facing skin?)
• Your CSS can become complex
• Plone’s CSS is massive (c. 3400 lines) and this approach is just adding to it! Can be a bit of a maintenance nightmare

Pick and choose from Plone’s CSS

• Not fully tested yet, but we have had some initial successes with this
• To use the Plone editing UI you need at least:
  • authoring.css
• You may also want to use:
  • base.css (for form elements etc.)
  • generated.css (for content type icons)
• You obviously need the relevant Javascript
• You can turn off the CSS you don’t need via portal_css or in your DIYPloneStyle-based product
• You can choose to keep Plone’s structure, or not. But, it’s probably a good idea to keep the same column IDs, i.e.:
  • #portal-column-one
  • #portal-column-content
  • #portal-column-two
• The Plone editing UI should work fine, although you may need to be careful with the way you cascade your portal-column-content styles

Pick and choose: advantages

• Potentially less work (at least on the CSS side, you’ll probably still want to customise portlets etc.)
• You get greater flexibility — you can use Plone’s HTML or not (but with caveats)
• You get greater consistency for public and edit views and therefore less confused or irritated editors

Pick and choose: disadvantages

• Inevitably you’ll lose some of the functionality of the editing interface — e.g. if your site doesn’t use “tree” navigation in view mode, then you’ll not get it in edit mode
• Plone may still be working harder than it needs to in public mode, processing metal calls and the like

Summary

• There is more than one way to skin a Plone
• Your approach will reflect your need and the complexity of the project
• You will be making compromises