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 a number of different choices to make regarding your hosting platform.

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.

Operating system

Choices:

• Linux (maintenance status) (the default)
• Mac (maintenance status) (if you're developing on your own machine; equivalent to Linux)
• Windows (maintenance status) (if you're developing on your own machine or on a Windows server)

Hosting control panel

When you are provided webhosting, you are usually allocated a webhosting control panel that runs software such as:

• Plesk (maintenance status)
• cPanel (maintenance status)
• 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.

Most users will want a webhosting control panel as otherwise you'll require some expertise in server configuration.

Without a webhosting control panel you'll need to know how to use SSH (Linux) or Remote Desktop (Windows), and then expertise in all the features of the operating system that you need to work with.

Type of hosting

Choices:

• Shared hosting (the default)
• VPS hosting / IaaS (e.g. Amazon EC2, Azure, Rackspace)
• Dedicated server
• PaaS:
  • 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

Shared hosting is cheaper by a long way, but may have poor performance, depending on the nature of the webhost, your hosting neighbours, and the hosting plan.

A VPS may have anything from terrible performance to great performance, depending on how much resource the VPS has been granted.

IaaS is very common among professionals due to the ability to quickly provision a machine. However management is not really any different than a dedicated server or VPS without 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.

PaaS is highly specialised and not recommended unless you are a developer. 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 and outside the scope of any direct instructions we can give.

On shared hosting the webhost will take responsibility for the daily maintenance of the server. For example, keeping the server 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 running a VPS or a dedicated server 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.

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

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, so most PHP/MySQL-supporting webhosts should be compatible.

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. These requirements only apply to bundled functionality; non-bundled addons may have their own requirements.

General

We require:

• At least 250MB of disk space (plus your needs for space for downloads, images, etc).
• No maximum file size limit under 25MB (some free webhosts will impose such a limit).
• No file type safelists (some free webhosts will impose such a limit – which explains why data.cms might disappear when you try to upload it; sometimes you can work around that by renaming cms files as *.tar.gz, uploading it, then renaming it on the server back to *.cms).
• Certain file permissions are required as described in the File permissions tutorial.
• That the 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.
• That the Composr install path does not contain the text "_custom" in it.
• That you not use ad-sponsored free webhost. The banners and tracking they inject will interfere with the mechanisms of Composr.

If running Windows:

• You should use an NTFS partition not a FAT32 partition, as FAT32 cannot support file locking.

Operating System

We require:

• The web server may be running Windows, Linux, or Mac OS. Other operating systems such as Solaris or OpenBSD are not officially supported, although bug fixes may be made.

Web Server

We require:

• A web server running Apache (the common Linux web server), LiteSpeed (maintenance status) [an Apache drop-in replacement], or IIS7+ (maintenance status) [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). It is possible to use a reverse proxy, such as Nginx (maintenance status), along with a web server such as Apache. However, we do not have special support for reverse proxies. It will be up to the webhost to ensure the proxy is configured properly. Be aware that static caching on the proxy could interfere with the software.
• 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.
• Either a suEXEC-style web server (strongly recommended) †, or a working FTP connection from PHP back to the hosting (so the server has to be running FTP, and PHP has to be running the PHP ftp extension).

If running Apache:

• Only Apache 2.4+ is fully supported
• It is assumed the AccessFileName option is set to the default .htaccess.
• If you want URL Schemes or URL Redirects, mod_rewrite must be enabled.
• 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).
• The following Apache modules are recommended (for maximum performance): mod_headers, mod_setenvif, mod_env, mod_deflate, mod_filter

If running IIS:

• You may not have disabled default Feature Delegation for anything the bundled web.config file changes (unless you manually change your main IIS configuration and edit the web.config as required to match)
• You must have the URL Rewrite module installed. This is not just needed for URL Schemes and URL Redirects, but also for basic security.
• It is possible you may need to configure IIS for additional mime-types, depending on what you are trying to do. Unlike Apache, IIS will not (by default) serve file types it is not configured to know a mime-type for.

If running LiteSpeed:

• Be aware that we do not provide explicit support for LiteSpeed.
• LiteSpeed only supports mod_rewrite directives from Apache .htaccess files; it does not support other directives such as AllowOverride or php_value used in the files and will ignore them. Make sure you modify your PHP configuration according to the specified php_value directives for your Composr site.
• You might have to modify all RewriteRule substitutions to include a forward-slash (/) before index.php.

If running Nginx:

• Be aware that we do not provide explicit support for Nginx.
• It is easier to use Nginx with the Composr software if proxying to a supported web server software mentioned above. Nginx does not support the directives or rewrite rules offered by Apache or IIS, and it also does not support reading in .htaccess or web.config files. Therefore, rewrite rules and access control for certain directories will not work when using Nginx as a standalone web server unless you explicitly configure them.
• Ensure Nginx is not caching static Composr resources. This could cause problems with the Composr software.

† By suEXEC-style web server we mean 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)

PHP

PHP is software which provides the environment that Composr is written for.

We require:

• A minimum of PHP version 7.2, however:
  • We strongly discourage hosting anything that is not officially supported by the PHP developers.
  • Forum drivers may require a newer version of PHP if the forum software itself does.
• A maximum of PHP 8.3 (this is what we have tested up to, although newer minor versions usually do work or are quickly fixed to work).
• The following PHP extensions:
  • GD2 (gd), including PNG and JPEG support (GD is used by PHP for image generation, e.g. to generate thumbnails).
  • MySQL extension (mysqli or pdo_mysql)
    • MySQL Native Driver being enabled or not is not a factor
    • (other databases are semi-supported, in which case you need the appropriate extension referenced in the tutorial written specifically for that database).
  • XML extension (xml).
  • The Multibyte String (mbstring) PHP extension (for reliable Unicode support).
  • cURL extension (curl) (for reliable file downloading).
  • JSON support is required in PHP which should be available by default, but for controversial licensing reasons is provided in separate packaging on some Linux distributions
  • Sodium (libsodium), available via PECL (for cryptographic encryption).
• The file upload settings set to allow at least 5MB (or higher, depending on your particular needs).
• A maximum execution time of at least 30 seconds.
• 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 via third-party PHP modification. 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 128MB (as this is PHP's default memory limit since 2009).
• 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)

Database

MySQL is the database software which Composr uses to store the majority of its data. MariaDB (maintenance status) will probably work as a drop-in MySQL replacement. Certain other database software may work, but is not fully supported; the requirements for other database software is discussed in tutorials specifically for that software.

We require:

• MySQL database software (if you want it to be fully supported).
• MySQL version 5.5.3 (†) or higher (although we have not tested the software beyond version 8.2).
• At least 25MB of database storage space (which should be available on any reputable webhost).
  • You may need a substantially larger amount of database space for sites utilising content translations, using the software's fulltext search, or heavily utilising content (e.g. social communities or catalogue-heavy sites).
• The max_allowed_packet server system setting must be at least 4M (this became the default in MySQL 5.6).
  • Consider using 8M instead if you plan to use web or PT notifications for error messages with stack traces.

(†) 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.

Often webhosts will quote a number of databases that webhosting comes with: Composr only requires a single MySQL database to function.

Requirements for specific features

Highly recommended

If you want to be able to generate custom graphics with quality TrueType text on, such as in the Logo Wizard, you'll need PHP to have been built with FreeType support.

If you want automatic image rotation correction, and image metadata import, you'll need the PHP exif extension.

If you want support for using ZIP files, you'll need the PHP zip extension.

To properly check permissions the posix extension is needed.

For faster upgrade transfer (which might be necessary on some webhosts), or compressed backups, or page compression, you want the PHP zlib extension. This is standard on many Linux distributions without a need to separately install it, but if compiling PHP yourself you need to include support for it.
If you want full Brotli compression you need to have the unofficial PHP Brotli extension; installing this generally requires some access and expertise.

For slightly faster performance the ctype extension helps.

Ideally e-mails should be sendable directly from PHP's own mail functionality. For this to work an SMTP server (or relay server) has to be available on the web server machine, or on Windows the PHP SMTP configuration needs to be filled in. Composr can connect to external SMTP servers but it is less elegant and perhaps more error prone than using a local server or relay.

If you need to be able to easily remove 'bounce' e-mails from newsletter subscriber lists, you will need the PHP IMAP extension (imap). 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). It is highly recommended you do this as your IP could get added to a spam blacklist for repeatedly sending e-mails to invalid addresses or addresses / domains that have blocked you.

Very specific features

If you want automatic thumbnail generation on videos you need a server with FFMPEG on it. It must be accessible via PHP either via the unofficial PHP FFMPEG extension, or the ability for shell_exec to run from PHP.

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

The OpenSSL extension (openssl) is required for:

• encrypted CPFs (Custom Profile Fields) (see the Advanced Composr member system tutorial)
• Composr-fed DKIM
• SSL-certificate expiry Health Check

If spell checking is needed, the Pspell (pspell) or Enchant (enchant) PHP extensions must be installed with matching aspell/hunspell installs and dictionaries on the server.

If transliteration of non-European languages is desired (for quality URL moniker generation), or Punycode support, or locale-aware sorting, the PHP intl extension (intl) is required.

If PDF download indexing is required, pdftohtml (poppler-utils) is required.

If using the eCommerce system with the Authorize.net payment gateway, then it is recommended, though not required, to have PHP hash_hmac support. This allows the Composr software to compare hashes with Authorize.net as added security to prevent fraudulent requests.

Further recommendations

Composr recommends:

• PHP versions:
  • Don't accept EOL ("end-of-life"). If a webhost or Linux distribution has a PHP version that is EOL, it is not just out-dated, but also insecure (at the time of writing, anything less than PHP 8.0 is unsupported by the PHP developers).
  • Make sure your PHP version is updated with security fixes, even if you haven't updated to the latest major version.

Easy-reference summary of the key hosting recommendations.

(Click to enlarge)

• A PHP opcode cache: Zend OpCache (bundled by default), APC (available for PHP 5.6 or lower only), APCu, XCache, Nusphere PhpExpress, or Wincache.
• A PHP environment with open_basedir enabled.
• At least 250MB of disk space.
• Generally, if you are using shared webhosting then we advise picking a host that does nightly backups that you have access to restore – we've seen a lot of webhosts not take any responsibility for backup, and it does need doing at the server level to work effectively.

Web server compatibility

Composr is only tested on, and optimised for, Apache and IIS.
It might work on other web server software, such as LiteSpeed or Nginx, but it may require special configuration. We do not provide explicit support for configurations outside of Apache and IIS.

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

• Invision Board 2.3 (maintenance status)
• phpBB 3.3 (maintenance status)
• myBB 1.8 (maintenance status)
• vBulletin .7 (maintenance status)
• Burning Board 2.2/Lite (maintenance status)
• Simple Machine Forum 2.1 (maintenance status)

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

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 Mac OS) 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 webhosts 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.

Basic server and site infrastructure

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 the configuration a webhost provides you 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:

See also

• Installation
• File permissions
• Installation on Linux
• Installation on a Windows desktop
• Installation on a Windows server
• Browser version requirements
• Optimising Performance
• Security
• Website Health

Feedback

Have a suggestion? Report an issue on the tracker.