[DEPRECATION WARNING: As of 3.0, this approach is no longer recommended. In Plone 3.0, we no longer use DIY Plone Style for creating themes. Instead, we use buildout for setting up a development environment, and paster and ZopeSkel for creating a theme product. Search for these items as well as for documentation on managing viewlets and managing portlets in 3.0 (found in the Visual Theming area of plone.org/documentation). More documentation on theming for 3.0 is coming soon.]

With Plone 2.1 and up, we have a new method of skinning Plone that makes it a lot easier than the approach used in earlier versions of Plone.

I won't dwell too much on how it was done earlier apart from saying that it was based on taking the existing Plone CSS, overriding the existing CSS rules and creating a new skin based on this. This approach had numerous problems:

• It was very complex if you didn't know much about CSS
• It was prone to breakage when upgrading to new versions of the Plone CSS (even minor changes would make your theme change
• It caused the CSS output files of Plone to be very large

The new approach

With Plone 2.1 and up, we have a new infrastructure component called ResourceRegistries. This component allows us to split up CSS and Javascript on the server side, so it can be managed in a sane way. We can attach conditional checks on parts of the CSS/JS, and merge it all to a single CSS/JS file on the way out, so that the browser only sees one CSS file to reduce the amount of file requests needed. In later versions, RR also added CSS and JS compression to keep file sizes down.

What this means for us when we want to create a Plone Theme, is that we can selectively disable parts of the Plone user interface CSS. A very common approach is to keep the CSS for authoring (the green border, the forms CSS), and customize only what people see when they are not logged in. This has several advantages:

• We can start with a blank slate, and apply our CSS without interference from Plone
• We can reduce the download size of the CSS to only what we need
• The theme becomes much more resilient to changes in Plone itself

The reason this approach is more robust when it comes to keeping compatibility with future Plone versions, is that it is only relying on HTML IDs and classes, which should rarely change. (Realistically, there are some changes now and then to the classes and IDs too - but these are much less frequent than other changes, and the Plone Team tries to leave them intact if possible)

There are three ways of changing Plone's appearance:

Simple changes

Replacing the logo and adjusting the colors. I won't cover this here, but it's covered in most of the books and in a couple of how-tos.

Comprehensive

Replacing all the styles that are visible to the public, but keeping the basic widget styles. May involve simple changes to main_template, but nothing radical.

Full

Starting from scratch and replacing all the CSS and rewriting templates (not recommended, will be a maintenance nightmare)

I will cover the Comprehensive use case.

Why keep the Plone structure?

Accessibility

Plone has been engineered to be friendly for users with motor or vision disabilities. This takes a lot of effort and testing — with Plone, you get it for free.

Search engine visibility

Out-of-the-box, a blank Plone site has the potential for a very high Google Rank. For plone.org itself, we have a Google Rank of 9/10, the same as Microsoft, IBM and similar massive entities on the web. We have spent a lot of time optimizing Plone for search engines. Google loves Plone. Plone loves Google. (Trivia: the only site I have found out there with a 10/10 Page Rank is the W3C page — anybody know of others? :-)

A note about terminology

Throughout this tutorial, I use the word "theme" to describe the collection of visual modifications done. In other parts of the Plone literature, this is described as "skinning" and the end result a "skin". The reasons we're trying to move away from this terminology are several:

1. In Plone terminology, a "skin" can be both template, CSS and code modifications. We try to keep the visual themes separate from the code and template customization as far as possible, and use the word "theme" to convey that it is only about visual changes.
2. We encourage you to keep your other Plone modifications in a separate file system product, this makes the visual modifications / theme part of the equation much more reusable and simple.

For example, in our company we usually stick to the following product naming convention, with "Site" being the customer or project name:

SiteTheme

Holds the visual theme, and the other visual elements that are general (logos, background images, etc).

SiteTweaks

Holds small modifications to the templates, behavioral changes to the templates and Python scripts.

SiteSetup

Using the GenericSetup infrastructure in Plone 2.5 or up (or CustomizationPolicies in Plone 2.1 and older), this product holds the stuff that needs to be set up when you instantiate a site — configuration changes, SQL connections, etc.

As for infrastructural components, we never name these after the customer/project, but try to come up with generic names (as we often end up open sourcing these solutions and want neutral names for these).