As of SS4.0.0 and the introduction of TrustedProxyMiddleware, the default now if no trusted proxies are defined is that nothing is a trusted proxy, whereas in SS3 a missing declaration was treated as everything being allowed.
* 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)
We decided during implementation not to check permissions explicitly on cascading objects due to performance concerns.
For example, when publishing a page with embedded images, publish permissions on the image are implied - even if Image->canPublish() would return false for this author.
See https://github.com/silverstripe-security/security-issues/issues/57
This is a suggestion to update the docs to use the actual type names used in code. All the examples use the non-DB type names (ie: 'Wheels' => 'Int') but the bulleted list suggests it should be 'Wheels' => 'DBInt'. This is a bit confusing for new SS developers. Could we change this?
I found these errors while going through this tutorial,
missing ```use use SilverStripe\Forms\GridField\GridField;```
interface GridField_ActionMenuItem required parameters on getTitle() and getGroup()
incorrect if statement on getExtraData() - $field is not defined
Currently the email documentation provides an example of how to use the SMTP adapter in SwiftMailer, but this example hardcodes the password in the config file which is a security issue. It is possible to reference environment variables instead, so we should document and encourage this.
* DOCS File migration changes for 4.4.0
See https://github.com/silverstripe/silverstripe-versioned/issues/177
* Update docs/en/02_Developer_Guides/14_Files/03_File_Security.md
Co-Authored-By: chillu <ingo@silverstripe.com>
* Corrected statements on archived/versioned files
* Corrected statement on filesystem paths of protected vs. public
* Update docs/en/02_Developer_Guides/14_Files/03_File_Security.md
Co-Authored-By: chillu <ingo@silverstripe.com>
* Clarify redirect behaviour
Following the example will give the following error;
```[Emergency] Uncaught Error: Class {my namespace}\Permission not found```
Added the missing class
Update example code for disabling anchors on a per-instance basis. The previous code was unclear and statically called a non-static method on SSViewer (presumably this was SS3 code)
* Add missing rollback operation in scaffolding example
* Update block_id references to id to allow query to read query to run successfully in conjunction with HistoryViewerField
Update guidance on form template location. They don't necessarily have to be placed in /app/templates and will work in the theme directory too. The current text also seems to suggest that they can be placed in the core directory - something which I don't believe should be advised,
* NEW Make resources dir configurable.
* Removing reference to old `resources` and updating doc #8519
* Rrtarget to 4.4 release.
* DOC Reference SS_RESOURCES_DIR in Environment doc.
* API Add a Resources method to SilverStripe\Core\Manifest\Module to read the resources-dir from composer.json
* Clean up reference to SS_RESOURCES_DIR env var
* Set default resources-dir
* Update test to use RESOURCES_DIR const in expected resource url method
* Correcting typos
Co-Authored-By: maxime-rainville <maxime@rainville.me>
* MINOR Correctubg minor typos
* DOCS Document the intricacies of exposing static assets.
