2019-11-18 05:58:33 +01:00
|
|
|
---
|
|
|
|
|
title: Server Requirements
|
|
|
|
|
icon: server
|
|
|
|
|
summary: What you will need to run Silverstripe CMS on a web server
|
|
|
|
|
---
|
|
|
|
|
|
|
|
|
|
|
2011-02-07 07:48:44 +01:00
|
|
|
# Requirements
|
|
|
|
|
|
2019-11-18 05:58:33 +01:00
|
|
|
Silverstripe CMS needs to be installed on a web server. Content authors and website administrators use their web browser
|
2014-09-21 02:07:58 +02:00
|
|
|
to access a web-based GUI to do their day-to-day work. Website designers and developers require access to the files on
|
|
|
|
|
the server to update templates, website logic, and perform upgrades or maintenance.
|
2011-02-07 07:48:44 +01:00
|
|
|
|
DOCS Rewrite server requirements
* Remove overly specific PHP RNG instructions (that's just built into PHP7 through random_bytes now, which will throw if no suitable RNG is available)
* Remove PHP 5 RNG requirements, since we don't support that PHP release any mre
* Remove verbose explanation of PHP 5.6 support
* Remove conflicting instructions for PHP memory limits
* Remove version numbers from supporetd databases other than MySQL, it's up to the community modules to define that
* Remove Oracle support (code is nine years old!)
* Make "community supported" status clearer on databases, people can draw their own conclusions as open source users on Github
* Remove IIS version number, I think we should just stick to "needs web.config" and not give the impression that this is actively tested
* Remove mention of OSes for web servers, that's kind of irrelevant in today's hosting world (containers, PaaS, etc)
* Shorten install instructions in favour of a "quickstart" and point to lessons instead
* Remove mention of archive download option, we really shouldn't promote this - composer is the de-facto standard
* Add generic descriptions of the hosting environment considerations without going too much into specifics
* Remove Apache version number, we don't test on different versions, and really mostly rely on mod_rewrite working properly. Laravel does the same (doesn't claim specific Apache version support)
2019-09-03 06:07:17 +02:00
|
|
|
## PHP
|
|
|
|
|
|
|
|
|
|
* PHP >=7.1
|
|
|
|
|
* PHP extensions: `ctype`, `dom`, `fileinfo`, `hash`, `intl`, `mbstring`, `session`, `simplexml`, `tokenizer`, `xml`
|
|
|
|
|
* PHP configuration: `memory_limit` with at least `48M`
|
|
|
|
|
* PHP extension for image manipulation: Either `gd` or `imagick`
|
|
|
|
|
* PHP extension for a database connector (e.g. `pdo` or `mysqli`)
|
|
|
|
|
|
|
|
|
|
Use [phpinfo()](http://php.net/manual/en/function.phpinfo.php) to inspect your configuration.
|
|
|
|
|
|
|
|
|
|
## Database
|
|
|
|
|
|
|
|
|
|
* MySQL >=5.6 (built-in, [commercially supported](https://www.silverstripe.org/software/addons/silverstripe-commercially-supported-module-list/))
|
|
|
|
|
* PostgreSQL ([third party module](https://addons.silverstripe.org/add-ons/silverstripe/postgresql), community supported)
|
|
|
|
|
* SQL Server ([third party module](https://addons.silverstripe.org/add-ons/silverstripe/mssql), community supported)
|
|
|
|
|
* SQLite ([third party module](https://addons.silverstripe.org/add-ons/silverstripe/sqlite3), community supported)
|
|
|
|
|
|
|
|
|
|
## Webserver Configuration
|
|
|
|
|
|
|
|
|
|
### Overview
|
|
|
|
|
|
|
|
|
|
SilverStripe needs to handle a variety of HTTP requests,
|
|
|
|
|
and relies on the hosting environment to be configured securely to
|
2019-09-04 05:34:36 +02:00
|
|
|
enforce restrictions. There are secure defaults in place for Apache,
|
DOCS Rewrite server requirements
* Remove overly specific PHP RNG instructions (that's just built into PHP7 through random_bytes now, which will throw if no suitable RNG is available)
* Remove PHP 5 RNG requirements, since we don't support that PHP release any mre
* Remove verbose explanation of PHP 5.6 support
* Remove conflicting instructions for PHP memory limits
* Remove version numbers from supporetd databases other than MySQL, it's up to the community modules to define that
* Remove Oracle support (code is nine years old!)
* Make "community supported" status clearer on databases, people can draw their own conclusions as open source users on Github
* Remove IIS version number, I think we should just stick to "needs web.config" and not give the impression that this is actively tested
* Remove mention of OSes for web servers, that's kind of irrelevant in today's hosting world (containers, PaaS, etc)
* Shorten install instructions in favour of a "quickstart" and point to lessons instead
* Remove mention of archive download option, we really shouldn't promote this - composer is the de-facto standard
* Add generic descriptions of the hosting environment considerations without going too much into specifics
* Remove Apache version number, we don't test on different versions, and really mostly rely on mod_rewrite working properly. Laravel does the same (doesn't claim specific Apache version support)
2019-09-03 06:07:17 +02:00
|
|
|
but you should be aware of the configuration regardless of your webserver setup.
|
|
|
|
|
|
2019-09-03 08:51:27 +02:00
|
|
|
### Public webroot
|
|
|
|
|
|
|
|
|
|
The webroot of your webserver should be configured to the `public/` subfolder.
|
2019-09-04 05:34:36 +02:00
|
|
|
Projects created prior to SilverStripe 4.1 might be using the main project
|
2019-09-03 08:51:27 +02:00
|
|
|
folder as the webroot. In this case, you are responsible for ensuring
|
|
|
|
|
access to system files such as configuration in `*.yml` is protected
|
|
|
|
|
from public access. We strongly recommend switching to more secure
|
|
|
|
|
hosting via the `public/`. See [4.1.0 upgrading guide](/changelogs/4.1.0).
|
|
|
|
|
|
DOCS Rewrite server requirements
* Remove overly specific PHP RNG instructions (that's just built into PHP7 through random_bytes now, which will throw if no suitable RNG is available)
* Remove PHP 5 RNG requirements, since we don't support that PHP release any mre
* Remove verbose explanation of PHP 5.6 support
* Remove conflicting instructions for PHP memory limits
* Remove version numbers from supporetd databases other than MySQL, it's up to the community modules to define that
* Remove Oracle support (code is nine years old!)
* Make "community supported" status clearer on databases, people can draw their own conclusions as open source users on Github
* Remove IIS version number, I think we should just stick to "needs web.config" and not give the impression that this is actively tested
* Remove mention of OSes for web servers, that's kind of irrelevant in today's hosting world (containers, PaaS, etc)
* Shorten install instructions in favour of a "quickstart" and point to lessons instead
* Remove mention of archive download option, we really shouldn't promote this - composer is the de-facto standard
* Add generic descriptions of the hosting environment considerations without going too much into specifics
* Remove Apache version number, we don't test on different versions, and really mostly rely on mod_rewrite working properly. Laravel does the same (doesn't claim specific Apache version support)
2019-09-03 06:07:17 +02:00
|
|
|
### Filesystem permissions
|
|
|
|
|
|
|
|
|
|
SilverStripe needs write access for the webserver user to `public/assets`,
|
|
|
|
|
and read access for that user on everything else in your webroot.
|
|
|
|
|
|
|
|
|
|
### Assets
|
|
|
|
|
|
|
|
|
|
SilverStripe allows CMS authors to upload files into the `public/assets/` folder,
|
|
|
|
|
which should be served by your webserver. **No PHP execution should be allowed in this folder**.
|
|
|
|
|
This is configured for Apache by default via `public/assets/.htaccess`.
|
|
|
|
|
The file is generated dynamically during the `dev/build` stage.
|
|
|
|
|
|
|
|
|
|
Additionally, access is whitelisted by file extension through a
|
|
|
|
|
dynamically generated whitelist based on the `File.allowed_extensions` setting
|
|
|
|
|
(see [File Security](/developer_guides/files/file_security#file-types)).
|
|
|
|
|
|
|
|
|
|
### Secure Assets
|
|
|
|
|
|
|
|
|
|
Files can be kept in draft stage,
|
|
|
|
|
and access restricted to certain user groups.
|
|
|
|
|
These files are stored in a special `.protected` folder (defaulting to `public/assets/.protected`).
|
|
|
|
|
**Requests to files in this folder should be denied by your webserver**.
|
|
|
|
|
|
|
|
|
|
Requests to files in the `.protected` folder
|
|
|
|
|
are routed to PHP by default when using Apache, through `public/assets/.htaccess`.
|
|
|
|
|
If you are using another webserver, please follow our guides to ensure a secure setup.
|
|
|
|
|
See [Developer Guides: File Security](/developer_guides/files/file_security) for details.
|
|
|
|
|
|
|
|
|
|
### URL Rewriting
|
|
|
|
|
|
|
|
|
|
SilverStripe expects URL paths to be rewritten to `public/index.php`.
|
|
|
|
|
For Apache, this is preconfigured through `.htaccess` files,
|
|
|
|
|
and expects using the `mod_rewrite` module.
|
|
|
|
|
By default, these files are located in `public/.htaccess` and `public/assets/.htaccess`.
|
|
|
|
|
|
|
|
|
|
### HTTP Headers
|
|
|
|
|
|
|
|
|
|
SilverStripe can add HTTP headers to reponses it handles directly.
|
|
|
|
|
These headers are often sensitive, for example preventing HTTP caching for responses
|
|
|
|
|
displaying data based on user sessions, or when serving protected assets.
|
|
|
|
|
You need to ensure those headers are kept in place in your webserver.
|
|
|
|
|
For example, Apache allows this through `Header setifempty` (see [docs](https://httpd.apache.org/docs/current/mod/mod_headers.html#header)).
|
|
|
|
|
See [Developer Guide: Performance](/developer_guides/performance/)
|
|
|
|
|
and [Developer Guides: File Security](/developer_guides/files/file_security) for more details.
|
|
|
|
|
|
|
|
|
|
### Symlinks
|
|
|
|
|
|
|
|
|
|
SilverStripe is a modular system, with modules installed and updated
|
|
|
|
|
via the `composer` PHP dependency manager. These are usually stored in `vendor/`,
|
|
|
|
|
outside of the `public/` webroot. Since many modules rely on serving frontend assets
|
2019-09-04 05:31:24 +02:00
|
|
|
such as CSS files or images, these are mapped over to the `public/_resources/` folder automatically.
|
DOCS Rewrite server requirements
* Remove overly specific PHP RNG instructions (that's just built into PHP7 through random_bytes now, which will throw if no suitable RNG is available)
* Remove PHP 5 RNG requirements, since we don't support that PHP release any mre
* Remove verbose explanation of PHP 5.6 support
* Remove conflicting instructions for PHP memory limits
* Remove version numbers from supporetd databases other than MySQL, it's up to the community modules to define that
* Remove Oracle support (code is nine years old!)
* Make "community supported" status clearer on databases, people can draw their own conclusions as open source users on Github
* Remove IIS version number, I think we should just stick to "needs web.config" and not give the impression that this is actively tested
* Remove mention of OSes for web servers, that's kind of irrelevant in today's hosting world (containers, PaaS, etc)
* Shorten install instructions in favour of a "quickstart" and point to lessons instead
* Remove mention of archive download option, we really shouldn't promote this - composer is the de-facto standard
* Add generic descriptions of the hosting environment considerations without going too much into specifics
* Remove Apache version number, we don't test on different versions, and really mostly rely on mod_rewrite working properly. Laravel does the same (doesn't claim specific Apache version support)
2019-09-03 06:07:17 +02:00
|
|
|
If the filesystem supports it, this is achieved through symlinks.
|
|
|
|
|
Depending on your hosting and deployment mechanisms,
|
2019-09-04 05:34:36 +02:00
|
|
|
you may need to configure the plugin to copy files instead.
|
DOCS Rewrite server requirements
* Remove overly specific PHP RNG instructions (that's just built into PHP7 through random_bytes now, which will throw if no suitable RNG is available)
* Remove PHP 5 RNG requirements, since we don't support that PHP release any mre
* Remove verbose explanation of PHP 5.6 support
* Remove conflicting instructions for PHP memory limits
* Remove version numbers from supporetd databases other than MySQL, it's up to the community modules to define that
* Remove Oracle support (code is nine years old!)
* Make "community supported" status clearer on databases, people can draw their own conclusions as open source users on Github
* Remove IIS version number, I think we should just stick to "needs web.config" and not give the impression that this is actively tested
* Remove mention of OSes for web servers, that's kind of irrelevant in today's hosting world (containers, PaaS, etc)
* Shorten install instructions in favour of a "quickstart" and point to lessons instead
* Remove mention of archive download option, we really shouldn't promote this - composer is the de-facto standard
* Add generic descriptions of the hosting environment considerations without going too much into specifics
* Remove Apache version number, we don't test on different versions, and really mostly rely on mod_rewrite working properly. Laravel does the same (doesn't claim specific Apache version support)
2019-09-03 06:07:17 +02:00
|
|
|
See [silverstripe/vendor-plugin](https://github.com/silverstripe/vendor-plugin) for details.
|
|
|
|
|
|
|
|
|
|
### Error pages
|
|
|
|
|
|
|
|
|
|
The default installation includes [silverstripe/errorpage](https://addons.silverstripe.org/add-ons/silverstripe/errorpage),
|
|
|
|
|
which generates static error pages that bypass PHP execution when those pages are published in the CMS.
|
|
|
|
|
Once published, the static files are located in `public/assets/error-404.html` and `public/assets/error-500.html`.
|
|
|
|
|
The default `public/.htaccess` file is configured to have Apache serve those pages based on their HTTP status code.
|
|
|
|
|
|
|
|
|
|
### Other webservers (Nginx, IIS, Lighttpd)
|
|
|
|
|
|
|
|
|
|
Serving through webservers other than Apache requires more manual configuration,
|
|
|
|
|
since the defaults configured through `.htaccess` don't apply.
|
|
|
|
|
Please apply the considerations above to your webserver to ensure a secure hosting environment.
|
|
|
|
|
In particular, configure protected assets correctly to avoid exposing draft or protected files uploaded through the CMS.
|
|
|
|
|
|
|
|
|
|
There are various community supported installation instructions for different environments.
|
|
|
|
|
Nginx is a popular choice, see [Nginx webserver configuration](https://forum.silverstripe.org/t/nginx-webserver-configuration/2246).
|
|
|
|
|
|
|
|
|
|
SilverStripe is known to work with Microsoft IIS, and generates `web.config` files by default
|
|
|
|
|
(see [Microsoft IIS and SQL Server configuration](https://forum.silverstripe.org/t/microsoft-iis-webserver-and-sql-server-support/2245)).
|
|
|
|
|
|
|
|
|
|
Additionally, there are community supported guides for installing SilverStripe
|
|
|
|
|
on various environments:
|
|
|
|
|
|
|
|
|
|
* [Hosting via Bitnami](https://bitnami.com/stack/silverstripe/virtual-machine): In the cloud or as a locally hosted virtual machine
|
|
|
|
|
* [Vagrant/Virtualbox with CentOS](https://forum.silverstripe.org/t/installing-via-vagrant-virtualbox-with-centos/2248)
|
2019-09-04 05:32:41 +02:00
|
|
|
* [macOS with Homebrew](https://forum.silverstripe.org/t/installing-on-osx-with-homebrew/2247)
|
2019-09-04 05:34:36 +02:00
|
|
|
* [macOS with MAMP](https://forum.silverstripe.org/t/installing-on-osx-with-mamp/2249)
|
DOCS Rewrite server requirements
* Remove overly specific PHP RNG instructions (that's just built into PHP7 through random_bytes now, which will throw if no suitable RNG is available)
* Remove PHP 5 RNG requirements, since we don't support that PHP release any mre
* Remove verbose explanation of PHP 5.6 support
* Remove conflicting instructions for PHP memory limits
* Remove version numbers from supporetd databases other than MySQL, it's up to the community modules to define that
* Remove Oracle support (code is nine years old!)
* Make "community supported" status clearer on databases, people can draw their own conclusions as open source users on Github
* Remove IIS version number, I think we should just stick to "needs web.config" and not give the impression that this is actively tested
* Remove mention of OSes for web servers, that's kind of irrelevant in today's hosting world (containers, PaaS, etc)
* Shorten install instructions in favour of a "quickstart" and point to lessons instead
* Remove mention of archive download option, we really shouldn't promote this - composer is the de-facto standard
* Add generic descriptions of the hosting environment considerations without going too much into specifics
* Remove Apache version number, we don't test on different versions, and really mostly rely on mod_rewrite working properly. Laravel does the same (doesn't claim specific Apache version support)
2019-09-03 06:07:17 +02:00
|
|
|
* [Windows with WAMP](https://forum.silverstripe.org/t/installing-on-windows-via-wamp/2250)
|
|
|
|
|
* [Vagrant with silverstripe-australia/vagrant-environment](https://github.com/silverstripe-australia/vagrant-environment)
|
|
|
|
|
* [Vagrant with BetterBrief/vagrant-skeleton](https://github.com/BetterBrief/vagrant-skeleton)
|
|
|
|
|
|
|
|
|
|
## PHP Requirements for older SilverStripe releases {#php-support}
|
2019-04-30 03:07:16 +02:00
|
|
|
|
|
|
|
|
SilverStripe's PHP support has changed over time and if you are looking to upgrade PHP on your SilverStripe site, this table may be of use:
|
|
|
|
|
|
|
|
|
|
| SilverStripe Version | PHP Version | More information |
|
|
|
|
|
| -------------------- | ----------- | ---------------- |
|
|
|
|
|
| 3.0 - 3.5 | 5.3 - 5.6 | [requirements docs](https://docs.silverstripe.org/en/3.4/getting_started/server_requirements/)
|
|
|
|
|
| 3.6 | 5.3 - 7.1 | |
|
|
|
|
|
| 3.7 | 5.3 - 7.3 | [changelog](https://docs.silverstripe.org/en/3/changelogs/3.7.0/) |
|
|
|
|
|
| 4.0 - 4.4 | 5.6+ | |
|
|
|
|
|
| 4.5+ (unreleased) | 7.1+ | [blog post](https://www.silverstripe.org/blog/our-plan-for-ending-php-5-6-support-in-silverstripe-4/) |
|
|
|
|
|
|
|
|
|
|
|
DOCS Rewrite server requirements
* Remove overly specific PHP RNG instructions (that's just built into PHP7 through random_bytes now, which will throw if no suitable RNG is available)
* Remove PHP 5 RNG requirements, since we don't support that PHP release any mre
* Remove verbose explanation of PHP 5.6 support
* Remove conflicting instructions for PHP memory limits
* Remove version numbers from supporetd databases other than MySQL, it's up to the community modules to define that
* Remove Oracle support (code is nine years old!)
* Make "community supported" status clearer on databases, people can draw their own conclusions as open source users on Github
* Remove IIS version number, I think we should just stick to "needs web.config" and not give the impression that this is actively tested
* Remove mention of OSes for web servers, that's kind of irrelevant in today's hosting world (containers, PaaS, etc)
* Shorten install instructions in favour of a "quickstart" and point to lessons instead
* Remove mention of archive download option, we really shouldn't promote this - composer is the de-facto standard
* Add generic descriptions of the hosting environment considerations without going too much into specifics
* Remove Apache version number, we don't test on different versions, and really mostly rely on mod_rewrite working properly. Laravel does the same (doesn't claim specific Apache version support)
2019-09-03 06:07:17 +02:00
|
|
|
## CMS browser requirements
|
2011-02-07 07:48:44 +01:00
|
|
|
|
2018-10-30 00:28:00 +01:00
|
|
|
SilverStripe CMS supports the following web browsers:
|
|
|
|
|
* Google Chrome
|
|
|
|
|
* Internet Explorer 11
|
|
|
|
|
* Microsoft Edge
|
DOCS Rewrite server requirements
* Remove overly specific PHP RNG instructions (that's just built into PHP7 through random_bytes now, which will throw if no suitable RNG is available)
* Remove PHP 5 RNG requirements, since we don't support that PHP release any mre
* Remove verbose explanation of PHP 5.6 support
* Remove conflicting instructions for PHP memory limits
* Remove version numbers from supporetd databases other than MySQL, it's up to the community modules to define that
* Remove Oracle support (code is nine years old!)
* Make "community supported" status clearer on databases, people can draw their own conclusions as open source users on Github
* Remove IIS version number, I think we should just stick to "needs web.config" and not give the impression that this is actively tested
* Remove mention of OSes for web servers, that's kind of irrelevant in today's hosting world (containers, PaaS, etc)
* Shorten install instructions in favour of a "quickstart" and point to lessons instead
* Remove mention of archive download option, we really shouldn't promote this - composer is the de-facto standard
* Add generic descriptions of the hosting environment considerations without going too much into specifics
* Remove Apache version number, we don't test on different versions, and really mostly rely on mod_rewrite working properly. Laravel does the same (doesn't claim specific Apache version support)
2019-09-03 06:07:17 +02:00
|
|
|
* Mozilla Firefox
|
2018-10-30 00:28:00 +01:00
|
|
|
|
|
|
|
|
We aim to provide satisfactory experiences in Apple Safari. SilverStripe CMS works well across Windows, Linux, and Mac operating systems.
|
2011-02-07 07:48:44 +01:00
|
|
|
|
2014-09-21 02:07:58 +02:00
|
|
|
## End user requirements
|
2011-02-07 07:48:44 +01:00
|
|
|
|
2014-09-21 02:07:58 +02:00
|
|
|
SilverStripe CMS is designed to make excellent, standards-compliant websites that are compatible with a wide range of
|
|
|
|
|
industry standard browsers and operating systems. A competent developer is able to produce websites that meet W3C
|
2015-01-13 20:59:55 +01:00
|
|
|
guidelines for HTML, CSS, JavaScript, and accessibility, in addition to meeting specific guide lines, such as
|
2014-09-21 02:07:58 +02:00
|
|
|
e-government requirements.
|
