Archive for March, 2007

Creating Theme Support for Our CMS

March 04, 07 by kenrich

I am trying to develop a themes module for my new PHP intranet that will allow me to easily install themes. I plan to create an update site which holds all of the available themes. Each theme will be identified by an XML descriptor file which contains all of the properties for the theme. On the update site, a service will scan all of the folders on the site and parse all of the XML descriptor files. The theme information will then be collected and summarized then stored in a global themes file. This way, when someone does an update, they can just retrieve one file from the update server to build a list of available themes to download.

I’m thinking of having two different types of themes. One set of themes will be for the public site while the other will be strictly for the control panel. Users are free to mix and match themes so that the theme for the public site doesn’t need to match the one used on the control panel. Although they share a lot of the same components, it’s better to keep them separate so there is no confusion over what elements are specific to the public and which elements are specific to the control panel (and which elements are shared by both.)

Another feature I would like to have is the ability to customize a theme. So if a user doesn’t like one particular aspect of the theme, they can use a web-based theme editor to tweak the parts that they wish to improve. This should provide maximum flexibility when working with themes. I’m really hoping to get the theme support done quickly so I can open up the demo site to everyone.

Configuration Settings on a CMS

March 01, 07 by kenrich

I’m in the process of developing the next generation Orvado Intranet application. Technically, it’s a which will be used to build and manage very dynamic websites. I have designed a database for universal configuration settings which can be used across all modules but now I need to determine how the settings will be accessed.

In the past I’ve used a system where the settings would be accessible from each page of the control panel. This makes the settings easily accessible and relevant to the current section you are in. The only problem with this setup is that you don’t see all of the configuration settings in one place.

We could put all of the settings for each module in one common area. However, this would require that users navigate away from the section they are currently in to make changes. Then, once their changes are complete, they would have to navigate back to the section they came from. Not the ideal situation.

Another issue I’d like to address is having global settings for the entire site. These are settings that are not specific to on specific module or feature on the site. Usually, I’d put these settings on the home page of the control panel or in a special Configuration area of the site.

I think I’ll put the settings in both areas. Make all of the configuration settings accessible from a centralized location and also make module-specific settings appear in their related sections. This should provide the best of both worlds and (hopefully) won’t be too confusing for the operators.