Presentation is loading. Please wait.

Presentation is loading. Please wait.

More than one way to skin a Plone? Or, what we learned about Plone skinning the hard way David Little, ITS Web Team 020 7631 6311 Available.

Similar presentations

Presentation on theme: "More than one way to skin a Plone? Or, what we learned about Plone skinning the hard way David Little, ITS Web Team 020 7631 6311 Available."— Presentation transcript:

1 More than one way to skin a Plone? Or, what we learned about Plone skinning the hard way David Little, ITS Web Team Available from

2 Introduction Look at approach to Plone skinning weve taken. Advantages and disadvantages of this approach. What we will do in the future. Plone 2.5 only. Plone 3 a different kettle of fish.

3 Background Zope + CMF sites Basic, but flexible: totally custom main_template with s. Pretty much same view for public and logged in users Simple, but limited. Need for hacks to achieve functionality that comes out of the box with Plone UI. We (well, I) expected to be able to easily replicate current approach in Plone – total customisation of template with editor UI sitting nicely in the content column. Think again!


5 Why move to Plone? Had been keeping an eye on Plone but werent convinced (trialled early 2005 for Web Team intranet). Starting to feel limitations of Zope – wanted custom content types; more development on Plone products, less on Zope (reflected in traffic on Zope and Plone mailing lists).

6 Why move to Plone? [2] Impressed with Archetypes – investigated for a project which was later cancelled (export from proprietary CMS to Plone). Brief to create marketing microsite. Clearly definable custom content types. Didnt want to create a database or hack CMF Product level for new content types. Perfect opportunity for Plone.

7 Prospective students microsite Marketing microsite – available at: Design from design agency (Indigo Creative). Photoshop mock-ups converted to XHTML 1.0 strict / CSS. Doesnt look like Plone.


9 First steps towards skinning Tried to create a consistent look and feel for public and edit view of the site, with little knowledge or experience of Plones CSS structure -- really should have read Alexander Limis article on at this stage! As per Zope sites, customisations made TTW (portal_skins/custom)

10 Round 2 Created a view skin using our XHTML and CSS, took out many of the etc. calls in the standard Plone template. Admin skin for site editors – default Plone skin with minor amendments. Python script to switch skins depending on users permissions. Filesystem product based on DIYPloneStyle. Added Public view tab to allow editors to preview page in the public skin. Cookies swapped with Javascript. View page in public skin via iframe.



13 Advantages of this approach [1] Didnt have to shoe-horn our design into Plones HTML structure / re-invent our CSS. Technology shouldnt dictate look and feel. Plones HTML is verbose. Lots of,, and tags. Works fine, but you can create a usable, accessible three-column layout more easily (which is what we did).

14 Advantages of this approach [2] Public view – cut down on amount of processing Plone has to do; e.g. remove calls for site actions, portal tabs, personal bar, Plone UI CSS/JS. Editors have access to full Plone UI for managing content, searching, monitoring workflow status of items etc. No real problem for sites with small number of skilled editors.

15 Disadvantages Skin structure can potentially become complex (e.g. another skin layer for scripts shared between public and admin skins). Inconsistency of view – becomes a real problem with restricted publishing – certain users log in with their details to view a page and skin switches. Problem on more devolved sites with easily confused, less technically-able editors.

16 Skin switching: a summary Not ideal, but not evil; especially if your public skin differs radically from Plones and you need flexibility. May be OK for a small number of editors who are known to you. More complex version of this (with staging / deployment) covered in Martin Aspeli article, Creating public websites with staging and custom skins (outdated). C.f. CMFDeployment / Entransit (alpha only). Limi – recent article: Plones future may not be in Web publishing? Revisiting the idea of Web deployment as separate from content / document management.

17 Alternatives [1]: override Plones CSS Possible to use Plones template (i.e. its XHTML structure / CSS) as basis for your own customisations. Override CSS as necessary (e.g. use Firebug to identify classes and IDs you want to change). Register own stylesheets and skins via a filesystem product (e.g. DIYPloneStyle).

18 Overriding Plones CSS: advantages Take advantage of the best bits in the Plone template – accessibility and usability, built-in CSS hacks (good for IE6 niggles). Just override the stuff you want to change, e.g. in ploneCustom.css. It can work (have built a site more or less using this approach).

19 Overriding Plones CSS: disadvantages Your site may differ too much from your design = bad. Worse still, your site may look like a Plone site = worse. Design should not be determined by technology = reflects badly on Plone (and you, the developer!). You could end up with a complex CSS structure – you could potentially have a class defined in a number of stylesheets = headache. Plones CSS is MASSIVE (c.3400 lines out of the box); and youre making it even bigger = potential maintenance nightmare.

20 Help, my site looks like a Plone site!

21 Oh dear, my CSS is a bit complicated

22 Alternatives [2]: Pick and choose from Plones CSS Havent fully tested this, but initial tests look promising. More savvy of you probably doing this already! To use the Plone editing UI you need at least: –authoring.css You may also want to use: –base.css (e.g. for form elements) –generated.css (for content type icons) Need relevant Javascripts too. Turn off CSS you dont want via portal_css (or via DIYPloneStyle-based Product).

23 Alternatives [2]: Pick and choose from Plones CSS Register your own stylesheet and skins. Keep Plones HTML structure – or not. But, probably a good idea to keep the same column IDs, i.e.: –#portal-column-one –#portal-column-content –#portal-column-two Plone editing UI should work fine (but be careful with your #portal-column-content styles).

24 Pick and choose: advantages Potentially less work (at least on CSS side, still may want to customise portlets etc.). Greater flexibility – use Plone HTML or not (with caveats). Consistency for public and admin views: less confused / irritated editors.

25 Pick and choose: disadvantages Inevitably will loose some of the functionality of the editing interface. Plone may still be working harder than it needs to processing calls and bringing in unneeded CSS / JS in the public view, but could be controlled with s etc. (can set conditions on CSS/JS via the CSS and JS registries).

26 Summary There is more than one way to skin a Plone. Approach will reflect need and complexity of project. You will be making compromises. What have others done? What about Plone 3?

27 Some interesting links Martin Aspeli, Creating public websites with staging and custom skins [marked as outdated!]: – Alexander Limi, –Creating a new theme for Plone: a real-world example: themes themes –18 things I wish were true about Plone: – about-plone/ about-plone/ Denis Mishunov, Making Plone theme: 10 most wanted tips [sic]. Video available from: –

28 Plone products mentioned DIYPloneStyle (available for Plone 2.5 and 3): – CMFDeployment (beta only): – Entransit (alpha only): –

Download ppt "More than one way to skin a Plone? Or, what we learned about Plone skinning the hard way David Little, ITS Web Team 020 7631 6311 Available."

Similar presentations

Ads by Google