You are on page 1of 5



All too often, content management systems (CMS’s) make it difficult to adapt designs to its template system. Designers are bogged

down with fitting their customized designs to the feature-laden CMS and nearly have to learn a new language (certainly a new API) to get it off the ground.

Another problem with today’s CMS’s is URIs. URI strings from yesteryear would go something like this:

Things have gotten better with URIs like this:

But what about customizing URIs in the CMS? Maybe something like:

With Davidicus CMS, site administrators and web designers can implement their designs with ease. Flexible and database-driven, Davidicus can render any design across multiple pages so administrators don’t have to propagate changes via hundreds of static

HTML pages. And any linking structure is possible by creating unique URLs and content labels.


Davidicus runs using the CakePHP framework and PHP/MySQL. Before installing Davidicus, you will need to download the CakePHP

libraries folder from Davidicus uses Cake version 1.1. It is recommended that you are familiar with PHP/ MySQL and semi-familiar with CakePHP to ensure an easy installation. The installation procedure outlined here is meant for a local- host configuration, however, site administrators will find these instructions useful for installing the program on a remotely hosted server.

1. Unzip the file and place its contents in your localhost root folder along with the Cake libraries folder. You should have

the following directory structure:


/cms /cake

2. Run the cms/database.sql file in MySQL to create the necessary tables.

3. Edit the database files to include your MySQL connection preferences. The following files will require updating:




4. Set permissions for the following folders using “chmod 777” (readable/writeable):



5. By default, the administrator account is stored in the “users” table in the database. You can change the name and password there if

you’d like. Otherwise, log in using “admin” for both the username and password. You can now begin creating content for the web site!

Important: you shouldn’t have to modify any of the .htaccess files, but if you have renamed the “cms” folder to something else, or are experiencing redirects to the cms folder, you should only have to change one line in one .htaccess file.

cms > .htaccess

Change line 6 from:

RewriteRule ^(.*)$ /cms/index.php/$1 [L]

To the root folder, etc., for example:

RewriteRule ^(.*)$ /public_html/index.php/$1 [L]


Davidicus uses four main elements to assemble dynamic web content:





The main object of this structure is, as much as possible, allow for any duplicated content to be managed in one place only. In the event of modifying content, such changes should occur in only one place, thus streamlining web site editing. Below are some expla-

nations about each element and what it accomplishes in the management structure.


Each layout is the main content for the site that contains the most common elements. In other words, it’s like the main template for web pages. A site can have as many layouts as desired. Each layout has two pieces: headcontent and footcontent. The content cre- ated in the pages will be sandwiched between the headcontent and footcontent of the layout. Nodes and mods may be called in the

layouts as well (see Nodes and Mods below).


These are typically small chunks of HTML, like a menu bar or a calendar, that are repeated over various layouts or pages. A node may contain any HTML and can be called anywhere in the site by using the tag <node>node_name</node>. Davidicus replaces the tag, wherever it appears in the layout or page, with the content provided in the node entry in the database.


Mods behave exactly like nodes, except they are chunks of PHP code instead of HTML markup. You can run any PHP script here, as long as the final output is returned (not “echo” or “print”). Your script also should not include the PHP opening and closing strings “<? php” and “?>”. Mods can be called anywhere in the site (layouts or pages) by using the <mod>mod_name</mod> tag.


The most unique content should be created in the individual pages. Each page has a unique URL and can go two levels from the

home page of the site. For example, when creating a new page or editing an old one, you can specify a URL and/or a label. If the label

is left blank, whatever is entered in the URL field will be how the page is called. A page with no label and “junk” entered in the URL

field would be accessible by going to:


A page with the label “trashcan” and the URL “junk” will be accessible via:


Pages with URLs of “index” become the home page for labels and as such, the word “index” may be left out of the URL. For example,

a page with no label and a URL of “index” is the home page of the entire web site and would be accessible at:




A page with the label “news” and the URL “index” would be accessible at:




Davidicus checks to ensure that no two pages have the same URL structure, as each page must have a unique URL string. For the time being, Davidicus only supports two levels beyond the root URL (in our case, we’ve been using “http://localhost/cms/” as the root, but this can be changed to fit your site).


Davidicus supports multiple content editors and administrators. Users are added and modified by clicking the “Users” link at the top

menu. The passwords are stored in plainview for the superuser, whoever that may be, for better access. Each user is given a user- name to log in with (“name”), a privilege, and related labels.

By default, the “administrator” privilege is the superuser, making it possible for the user to access every feature of the CMS. If this option is set, the user will be able to edit and access everything, regardless of the other restrictions that may be selected. You can create other privileges that restrict which elements of the page the user can edit by going to the “privileges” link at the top.

Related labels restrict which content the user can edit. For example, if only “news” and “posts” are selected, then the user can only edit pages that have “news” and “posts” for their label.

For example, let’s say the web site “” will be edited by multiple editors throughout the world. The site administrator wants to set up for one editor access to posts related to “medicine” and another editor he wants to grant access to posts related to “sports.” He would select under related labels for the one just the option “medicine” and “sports” for the other. Let’s say that the

medicine editor is a close friend of the administrator whom he can trust. So under “privileges” he creates a new privilege called “friend” that can edit the URL but not the label. For the sports editor, he creates a privilege called “editor” that restricts editing any- thing but the description meta tag, the keywords meta tag, and the page content. When the respective users log in, they will only see pages that are found with their respective labels, and will only be able to edit the elements that the administrator has granted them.

I’ll be adding more to this guide. For the time being, please give Davidicus a look, and respond with any suggestions or feedback on CakeForge:

--David Golding