While I am thinking about this I will write it down. Here is a concept for modular theming that I know works.

All themes are modular, including the default theme.

Every theme would be stored in a logical directory structure under a main themes directory. The organization would look something like this:



The file organization is relatively simple and self-explanatory, and would use the same order of preference that tiki uses currently, with 2 possible changes:

1) signifigant style areas should have their CSS split into multiple files, to offer the user the option of customizing a particular area via css. This would work just like templates now: if(user_css_for_this_area_exists) { use_user_css } else { use_default_css } This improve performance by not sending one gigantic CSS file for every page viewed (the CSS I'm using right now is 100k!! and the average size of is about 50k...for every page load)

2) CSS files could be piped through smarty. This may or may not be needed, but it is an option to alter values in a CSS based on browser version. The other (preferable) option here would be to add a browser variable to the data that gets passed to smarty. This way users could customize header.tpl, use the existing USER_AGENT info passed to smarty, and call one or more different CSS files from there. (modular CSS would shine in this case).


In order for truly modular theming to work, a few prerequisites must also be met by the default templates:


This includes tables, which except in the case of tables that are absolutely required (which none really are). What the templates should do is provide containers in which to display the data.