Welcome to CMS Made Simple

This page in: English - Deutsch - Français - Svenska - Русский - Norsk - Polski - Nederlands - Español - Lietuvių

Tips and Tricks

The default installation of CMS Made Simple comes with a standard set of templates and functionality.

This section collects some common tips to help you modify this installation to better suit your website.

See also the Frequently Asked Questions for more useful tips and tricks - the Pretty URLs article was moved to there.

Protecting Email Links From Spam (mailto)

Email addresses in your web pages can be harvested by spammers. Here's a handy Smarty trick to encode email addresses so they display and function normally in a browser, but can't easily be seen by an automated system scanning for them. This technique is sometimes referred to as "email obfuscation."

Instead of directly adding the email link in html as <a href="mailto:me@example.com">, use the Smarty {maito} tag to encode the email address:

{mailto address="me@example.com" encode="javascript"}

The {mailto} tag will automatically encode the email address into Javascript, hex or other format, concealing it from spam harvesters. The above tag is encoded to:

<script>
   eval(unescape('%64%6f% ... snipped ...%61%3e%27%29%3b'))
</script>

The {mailto} tag supports parameters that allow you to specify the encoding method, text to display for the email link, email subject line, additional recipients and more. See details on the Smarty {mailto} function at the Smarty website.

LDAP Integration

Although CMSms has its own users/groups management, authentication and authorization features, some users may want to rely on an existing users database stored in an LDAP directory. CMSms (v1.0.4) has not yet a builtin option to be integrated with an LDAP directory. But some users have published tips to achieve it and they have testify it is working in production environnements today.

To read some background information about this subject, please browse the first forum LDAP thread. To actually integrate your CMSms with your LDAP directory, browse the forum tip thread.

Protecting against viewing of folder contents

If you are using Apache web server (and I suspect it is the same with others), when someone goes to www.yourwebsite.com/somefolder/, he (or she) will see contents of that folder, which is nice... if you had FTP server, and that was supposed to happen. The quick'n'dirty solution for this is placing simple index.html file into these folders, with some warning message; your files will still be accessible from web pages, and the smart one who wanted to leech out files will be stopped, seeing that warning... and possibly quit.

Note: This is not the safest way of dealing with that matter, but it is quickest.

Another option is through your .htaccess, or httpd.conf file

To protect your current folder via the .htaccess method. Edit or create an .htaccess file and add:

#option to remove directory listings in this folder

Options -Indexes

What this will do is prevent directory listings of files in this directory but will still allow viewing the index.php, index.html file (page) if it actually exists in the directory. You can also make this global for your entire web site by adding this line in the .htaccess file in your web sites root directory. This same method also applies to httpd.conf files.

Custom Error Messages for Errors 401, 403, and 404

Since it's common for a web server to have aliases and virtual hosts, in some cases, it might be better to have the web server provide error documents rather than the cms. By having the web server handle errors, consistent error pages can be served regardless of which alias or virtual host might have been requested and causing the error.

Thus, a combination of apache's ErrorDocument handler and cmsms's Page content can be used to provide a consistent means of serving error pages. Only error pages for 401, 403 and 404 were setup, but this process can easily be extended to any number of error messages. And considering how this might work in a shared hosting environment, apache configurations _should_ be able to be added to an .htaccess file instead of directly in the apache.conf.

This process was tested under a stock install of CentOS 5 x86_64, and at the time of this writing, the current version of CentOS 5 is 5.1. Apache was not configured with virtual hosts, but did have several aliases.

1.) First step is to setup PrettyURLs using mod_rewrite as detailed in the CMSMS FAQ. Specifically, in the cmsms config.php, set the following:

$config['assume_mod_rewrite'] = true;
$config['page_extension'] = '.html';
$config['internal_pretty_urls'] = false;
$config['use_hierarchy'] = true;  //optional

2.) Next, edit apache.conf and specify:

<Directory "/path/to/your/cmsms">
        Options -Indexes +FollowSymLinks
        Order allow,deny
        Allow from All
        RewriteEngine on

        # 301 Redirect all requests that don't contain a dot or trailing slash to
        # include a trailing slash
        RewriteCond %{REQUEST_URI} !/$
        RewriteCond %{REQUEST_URI} !\.
        RewriteRule ^(.*) %{REQUEST_URI}/ [R=301,L]

        # Rewrites urls in the form of /parent/child/
        # but only rewrites if the requested URL is not a file or directory
        RewriteCond %{REQUEST_FILENAME} !-f
        RewriteCond %{REQUEST_FILENAME} !-d
        RewriteRule ^(.+)$ index.php?page=$1 [QSA]
</Directory>

Note: The base cmsms directory was specified as the DocumentRoot, so any other related directive in apache.conf was updated accordingly.

Also in apache.conf, define error pages:

ErrorDocument 401 /error-401.html
ErrorDocument 403 /error-403.html
ErrorDocument 404 /error-404.html

3.) In CMSMS Admin Panel, create error pages:

e.g.

Error 401 Error Page

 Main tab
   content type:	Content
   title:		Error 401
   menu text:		Error 401
   parent:		None
   template:		Whatever your default template is
   content:		Your custom error message

 Options tab
   Active: checked
   Show in Menu: unchecked
   Cachable: unchecked
   Page Alias: error-401

Create other error pages similarly.

4.) Restart apache and test.

With PrettyURLs enabled using mod_rewrite as detailed above, you should now be able to access http://www.yourdomain.com/error-401.html. Likewise, apache can now redirect any 401 errors it detects to this error page, regardless of which alias or virtual host was requested.

Since this process wasn't tested in a shared hosting environment, your mileage may vary.