Composr Tutorial: Webhosting for Composr

Written by Chris Graham (ocProducts)
To put a website on-to the Internet, you need to arrange for 'webhosting'. This is usually done by paying for the services of a webhost , who will provide you space-on and access-to, a computer (a web server) that is permanently connected to the Internet via a high-speed connection.

This tutorial covers requirements for hosting Composr and some general information about webhosting and security.

This tutorial goes into great detail of all the low-level requirements (much of which you may not understand), and different environments to install on. Practically speaking almost any "PHP hosting" will run Composr, so long as it's not free ad-supported hosting. The verbosity of this tutorial is so that we can be really comprehensive. A simpler list is shown on the Composr download page.

Different hosting options

You have the following options for hosting Composr (roughly):
  • Traditional shared webhosting (with a control panel)
  • Traditional VPS webhosting (with a control panel)
  • Traditional VPS webhosting (without a control panel)
  • Dedicated Linux server (with a control panel)
  • Dedicated Linux server (without a control panel)
  • Hosting on your own Windows desktop (for development purposes)
  • Hosting on a Windows server
  • Hosting on your own Mac desktop (for development purposes)
  • IaaS cloud hosting (e.g. Amazon EC2, Azure, Rackspace)
  • PaaS cloud hosting (e.g. AppFog, Heroku, Rackspace Cloud, Engine Yard, OpenShift)
  • Google App Engine, which is a special case of PaaS due to the high-level of organisation you need to work within. It is covered in its own tutorial.

The vast majority of users will choose traditional shared webhosting, or traditional VPS webhosting with a control panel.

Users with high requirements for CPU, memory, security, privacy, autonomy or disk space, may opt to get a dedicated server . This is more expensive, and usually requires additional maintenance by the user, but for some users, is highly advisable.

Programmers will often prefer IaaS and PaaS hosting in order to get scalability. However scalability is not automatic with any system, so programmers need to put serious consideration into infrastructure. This is discussed more in the Optimising Performance tutorial.

Regardless of your choice, you'll always be running the same underlying software (PHP etc). For the purpose of this tutorial the differences don't really matter, except where we provide specific advice on configuring platforms.
We have various different installation tutorials that go into details on how to install on the different hosting options.

Recommended shared webhost

We don't currently recommend any particular webhosts because it is a tricky thing. I'm afraid the answer will be rather cynical, but I want you to get a realistic outlook.

Webhosts have a tendency to take a turn for the worse at some point, as it's a race-to-the-bottom kind of industry – any ones built on a good reputation tend to get taken over when the founders cash-out and then milked for it by a new team.

We advise picking your own webhost based on good reviews that are both recent and credible. Actively look for people complaining about the company to get a sense for whether these complaints are reveal a pattern of genuine concern (as opposed to general frustration with technology / unreasonable expectations from the webhost). Don't pick the cheapest, but also don't assume paying more guarantees good service.

Webhosts generally fit into 3 categories:
  1. Good infrastructure, good support (pick a company like this, but it usually doesn't last long – they're likely either losing money, or propped up by a passionate underpaid founding team who won't be there forever)
  2. Good infrastructure, poor support (stick with a company like this because it's probably not worth the hassle to move)
  3. Poor infrastructure, poor support (this is when you leave to a company in state '1')

Keep making sure you have your own backups so that you are able to always make a swift move if it becomes necessary.

Requirements and recommendations

When choosing a webhost, you need to make sure that they meet all the requirements of Composr. Composr is intentionally designed to have very low requirements, but like when making virtually any choice in life, there are various different kinds of product that companies may try and sell.
If a random commercial PHP /MySQL -supporting webhost was chosen, it is very likely that they would support these requirements: however the developers cannot be held accountable for incompatibilities with systems that do not.

The remainder of this section details Composr's requirements. If you have trouble ascertaining a webhosts compliance, you may wish to contact them with this information.

Composr requires:
  • A web server that runs PHP. PHP is software which provides the environment that Composr is written for. Composr requires PHP version 5.1 or higher. If a webhost has a PHP version older than this, it is not just out-dated, but also insecure: no competent webhosts still do (at the time of writing, anything less than PHP 5.5 is unsupported by the PHP developers)
    • If you are using PHP 5.2.0 or lower then PHP must have been compiled with --enable-memory-limit
    • If you intend to use WebDAV, PHP 5.3 or higher is required
    • Other non-bundled addons may have different dependencies
    • If you install with PHP 5.5 or newer, you may not then down-grade to anything older than PHP 5.5 (as Composr will have already made use of PHP 5.5's password security features for saved passwords)

Easy-reference summary of the key hosting recommendations.

Easy-reference summary of the key hosting recommendations.

(Click to enlarge)

  • A PHP environment with the following (a competent webhost geared towards running PHP web applications should be able to provide this):
    • GD2 extension (including PNG and JPEG support). GD is used by PHP for image generation, e.g. to generate thumbnails.
    • file uploads with at least 5MB (or higher, depending on your particular needs)
    • MySQL extension (mysql or mysqli or pdo_mysql) [MySQL Native Driver being enabled or not is not a factor]
    • a maximum execution time of at least 30 seconds
    • max_input_vars of at least 2000 (most hosts let you raise the setting)
    • key functions may not be disabled with disable_functions (PHP can be stripped down heavily by disreputable webhosts) – the installer will warn if any critical functions have been
    • no other explicit disabling of standard functionality that we require. Commonly webhosts do this using ModSecurity, Suhosin, suPHP or their own modified PHP versions. We do our best to workaround such issues for common recoverable cases, but ultimately if arbitrary standard functionality has been disabled the software cannot function.
    • memory limit of at least 32MB (bare minimum – you may see errors if caches are disabled, while caches fill, if you are doing imports, if you are doing Admin Zone searches, or if you are a programmer with dev mode on).
  • At least 50MB of disk space, plus your needs for space for downloads, images, etc. No maximum file size limit under 25MB or file type whitelists (some free webhosts will impose these limits – which explains why data.cms might disappear when you try to upload it)
  • A web server that runs MySQL (*), version 5.5.3 (†) or higher:
      • MySQL is the database software (software which allows creation of a number of separate databases) which Composr uses to store the majority of its data.
      • Often webhosts will quote a number of databases that webhosting comes with: Composr only requires a single MySQL database to function. At least 5MB of database storage space is required, which should be available on any reputable webhost.
      • The max_allowed_packet server system setting must be at least 16M.
  • A web server running Apache (the common Linux web server) or IIS7+ (the Microsoft web server). It is very unlikely you will find a webhost that provides something else. Other servers might work but are not supported (additional guidance is provided in this tutorial)
    • If running Windows, you should use an NTFS partition not a FAT32 partition, as FAT32 cannot support file locking
    • If running Apache using a mod_php (as opposed to a CGI version of PHP), the server configuration needs to have AllowOverride All or at least AllowOverride Options FileInfo Limit (because we use distributed .htaccess files containing settings to increase security)
    • If you want URL Schemes on Apache, mod_rewrite must be enabled
  • The CGI timeout on the server must not be lower than 60 seconds (which is the default on Apache)
  • That the web server is not overloaded with too many users, or has very poor performance
  • That the web server does not have a Firewall that stops outgoing connections or internal connections to itself (sometimes referred to 'HTTP loopback') – this applies to both TCP port 80 and 443
  • Connectivity to a mail server (SMTP) so that outgoing e-mail can be sent out to the staff e-mail address or the addresses of individual members
  • The install path does not contain the text "_custom" in it
  • Either a suEXEC-style server or a working FTP connection from PHP back to the hosting
  • If you are running on Windows, and a PHP version below 7.2, and are using non-latin characters in codenames, you need to install the transliteration addon (basically due to a PHP bug reading and write non-latin filenames)
  • The web server may be running Windows, Linux, or MacOS – other operating systems such as Solaris or OpenBSD are not officially supported, although bug fixes may be made
(*) Other database software may work, but is not supported. MariaDB should work as a drop-in MySQL replacement but we do not proactively test against it. Certain permissions are required as described in the Basic Installation tutorial.
(†) MySQL 5.5.3 introduces the utf8mb4 character set, which is required to store emojis. The installer assumes you will install with this support available, but upgrades from older versions may work in anything from MySQL 4.1+ if the database is kept in latin1 via having $SITE_INFO['database_charset'] = 'latin1'; in _config.php. This compatibility will not be guaranteed, but as webhosts have been very slow to upgrade MySQL installations we will informally try and maintain it.

Composr recommends:
  • A PHP versions that hasn't reached end-of-life status
  • A PHP environment with the following PHP extensions/build-options and matching system software:
    • FTP †
    • EXIF
    • pSpell or Enchant, with matching aspell/hunspell installs and dictionaries (spellchecking)
    • iconv or mbstring (Unicode support)
    • intl (Strong transliteration of non-European languages for quality URL moniker generation)
    • FreeType (with the build-option for GD). FreeType allows us to draw text onto graphics using TrueType fonts.
    • OpenSSL (raises security, strongly recommended)
    • ZIP
    • XML
    • cURL
    • APC (PHP 5.6 or lower only), or Memcache, or Memcached, or Wincache, or eAccelerator (PHP 5.4 and lower only)
  • A PHP environment with Safe Mode disabled, but open_basedir enabled – or a suEXEC/IIS server (explained further down)
  • A PHP memory limit of 64MB
  • At least 100MB of disk space
  • Generally, if you are using shared web hosting then we advise picking a host that does nightly backups that you have access to restore – we've seen a lot of web hosts not take any responsibility for backup, and it does need doing at the server level to work effectively
  • If running Apache, the following Apache modules (for maximum performance): mod_headers, mod_setenvif, mod_env, mod_deflate, mod_filter

† If you do not have the PHP FTP extension, then you will need either:
  1. an environment where the web server user has recursive write access over the web directories (most Windows servers)
  2. an environment where the web server user is the same as the virtual hosting login user (suEXEC)

Requirements for specific features

If you want automatic thumbnail generation and transcoding you need a server with FFMPEG on it. It must be accessible via PHP either via the PHP extension (thumbnails only, not transcoding), or the ability for shell_exec to run from PHP (both thumbnails and transcoding).
It is best, however, to transcode manually offline/off-server to avoid resource over-use.

Do not try and install Composr on an ad-sponsored free webhost. The banners and tracking they inject will interfere with the mechanisms of Composr.

If LDAP integration is required (for corporate network authentication integration), the PHP LDAP extension is required.

If you need to be able to easily remove 'bounce' e-mails from newsletter subscriber lists, you will need the PHP IMAP extension. If your IMAP server requires SSL (like gmail) then you will need to have IMAP-SSL support inside PHP (or you will get "invalid remote specification" errors).

If encrypted CPFs (custom profile fields) are needed (see the Advanced Composr member system tutorial), or Composr-fed DKIM, the PHP OpenSSL extension is required.

Package installation (advanced)

This section contains some suggestions for which packages to install on different Linux distributions to get a good PHP environment. It is only applicable to people who aren't on traditional hosting with a control panel to manage things from.

This section is not actively maintained. Package names may change, but it is designed to give a leg-up to people configuring new Linux servers.


Code (Bash)

apt-get install apache2 libapache2-mod-php5 php5 php5-common php5-cli php5-apcu php5-curl php5-enchant php5-ffmpeg php5-gd php5-imap php5-mysqlnd php5-pspell openssl mysql-server mysql-client postfix nano wget lynx hunspell git openssh-server nano wget iostat

Some lines in the default PHP ini (/etc/php5/apache2/php.ini) file need changing:
upload_max_filesize = 2Mupload_max_filesize = 500M
post_max_size = 8Mpost_max_size = 500M
;date.timezone = date.timezone = "UTC" (to avoid errors on PHP startup)
; extension_dir = "./"extension_dir = "usr/lib/php5/20121212"

(the extension_dir may actually be different on different versions, so check that)


You may need to setup the EPEL repository first.

Code (Bash)

yum install httpd mod_ssl mod_fcgid php php-common php-cli php-pecl-apc php-pdo curl enchant freetype gd php-gd php-imap php-mysqlnd php-mbstring php-pspell php-xml openssl mysql-server mysql sendmail nano wget lynx hunspell git openssh-server aspell aspell-en nano wget iotop hunspell-en screen unzip

You may have selinux installed, you can see if you do with sestatus:
[root@localhost html]# sestatus
SELinux status:                 enabled
SELinuxfs mount:                /sys/fs/selinux
SELinux root directory:         /etc/selinux
Loaded policy name:             targeted
Current mode:                   enforcing
Mode from config file:          enforcing
Policy MLS status:              enabled
Policy deny_unknown status:     allowed
Max kernel policy version:      28

If so, you need to set additional write permissions with something like:
chcon -R -t httpd_sys_rw_content_t /var/www

You may also want to include yum-cron (or whatever it is now) in there, for automatic system updates (who has time to stay on top of all server software for urgent security patches?).

Some lines in the default PHP ini (/etc/php.ini) file need changing:
upload_max_filesize = 2Mupload_max_filesize = 500M
post_max_size = 8Mpost_max_size = 500M
;date.timezone = date.timezone = "UTC" (to avoid errors on PHP startup)

Web server compatibility

Composr is only tested on, and optimised for, Apache and IIS.
However in principle it should work on any web server software.

There are a few notes to give, although the only one of likely major significance is the URL Schemes one..

Note Apache-approach IIS-approach Comments
URL Schemes recommended.htaccess file web.config file If URL Schemes are desired then Rewrite rules will need manually writing for other servers, which will require expertise
Gzip/caching optimisation rules themes/*/templates_cached/.htaccess, uploads/.htaccess, recommended.htaccess None For other servers just manually configure your preferred rules as desired
PHP base-line configuration recommended.htaccess file (for PHP-module installations only) None Default configuration is usually okay, but sample .ini-based configuration is provided in the FAQ
404 error configuration recommended.htaccess file web.config file For other servers just manually configure if routing to Composr's 404 page is desired
Efficient IP bans Written into .htaccess file None For non-Apache servers bans are enforced only within Composr's bootstrapping process (a little slower); bans may be manually added to web server configuration as desired
Disabling PHP in certain directories .htaccess files strewn around No default support This is an extra layer of security but is not required because Composr prohibits the upload of .php files by users and white-lists accepted file-types
Disabling URL access in certain directories .htaccess files strewn around web.config file This is an extra layer of security but is not required because executable PHP files that are not meant to be executed don't have any code that would activate by URL, and private files are protected by filename randomisation
Disabling unauthorised log file downloading data_custom/.htaccess file web.config file The Composr error log is the only log that exists, and download is protected as it is a .php file; if additional logs are created manually then the web server should be hand configured to prohibit direct access
failover_apache_rewritemap_file option Supported None Fail-over mode can work for Apache users without PHP even working, if this particular configuration is carefully implemented; this is not a feature supported on any other web server
MATURITY_FILTER_REQUESTED symbol Supported (for PHP-module installations only) No default support As documented in the Tempcode programming tutorial, there is a workaround for configuring other servers
Documentation Provided Provided While documentation is written with respect to Apache and IIS, concepts can be adapted by experienced users
Workarounds to quirks Implemented Implemented Quirks present in Apache and IIS are worked around where required (such as ModSecurity, or maximum cookie size); it is not expected significant quirks will exist in other servers that can't be resolved by configuring of said servers

In terms of operating system support, Composr is only tested on, and optimised for, Windows, Mac, and Linux. It may work on other operating systems supporting by PHP, such as BSD variants – so long as they are Unix-like.

Forum drivers (advanced)

If you wish to integrate an existing forum into Composr, rather than use our own, the forum must be one of:
  • Advanced Electron Forum 1
  • Invision Board 1.1-1.3/2.0-2.3
  • phpBB 2.0-3.0
  • myBB 1.4
  • vBulletin 2.2/3.0-3.7
  • Burning Board 2.0/2.2/Lite
  • Simple Machine Forum 1.0/1.1
  • WowBB 1.7
If your forum is not on the list, professional developers are available to add support.

Please note that many 'forum systems' are referred to as 'bulletin boards', and that a 'forum' within 'forums' is often referred to as a 'board'. We consistently use the terms 'discussion forums', 'forums' and 'forum' to describe these.

We also provide converters for most of the above to our forum system, Conversr. If you currently use one of these systems, you have the option to convert it.

Configurability of linked forums

Instead of naming the forum "Website comment topics" or "Website Support Tickets", you could name it "Mysite comment hub", "Mysite help region", or anything else you choose. Just be sure to change the configuration option to reflect it.

This is in the "Support Tickets" and "User interaction" groups of the "Feature Options" configuration category. Find this under Admin Zone > Setup > Configuration.

If you have installed forums, you will likely wish to create a comments forum. To do this, create a non-public forum called 'Website comment topics'. This forum will be used to store topics relating to comments for content in your portal.

You may also wish to create a non-public forum called 'Website support tickets' if you wish to enable the support ticket feature.

Configuring MySQL (advanced)

Server variables may be set in the MySQL config – either the main config file (e.g. /etc/my.cnf), or included files (e.g. from /etc/my.cnf.d) – or in the startup parameters – or via setting the server variable at run-time. If they are not set anywhere then MySQL will use hard-coded defaults.

To find which config file(s) MySQL uses, run this command (Linux and MacOS):

Code (Bash)

mysql --help | grep "Default options" -A 1

In the config file it will look something like this (example for setting max_allowed_packet, which is probably what you want):

Code (Bash)

max_allowed_packet = 16M

To find if a setting is set in startup parameters (Linux and MacOS) run:

Code (Bash)

ps -Af | grep mysqld
If it is, you'll see it in the command. This may be set in an init file such as /etc/init.d/mysqld, but it varies considerably by Linux distribution.

If you are changing a config file, or a startup parameter, you naturally need to reset MySQL for it to take effect, e.g. with:

Code (Bash)

/etc/init.d/mysqld restart

Code (Bash)

service mysqld restart
Again it varies a lot by distribution. On Windows you'd use the Services application to restart the service.

When a MySQL session is started, certain server variables are cloned into the session (e.g. max_allowed_packet). These variables may then be read and written as either server or session variables (actually max_allowed_packet is read-only as a session variable – an exception described further below). If you set a global variable then the current session is not affected, but new sessions will be. Sessions are thrown out when connections are closed, e.g. when a Composr page is fully served.

To find the values of a variable you can use these MySQL queries (example for max_allowed_packet):

Code (MySQL)

SHOW GLOBAL VARIABLES LIKE 'max_allowed_packet';
SHOW SESSION VARIABLES LIKE 'max_allowed_packet';

There are lots of equivalent terms and syntaxes in MySQL which can make it confusing when trying to understand the documentation and third party solutions. Here is a guide:
  • Types of variable:
    • "Server" = "Global"
    • "Session" = "Local" = "Connection"
  • Commands for setting variables:
    • Server variables, all equivalent:
      • SET @@global.whatever=something
      • SET GLOBAL whatever=something
    • Session variables, all equivalent:
      • SET whatever=something
      • SET @@whatever=something
      • SET @@session.whatever=something
      • SET SESSION whatever=something
      • SET @@local.whatever=something
      • SET LOCAL whatever=something
  • Commands for getting variables:
    • Server variables, all equivalent:
      • SELECT @@global.whatever
    • Session variables, all equivalent:
      • SHOW VARIABLES LIKE 'whatever'
      • SHOW LOCAL VARIABLES LIKE 'whatever'
      • SELECT @@local.whatever
      • SELECT @@session.whatever

The rest of this section will deal with the specifics of the max_allowed_packet setting, which is the only variable that a server administrator usually needs to set.

max_allowed_packet exists as separate server-side and client-side settings; this is totally different from the concept of server and session variables (which are both server-side) and should not be confused.

max_allowed_packet defaults to 1MB server-side if not configured at all (i.e. this is the hard-coded default). Most web hosts will have a higher default value and Composr defines a minimum requirement of 16MB (we define a higher limit in case large Comcode pages are being cached).
max_allowed_packet's session variable exists but is read-only. Attempts to change it will give an error message. You therefore must configure the server variable correctly.
Only MySQL users with the SUPER privilege may set the server variable. Typically only the root user has this.

max_allowed_packet defaults to 1GB client-side (e.g. PHP), except in official client applications like mysql (16MB) and mysqldump (24MB) (which may be configured in the MySQL configuration, the client configuration sections).
Therefore for the Composr application the client-side setting is irrelevant, but you may come up with it when doing MySQL dumps for example.

max_allowed_packet can be set with "M" syntax, not just with exact bytes. So you can set it to 16M or 16777216, that's your choice. Once parsed MySQL will show it in bytes.

The absolute maximum max_allowed_packet setting (both server-side and client-side, as it relates to the protocol implementation) is 1GB.

Domain names

Most websites prefer to have a short and memorable Internet address, direct to their front page. In order to achieve this, you will need to pay for control of a domain name. A very large number of companies will provide these domains, and the facility to bind these names to your web-server, for a very low fee.

It is important to note that domain names are licensed on a temporary basis, and therefore you will need to renew your domain names. The length of the licence varies, but is typically between 1 and 5 years.

Ongoing maintenance responsibilities

Usually the webhost will take responsibility for the daily maintenance of the server. For example, keeping the server software, usually Linux and common Linux software, up to date with security and stability patches . However few webhosts will take serious responsibility for the maintenance (including backups) of your space on the server. If you are not using a traditional webhost then you probably are responsible for absolutely everything, so make sure you are comfortable with that.

It is important to understand the responsibilities for the various aspects of creating, maintaining and operating your website, before you launch your endeavour.

Basic server and site infrastructure

When you are provided webhosting, you are usually allocated a 'hosting control panel' that runs software such as:
  • Plesk
  • cPanel
  • Ensim
  • DirectAdmin
This allows you to manage your account on the server, and create databases, FTP accounts (additional to your primary account that already would exist), and e-mail addresses.

Note: the next few paragraphs detail the complexities of a typical Linux file system, and is not necessary reading for most users.

The server itself, has a file system, much like a desktop computer, and is usually laid out something like as follows (this example is for a Linux server):


Of course this is only a partial detailing of the directory structure, but the intent is to provide you with an overview of what is really happening on your server. Usually you will not be able to, using your control panel or SFTP/FTP, see outside of '/home/your-account-name/'. When you install Composr, you usually would place the quick installer or manual installer files inside '/home/your-account-name/httpdocs/'; this is the directory that becomes accessible at the base URL of your website.

For instance, if your account on the server was associated with a domain name, '', then would be tied to the file system file, '/home/your-account-name/httpdocs/index.php' (often the 'www.' is removable, but not on all servers).
In addition, from your main FTP account, the same file would likely be '/httpdocs/index.php'.

In other words, three views of the file system exist, according to context:
  1. The full file system view, which is usually completely hidden from you, but which is what Composr actually itself uses
  2. The FTP view, which branches off from the base of your account directory in the full file system view
  3. The URL view, which branches off from the httpdocs directory in your account directory

As previously mentioned, this file system is merely illustrative. Different servers use different conventions; for example httpdocs is often public_html or www.

Server security

(Optimal configuration advice is provided in the Security tutorial – we just cover some practical implications of configuration here)

There are two ways that webhosts may use to manage web application on the server:
  1. Shared user
  2. suEXEC-style

With a shared user, all sites run code as a user such as apache or nobody. This is simpler for the host to configure, but it is not a good idea for security. It also is the reason so much 'chmodding' may be needed (so the shared user has write access to files specifically on your account). In this scenario they will typically then lock other things down, such as denying shell access and setting an open_basedir to sandbox PHP – but rarely are these restrictions enough and it's an inherently incorrect approach for a shared webhost to take. Different server users are likely to be able to access and interfere with (erase and edit) each others files. We strongly advise any webhosts to use a suEXEC-style environment.

With a suEXEC-style hosting environment, sites run code under the same account that the site is held in. This is simpler, easier to configure, and more secure. "suEXEC" refers specifically to how the Apache server manages this, other server software will refer to it in different ways.

Worked example of a shared user permission scheme

Without suEXEC the web server will run under a web-server-specific user, such as apache or nobody.

It is a good idea to understand the disparity of file ownership that can happen…

Let's assume the web server runs as apache, and your user account is bob.

Any file created by the web server (or PHP) would be owned by apache. For example, Composr uploads, or Composr revision files.

Any files you manually uploaded (e.g. via FTP) would be owned by bob.

Both of these situations present a disparity in the permission scheme.

If apache wants to write to a file you uploaded, it cannot, unless you specified world-write permissions on the file. This is why we talk about file permissions in our documentation, saying exactly what needs to be set.

If you want to edit or delete a file made by the web server, using your FTP account, you cannot, unless the server had specified world-write permissions on the file. Fortunately Composr is quite smart and it actually does set world-write permissions on the apache owned files. It does this because it automatically detects the disparity between the account owner and the user the server is running as.
Composr detects the account owner by seeing who owns the index.php file.

So, the main take-away is:
If you do not have suEXEC, any files the web server needs to be able to write to need to be either reassigned to be owned by the web server (if you are a server admin you can do that, it's more secure if other users have login access to your web server) or given world-write permissions (what most Composr users would have to do)


'PHP-info' displays information about the PHP server environment. This is based on a feature PHP itself provides, of the same name – but we also add in some extra checks of our own, putting out warnings if software requirements are not met.

Information includes all the technical details of the PHP configuration, such as the installed PHP extensions and the defined options.

Some PHP options can be defined in the '.htaccess' file (Apache non-CGI web server users only), as illustrated by the default recommended.htaccess file. On CGI servers you need to use a custom php.ini file instead (see our FAQ). Full details of this are in the PHP manual.

The PHP-info is also convenient for identifying wider factors of the system environment, such as server paths.

PHP-Info can be reached from:
Admin Zone > Tools > PHP-Info / Server Checks

Failover mode

You may configure a special failover mode via the config_editor script. This mode serves cached versions of page if your server seems to be failing. It is not a perfect system because:
  1. it serves hits as guests
  2. it can only work if the static cache is populated
  3. it assumes that your server is only failing for performance/database reasons, not totally failed (however most failures in practice are like this)

However, it's still a great system because it lets your site content continue to be available even under massive load.

Failover can automatically fall into place based on a number of criteria.

Note that the failover status messages (failover_message_place_after and failover_message_place_before options) are put in place at the caching stage, not dynamically. So you would need to empty the static cache if you change these messages to something else.

Failover mode requires the PHP usleep function not be disabled.


A provider of Internet server facilities
Dedicated server
A server that is not shared with others
A virtual private server. This works via allowing multiple virtual machines to run on a real host machine. Typically this is what cloud hosting is using behind-the-scenes
The Linux operating system, very well suited to servers
Patches are upgrades to software designed to fix problems, especially security ones nowadays
Infrastructure as a service. This is cloud hosting based on direct provision of VPSs.
Platform as a service. This is cloud hosting based on providing direct support and configurability for particular programming language(s). It typically will hide the complexities of VPS management from you.
Software as a service. This is what you are using when you create something like a Facebook page or a hosted blog, where you don't ever need to directly install/configure the software. This has advantages but severely limits configurability. Composr could be delivered as SaaS but the majority of users want a high degree of control over their sites.
Traditional hosting
Hosting managed via a webhost. Support is provided, servers are kept up-to-date, and control panels are provided for relatively easy system management.

See also


Please rate this tutorial:
Item has a rating of 5 (Liked by rwill76Liked by ldmidelhi)

Have a suggestion? Report an issue on the tracker.

Back to Top