Why you should add fallbacks for your theme parameters

Bring your Plone Diazo Theme to the next level with fallbacks for your theme's configuration parameters.

Say you create a new theme and deploy it to your customer's website. You're making the theme more dynamic by adding configuration options, so you can have one theme with different layouts. Perfect. Now you tell your customers how to adjust those settings using the Plone Theming Control Panel. They start playing with it and your theme just crashes. Why? Because theming parameters are not that easy to understand, end user friendly and don't have fallbacks.

You won't be able to catch every possible error, but you can at least add fallbacks for your params in case they get removed from the configuration panel.

Wenn you create your theme your manifest.cfg might look like this:

title = Your Theme
description = A Theme.
preview = preview.png
doctype = <!DOCTYPE html>

portal_url = portal_state/portal_url
header = string:normal
email = string:info@example.com

Users are able to change those parameters using the Advanced section of the Theming Control Panel. Since those params follow a very strict syntax, a lot can go wrong. We cannot check for the correct syntax or type errors, but we can at least make sure that if a param has been removed accidentally, the theme still works in a fallback configuration.

<?xml version="1.0" encoding="UTF-8"?>
<rules xmlns="http://namespaces.plone.org/diazo"

 <!-- The empty params defined here will be overridden by your manifest.cfg. -->
 <xsl:param name="portal_url"></xsl:param>
 <xsl:param name="header">normal</xsl:param>
 <xsl:param name="email">info@example.com</xsl:param>

 <!-- Now add your rules ... -->

Notice that the fallback for the portal_url is empty, while the other params have the same default value as in the manifest.cfg. That is simply because we cannot compute the URL in the rules files, so we use an empty value to have relative URLs.