This action might not be possible to undo. Are you sure you want to continue?
All too often, content management systems (CMS’s) make it difﬁcult to adapt designs to its template system. Designers are bogged down with ﬁtting 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.
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 localhost conﬁguration, however, site administrators will ﬁnd these instructions useful for installing the program on a remotely hosted server. 1. Unzip the cms-x.x.zip ﬁle 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 ﬁle in MySQL to create the necessary tables. 3. Edit the database ﬁles to include your MySQL connection preferences. The following ﬁles will require updating: /localhost/cms/db.php /localhost/cms/admin/app/conﬁg/core.php /localhost/cms/admin/app/conﬁg/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 ﬁles, 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 ﬁle.
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: 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 explanations 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 created 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 ﬁnal 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 ﬁeld will be how the page is called. A page with no label and “junk” entered in the URL ﬁeld 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 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 ﬁt your site). or,
DISTRIBUTED USER MANAGEMENT
Davidicus supports multiple content editors and administrators. Users are added and modiﬁed 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 username 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 “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 anything 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
This action might not be possible to undo. Are you sure you want to continue?
We've moved you to where you read on your other device.
Get the full title to continue reading from where you left off, or restart the preview.