2019-11-18 05:58:33 +01:00
---
title: Server Requirements
icon: server
2020-10-22 04:01:30 +02:00
summary: What you will need to run Silverstripe CMS on a web server
2019-11-18 05:58:33 +01:00
---
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)
2020-10-22 04:01:30 +02:00
### Connection mode (sql_mode) when using MySQL server >=5.7.5
In MySQL versions >=5.7.5, the `ANSI` sql_mode setting behaves differently and includes the `ONLY_FULL_GROUP_BY` setting. It is generally recommended to leave this setting as-is because it results in deterministic SQL. However, for some advanced cases, the sql_mode can be configured on the database connection via the configuration API (see `MySQLDatabase::$sql_mode` for more details.) This setting is only available in Silverstripe CMS 4.7 and later.
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
## 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 )).
2020-02-14 03:23:20 +01:00
This whitelist uses the same defaults configured through file upload
through SilverStripe, so is considered a second line of defence.
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
### 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.
2020-02-14 03:23:20 +01:00
### Web Worker Concurrency
It's generally a good idea to run multiple workers to serve multiple HTTP requests
to SilverStripe concurrently. The exact number depends on your website needs.
The CMS attempts to request multiple views concurrently.
It also routes [protected and draft files ](/developer_guides/files/file_security )
through SilverStripe. This can increase your concurrency requirements,
e.g. when authors batch upload and view dozens of draft files in the CMS.
When allowing upload of large files through the CMS (through PHP settings),
these files might be used as [protected and draft files ](/developer_guides/files/file_security ).
Files in this state get served by SilverStripe rather than your webserver.
Since the framework uses [PHP streams ](https://www.php.net/manual/en/ref.stream.php ),
this allows serving of files larger than your PHP memory limit.
Please be aware that streaming operations don't count towards
PHP's [max_execution_time ](https://www.php.net/manual/en/function.set-time-limit.php ),
which can risk exhaustion of web worker pools for long-running downloads.
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
### 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.
2020-07-29 04:28:20 +02:00
Silverstripe relies on the `Host` header to construct URLs such as "reset password" links,
so you'll need to ensure that the systems hosting it only allow valid values for this header.
See [Developer Guide: Security - Request hostname forgery ](/developer_guides/security/secure_coding#request-hostname-forgery ).
### CDNs and other Reverse Proxies
If your Silverstripe site is hosted behind multiple HTTP layers,
you're in charge of controlling which forwarded headers are considered valid,
2020-07-29 19:44:20 +02:00
and which IPs can set them. See [Developer Guide: Security - Request hostname forgery ](/developer_guides/security/secure_coding#request-hostname-forgery ).
2020-07-29 04:28:20 +02: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
### 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` .
2020-10-22 04:01:30 +02:00
The default `public/.htaccess` file is configured to have Apache serve those pages based on their HTTP status code.
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
### 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.
2020-10-22 04:01:30 +02:00
In particular, configure protected assets correctly to avoid exposing draft or protected files uploaded through the CMS.
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
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
2020-10-22 04:01:30 +02:00
* 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
2020-10-22 04:01:30 +02:00
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.
