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 {mailto} 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
    # except for form POSTS
    RewriteCond %{REQUEST_URI} !/$
    RewriteCond %{REQUEST_URI} !\.
    RewriteCond %{REQUEST_METHOD} !POST$
    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 CMS Made Simple Admin Console, 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.

A Private Page with Downloads for Logged In Users

If you want to have a private page containing downloadable documents that is only available to logged in users then you need 3 modules - Front End Users, Custom Content and Uploads. You should also create a directory, e.g. /uploads/privatedocs to store the documents and place an htaccess file in that directory that simply says "Deny from all".

In your page, or the template for the page, that will display the list of documents you should have something like this:

  { if $ccuser->loggedin() }
    {cms_module module="Uploads" category="mycategory" mode="summary" sortorder="date_desc" template="mytemplate"}
  {else}
    <p>This is a private area.</p>
    {cms_module module=FrontEndUsers form="login" nocaptcha="1" returnto="$page_alias"}
  {/if}

"if $ccuser->loggedin()" checks that the user is logged in. There are other options that allow you to check if the user is a member of a particular group, for example. Read the module documentation for more information.

"{cms_module module="Uploads" etc." displays a list of documents available to download. Read the module documentation for more information on the available parameters.

Only logged in users will see the list of files and the htaccess prevents people trying to go directly to the documents directory url via their web browser.

If you want to allow your authorised users to upload documents as well as download them you need another page with something like this:

  { if $ccuser->loggedin() }
    {cms_module module="Uploads" category="mycategory" mode="upload" noauthor="1" nocaptcha="1"}
  {else}
    <p>This is a private area.</p>
    {cms_module module=FrontEndUsers form="login" nocaptcha="1" returnto="$page_alias"}
  {/if}

Pretty URL's

CMS Made Simple 0.13 and higher come with support for Clean Hierachical URL's

Warning - the following .htaccess file contents may be outdated (and didn't work for me with SMSMS 1.6 - instead read this wiki page for Pretty URL instructions (which did work for me): User_Handbook/Tips_And_Tricks/Installation

Step 0 - Finish installation

If you are reading this, you may have missed the activation of the pretty URLs in the optional settings of the installation procedure.

Step 1 - .htaccess file

Create or modify an existing .htaccess file and add/replace with the following. Certain server configurations may require you to add 'RewriteBase /' after the 'RewriteEngine on' command. If your CMS Made Simple installation is in a subdirectory, you'll need to replace RewriteBase / with RewriteBase /cms/ (where /cms/ is the subdirectory name). Also make sure to check your FTP settings to transfer the file as Encoding: ASCII. (For those using Dreamweaver, you may have to use another FTP software.)

No file extension

This configuration will not show a file extension on page URLs. The URLs will look something like www.example.com/page1/, and if use_hierarchy is turned on, nested pages (subpages) will have URLs like www.example.com/page1/page11/)

  Options +FollowSymLinks
  RewriteEngine on
  RewriteBase /
 
  # 301 Redirect all requests that don't contain a dot or trailing slash to
  # include a trailing slash
  # except for form POSTS
  RewriteCond %{REQUEST_URI} !/$
  RewriteCond %{REQUEST_URI} !\.
  RewriteCond %{REQUEST_METHOD} !POST$
  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]

.htm page extension

This configuration will use a .htm extension for the pages. Pages will have URLs like www.example.com/page1.htm, and if use_hierarchy is turned on, nested pages (subpages) will have URLs like www.example.com/page1/page11.htm)

  Options +FollowSymLinks
  RewriteEngine on
  RewriteBase /
 
  # 301 Redirect all requests that don't contain a dot or trailing slash to
  # include a trailing slash
  # except for form POSTS
  # RewriteCond %{REQUEST_URI} !/$
  # RewriteCond %{REQUEST_URI} !\.
  # RewriteCond %{REQUEST_METHOD} !POST$
  # 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 ^(.+).htm$ index.php?page=$1 [QSA] 

Save the file and upload it to your site's root as '.htaccess' (no file extension!).

Note: if you are using the News module and want publish a rss feed than you will have the following problem if you use an extension. Normally your feed is available under http://host/News/rss but with mod_rewrite turned on the server will not find anything because http://host/News/rss is not rewritten to http://host/index.php?page=News/rss. You can solve the problem in two ways.

1. add an extra rule just before the first RewriteRule:

   RewriteRule ^News/rss(.+)$ index.php?page=News/rss$1 [S=1]

   This rewrites just the rss feeds to the thing you need. You can add extensions like .xml or .rss
2. use a more general rewrite rule:

   RewriteRule ^(.+)(.html)?$ index.php?page=$1 [QSA]

   Now all pages with or without extension .htm will work.

Step 2 - config.php changes

Now make the following changes to the "URL Settings" section of your config.php file.

Note: If you have already followed the Install Instructions to "set your config.php back to a read-only state" you may need to set it back to 666 or 777 temporarily in order to edit and save changes to config.php)

  #------------
  #URL Settings
  #------------

  #What type of URL rewriting should we be using for pretty URLs?  Valid options are:
  #'none', 'internal', and 'mod_rewrite'.  'internal' will not work with IIS some CGI
  #configurations. 'mod_rewrite' requires proper apache configuration, a valid
  #.htaccess file and most likely {metadata} in your page templates.  
  $config['url_rewriting'] = 'mod_rewrite';

  #Extension to use if you're using mod_rewrite for pretty URLs.
  $config['page_extension'] = '.html';  or some other extension, .php, .asp

  #If you're using the internal pretty url mechanism or mod_rewrite, would you like to
  #show urls in their hierarchy?  (ex. http://www.mysite.com/parent/parent/childpage)
  $config['use_hierarchy'] = true;

  #If using none of the above options, what should we be using for the query string
  #variable?  (ex. http://www.mysite.com/index.php?page=somecontent)
  $config['query_var'] = 'page';

If you're using the .htm page extensions, replace '/' above with '.htm'.

Step 3 - {metadata} plugin call

Add the {metadata} plugin call to the <head> section of your templates. This will automatically insert the base href tag to your site's root so that relative paths to files and images function as expected.

The use_hierarchy setting employed in the config file (see step 2) will convert nested page URLs to display in a heirachical manner (www.example.com/parent/child/ as opposed to www.example.com/child).

Don't worry about having to change any previously advertised URLs as both these forms will still work!

LightTPD configuration

If you are using LightTPD instead of Apache, the following configuration setting should work. This should go into your lighttpd.conf file.

  url.rewrite-final = (
    "^/(admin)/(.*)$" => "/$1/$2",
    "^/([^.?]*)$" => "/index.php?page=$1"
  )

Optional:

LightTPD configuration that works with and without trailing slashes (e.g. /admin will work) and supports /alias, /alias/, and /alias.htm for accessing pages

  url.rewrite-final = (
   "^/(admin.*)$" => "/$1",
   "^/(uploads.*)$" => "/$1",
   "^/([^.?]*)(\.htm)$" => "/index.php?page=$1",
   "^/([^.?]*)$" => "/index.php?page=$1"
  )

For new Lighttpd and Search module:

  url.rewrite-if-not-file = (
    "^/(admin)/(.*)$" => "/$1/$2",
    "^/([^.?]*)(\?(.*))?$" => "/index.php?page=$1&$3"
  )

For new IIS7+:

IIS 7+ (tested) configuration that works with and without trailing slashes (e.g. /admin will work) and supports /alias, /alias/, and /alias.htm for accessing pages. Note there is some examples of caching and securty but real it's just the <rewrite> area you'll really want. Just put a web.config at the root of the cmsms install when using php under IIS.

    <?xml version="1.0" encoding="UTF-8"?>
    <configuration>
    
        <configSections>
            <sectionGroup name="system.webServer">
                <sectionGroup name="rewrite">
                    <section name="rewriteMaps" overrideModeDefault="Allow" />
                    <section name="rules" overrideModeDefault="Allow" />
                </sectionGroup>
            </sectionGroup>
        </configSections>
    
        <system.webServer>
            <security>
                <!--  This section should be uncommented after
                installation to secure the installation. -->
                <!--
                <requestFiltering>
                    <denyUrlSequences>
                        <add sequence="engine" />
                        <add sequence="inc" />
                        <add sequence="info" />
                        <add sequence="module" />
                        <add sequence="profile" />
                        <add sequence="po" />
                        <add sequence="sh" />
                        <add sequence="theme" />
                        <add sequence="tpl(\.php" />
                        <add sequence="Root" />
                        <add sequence="Tag" />
                        <add sequence="Template" />
                        <add sequence="Repository" />
                        <add sequence="code-style" />
                    </denyUrlSequences>
                    <fileExtensions>
                        <add fileExtension=".sql" allowed="false" />
                        <add fileExtension=".pl" allowed="false" />
                    </fileExtensions>
                </requestFiltering>
                -->
            </security>
            <directoryBrowse enabled="true" />
        <caching>
                <profiles>
                    <add extension=".php" policy="DisableCache" kernelCachePolicy="DisableCache" />
                    <add extension=".html" policy="CacheForTimePeriod" kernelCachePolicy="CacheForTimePeriod" duration="14:00:00:00" />
                </profiles>
            </caching> 
            <rewrite>
                <rules>
                    <rule name="block favicon" stopProcessing="true">
                        <match url="favicon\.ico" />
                        <action type="CustomResponse" statusCode="404" subStatusCode="1" 
                            statusReason="The requested file favicon.ico was not found" 
                            statusDescription="The requested file favicon.ico was not found" />
                    </rule>
                    <rule name="Imported Rule 2" stopProcessing="true">
                        <match url="^(.*)$" ignoreCase="false" />
                        <conditions>
                            <add input="{REQUEST_FILENAME}" matchType="IsFile" ignoreCase="true" negate="true" />
                            <add input="{REQUEST_FILENAME}" matchType="IsDirectory" ignoreCase="true" negate="true" />
                <add input="{URL}" pattern="^/favicon.ico$" ignoreCase="false" negate="true" />
                        </conditions>
                        <action type="Rewrite" url="index.php?page={R:1}" appendQueryString="true" />
                    </rule>
                </rules>
            </rewrite>
            <defaultDocument>
                <files>
                    <remove value="index.php" />
                    <add value="index.php" />
                </files>
            </defaultDocument>
    
            <!-- HTTP Errors section should only be enabled if the "Error Pages"
            feature has been delegated as "Read/Write" at the Web Server level.        -->
               <httpErrors>
                   <remove statusCode="404" subStatusCode="-1" />
                   <error statusCode="404" prefixLanguageFilePath="" path="/index.php" responseMode="ExecuteURL" />
               </httpErrors>
    
    
        </system.webServer>
    </configuration> 

--jeremyBass 12:48, 31 October 2011 (PST)

Performance Testing

Performance testing is fraught with peril, as it's easy to come to incorrect conclusions. First, the test environment is difficult to control in any meaningful way unless you build a full physical network for testing. A lot of variables were not controlled in this test including: other network activity, other server processes, some other client processes, and so on.

Therefore, this set of results should be considered only in terms of order-of-magnitude numbers. As a general guideline, it may be useful. Don't expect that you'll get the exact same results.

Testing Methodology

The Codebase

This test was run against a specific CMS Made Simple site, built on CMS MS 1.0.2, with the standard modules plus FormBuilder, FrontEnd Users, CustomContent, and possibly a few other stray modules.

The Servers

This was tested on two different Virtual Host environments (labelled VPS 1 and VPS 2), as well as a server sitting on the local area network (labelled Server 1).

VPS 1

is running Debian stable. It has 138 MB of RAM, which is a hard limit. It's running Apache 1.3.33, MySQL 4.1.11, and PHP 4.3.10.

VPS 2

is running RedHat Fedora Core 4. It has 256 MB of RAM, which is burstable to 1 GB. It's running Apache 2.0.54, MySQL 4.1.20, PHP 5.0.4 with eAccelerator 0.9.5.

Server 1

is running RedHat Fedora Core 6. It has 2 GB of RAM. It's running Apache 2.2.3, MySQL 5.0.22, and PHP 5.1.6. When annotated Server 1 (1), it is running without eAccelerator. When it's annotated Server 1 (2), it's running with eAccelerator 0.9.5.

The Tests

Tests were run using Jakarta JMeter 2.2, running on a Windows XP box. Two pages were selected on the test site:

• page one contains a nearly straight-out-of-the-box CMS MS page, with the exception of containing a Front-end User sign-in box. CMS Made Simple reports this page as requiring 37 SQL queries.
• page two contains a Front-end User signin box and a FormBuilder Form containing 10 fields. CMS Made Simple reports this page as requiring 73 SQL queries (how's that for symmetry?).

Neither page was behind a login, tracked session data, or required reshipping of a cookie.

Each test below describes how many simultaneous threads were launched and how many times they repeated their requests.

Unfortunately, missing from this data is absolute time. Simultaneity is a somewhat artificial construct when the requests are all being generated by a single source computer. Still, this gives some idea of what heavy loading will do to a CMS MS site.

Some Conclusions

• CMS MS runs heavy loads better with more available memory. This is especially true when using eAccelerator (which is not surprising, as the basic premise there is trading memory for speed)
• CMS MS handles pretty decent loads, at least in the test configuration
• Sometimes an Apache child process will get swapped out. The request that that child is handling will take a long time to get back to the user.
• Still, no requests were completely dropped.
• Further tests would be interesting:
  • tests involving more pages on a given site
  • tests involving pages containing dynamic, module-created content
  • tests involving higher loads and/or shaped traffic

General Test

Test: 10 threads, each requesting two separate pages, repeating 10 times

(1) before install of eAccelerator

(2) after install of eAccelerator

Stress Test 1

Test: 55 threads, each requesting two separate pages, repeating 10 times

Stress Test 2

Test: 100 threads, each requesting two separate pages, repeating 10 times

Import Static HTML Content

Русская версия доступна здесь.

What Does This Do?

Import static HTML pages into CMS MS with media (images, objects) and styles.

How it work?

• Images relative path will set as URL absolute path in unique name directory in "uploads" directory.
• Scripts file path same way as image and included scripts all placed in Metadata page field.
• Style CSS files same way as image and content of <style> tag are placed in Metadata page field.

Just try some simple html files for testing and see what happend in Content->Pages.

How Do I Use It?

• Create or upload unique name directory in "uploads" directory.
• Upload there html files. It may contain html files, some media objects - pictures, flash, media, style files and java scripts with relative path like: <img src="images/mm_travel_photo.jpg" alt="Header image" width="382" height="127" border="0" /> or <script type="text/javascript" src="scripts/javascript.js"></script>
• Then set options, save it, set template for pages & it's parent and push OK button.

After job is completed you can must see messages with report wich files are add in or not.

If you have troubles.

Here some typical errors and it's solving.

• Be sure that static pages have same encoding as your CMS.
• Be sure that HTML is correct and valid!
• Be sure that static pages have not any conflict scripts (try Smarty tag literal), styles or tags in body section. I think Smarty tags are possible there, but try it on your own risk.
• If you set alias as file names be sure that you have not already same aliases!
• This module uses a built-in function for processing Cyrillic characters. So if you have troubles on this way try to solve global problem with Cyrillic support.

Some ThemeManager tips

When exporting a template and importing it, it also imports the pictures used in the template.

After importing a template, you need to make it active by going to "Layout » Templates" and under "Active" click on the red "X" so that new pages can be added using the templates.

Add Menu Item Subtext

Menu items in CMS Made Simple are, initially, limited to a single link with no option for secondary (non-linked) descriptive text. By modifying a couple files in your CMS Made Simple installation, you can have easily editable menu subtext:

• /lib/classes/contenttypes/Content.inc.php

Move the Title Attribute text field, located on line 244 (seen below), immediately under the Menu Text text field, located on line 200:

$ret[]= array(lang('titleattribute').':','<input type="text" name="titleattribute" maxlength="255" size="80" value="'.cms_htmlentities($this->mTitleAttribute).'" />');

Moving the Title Attribute text field places it on the Main tab of the Edit Content page, making it easier for users to locate and modify. The next modification will change the text field's label to better indicate its new use:

• /admin/lang/en_US/admin.inc.php

Edit line 438 (seen below):

$lang['admin']['titleattribute'] = 'Description (title attribute)';

To say:

$lang['admin']['titleattribute'] = 'Menu Subtext';

Now, users will know that they can add in additional descriptive text to their page's menu item by modifying the Menu Subtext text field.

To include the menu subtext in your menus, include {$node->titleattribute} in your menu's template wherever you want the descriptive text to be shown.

--MasterKale 12:53, 10 July 2007 (CDT)

Using CMSMS with CloudFlare

CloudFlare acts as an automatic Content Delivery Network for your website. It works by caching and serving your static content like images and stylesheets. In doing so it takes load off of your server, saves you bandwidth and speeds up your site as well. CloudFlare also protects your server by blocking threats and obfuscates email links to prevent spammers harvesting them.

The automatic part comes from redirecting all traffic through their servers by changing DNS settings. See the CloudFlare website for more information.

CMSMS works beautifully with CloudFlare however for the Admin panel to work correctly you have to use the extra subdomain which CloudFlare creates for such purposes. This section explains how to modify CMSMS to use this 'direct' subdomain as it's named by default.

By accessing your site through 'direct.mywebsite.org' you bypass the CloudFlare servers and get a direct connection (hence it's name) just as if you weren't using CloudFlare at all.

Changing config.php

The problem with the setting for the document root in the config.php file is that all pages visited from for example 'direct.mywebsite.org/admin/login.php' use this setting. The effect is that all subsequent pages don't have the 'direct' subdomain part in their URL. In other words they still are (partly) served by CloudFlare.

The solution is to make the document root setting respect the special CloudFlare subdomain 'direct'.

Change the document root setting like this:

  #Respect the special CloudFlare subdomain 'direct' (without it the admin
  #panel shows errors when using CloudFlare)
  if (strpos($_SERVER['HTTP_HOST'],'direct') !== FALSE) {
    $config['root_url'] = 'http://direct.mywebsite.org';
  }
  else {
    $config['root_url'] = 'http://www.mywebsite.org';
  }

In case of a subdomain the path setting is also required for the frontend. Make sure the path setting points to the subdomain directory and also disable mod_rewrite if you use pretty URLs. So as an example:

  #Respect the special CloudFlare subdomain 'direct' (without it the admin
  #panel shows errors when using CloudFlare)
  if (strpos($_SERVER['HTTP_HOST'],'direct') !== FALSE) {
    $config['root_url'] = 'http://direct.mywebsite.org/mysubdomain';
  }
  else {
    $config['root_url'] = 'http://mysubdomain.mywebsite.org';
  }

and (only when using pretty URLs):

  #Disable URL rewriting for this subdomain when using the special CloudFlare subdomain 'direct'
  if (strpos($_SERVER['HTTP_HOST'],'direct') !== FALSE) {
    $config['url_rewriting'] = 'none';
  }
  else {
    $config['url_rewriting'] = 'mod_rewrite';
  }

Adding a special UDT

To prevent search engines indexing your pages when accessed via 'direct.mywebsite.org' you can create a UDT like 'robots_meta_tags' and include "{robots_meta_tags}" in the head section of your template(s).

Use this code for such a UDT:

  // Prevent search engines to index the site when it was accessed through the
  // special CloudFlare 'direct' subdomain
  if (strpos($_SERVER['HTTP_HOST'],'direct') !== FALSE) {
    echo '<meta name="robots" content="noindex, nofollow">';
  }
  else {
    echo '<meta name="robots" content="index, follow">';
  }

This page in: English - Deutsch - Español - Français - Italiano - Lietuvių - Nederlands - Norsk - Polski - Česky - Русский - Svenska - Tiếng Việt - عربي - 日本語 简体中文

User Handbook/Tips And Tricks

From CMSMS