Can I improve my module-skin architecture somehow?


I’m designing a CMS for a private project that should make the editing of the website simple. It supports modularism. However, it’s still in beta, and I’m now asking if you can see something I could improve or if you have some entirely different approaches to this scenario.

First of all, I have “themes” that are a set of HTML, CSS and maybe JS. Each theme can contain different styles that are each in separate files (like full-width.html, fluid.html, etc). Then the admin can choose a different style for different pages. Some pages have only 1 column, some have sidebars, etc.

Current the way it works is that a style HTML looks like:

<div id="header">{block id="header"}</div>
{blocks id="list"}



The theme creator can place “blocks” which define where the admin can place modules. These modules can be just text, or contain more complex HTML like a shoutbox or a login form. Anyway, the blocks must all have ID’s except for those that are inside another block. This way, when the admin decides where to place modules, he will get a form like:

Header module: --select--
 List modules:
     --select-- (automatically adds new selects as needed)

Where --select-- is a HTML select box containing all installed modules. The ID is used to make it easier for admin to understand where the selected module goes on the site without having to save changes and preview.

The theme creator is capable of placing multiple blocks with {blocks} tag. It means that the admin can place several modules within it, like in Wordpress you can have “tags”, “login”, “affiliates”, etc lots of modules on the sidebar. The amount of modules can be restricted with {blocks limit=“5”}. I could have some other settings, too.

If the block is specified on the page as {block id=“header”} then it means the contents of the chosen module for the block will be substituted into it. However, if it’s {block}{/block}, then the theme creator has to use {content} somewhere in between the tags to specify the place for the content. He can also use {name} to specify the module’s name, etc.

In overall, are there some improvements I could do on this? Do you have any suggestions?

And most importantly, am I trying to redesign an already existing mighty modular system that I should use instead?