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


Easy-reference summary of the key hosting recommendations.

Easy-reference summary of the key hosting recommendations.

(Click to enlarge)

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 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)
  • 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)
    • 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
  • 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 (for example nginx should work, but you would need significant expertise to get the URL schemes functionality working)
    • 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)
  • 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')
  • 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
(*) 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 †
    • 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 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 off-line/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), 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

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)


Code (Bash)

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

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)

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.

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


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

Have a suggestion? Report an issue on the tracker.

Back to Top