DAVIDICUS CMS QUICK START GUIDE

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:

http://www.site.com/index.php?id=567

Things have gotten better with URIs like this:

http://www.site.com/id/567

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

http://www.site.com/news/headlines

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.

INSTALLATION
Davidicus runs using the CakePHP framework and PHP/MySQL. Before installing Davidicus, you will need to download the CakePHP
libraries folder from http://www.cakephp.org. 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 cms-x.x.zip file and place its contents in your localhost root folder along with the Cake libraries folder. You should have
the following directory structure:

/localhost
/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:

/localhost/cms/db.php
/localhost/cms/admin/app/config/core.php
/localhost/cms/admin/app/config/database.php

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

/localhost/cms/admin/app/tmp
/localhost/cms/images

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]

STRUCTURE
Davidicus uses four main elements to assemble dynamic web content:

Layouts
Nodes
Mods
Pages

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.

Layouts

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).

Nodes

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

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.

Pages

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:

http://localhost/cms/junk

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

http://localhost/cms/trashcan/junk

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:

http://localhost/cms/ or,
 http://localhost/cms/index

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

http://localhost/cms/news or,

http://localhost/cms/news/index

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).

DISTRIBUTED USER MANAGEMENT

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 “blogmania.com” 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:

http://www.cakeforge.org/projects/davidicus

--David Golding