Composr Tutorial: Webhosting for Composr

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.3 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 7.3 is unsupported by the PHP developers)
  • 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 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
  • If running IIS, the rewrite module may need to be enabled or the bundled web.config may need editing to remove the <rewrite>...</rewrite> section
• 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.

Ubuntu/Debian

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

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

Fedora/RHEL/CentOS

You may need to setup the EPEL repository first.


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 = 2M → upload_max_filesize = 500M
post_max_size = 8M → post_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..



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.

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):

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

To find if a setting is set in startup parameters (Linux and MacOS) run:
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:
or:
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):

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:
    • SHOW GLOBAL VARIABLES LIKE 'whatever'
    • SELECT @@global.whatever
  • Session variables, all equivalent:
    • SHOW VARIABLES LIKE 'whatever'
    • SHOW LOCAL VARIABLES LIKE 'whatever'
    • SHOW SESSION 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):

/
/home/
/home/your-account-name/
/home/your-account-name/httpdocs/
/var/
/var/mysql/
/var/mysql/your-database-name/
/var/mysql/your-database-name/<database-files>

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, 'mywebsite.com', then http://mywebsite.com/index.php 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:

PHP-Info

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

See also

• Basic Installation
• Advanced installation
• Installing Composr on a Windows desktop
• Browser version requirements
• Optimising Performance

Feedback

Have a suggestion? Report an issue on the tracker.