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.
* API Revert addition of Extensible::flush_extra_methods_cache() and change to ExtensionTestState
This reverts the changes from #8465 and #8505 that relate to ExtensionTestState and the
tracking of extra methods between unit tests. The existing test from #8465 testing
overloaded Extensions after extra_methods are populated has been updated to show that you
must re-add the extension to flush the extra_methods cache if you need this behaviour.
* Revert change to InjectorTest::testExtendedExtensions
* Revert "Add failing test to show that overloaded extensions are broken in Extensible"
This reverts commit 55e79ffdfd.
* DOCS Add docs for extending extensions, and upgrade guide note to 4.3 to avoid using PHP config to do so
* MINOR: Add `Previous`, `Next` and `Create New` actions in edit form
If the form is opened via a grid field, the filters will be retained so the previous/next record opened will be correct
* MINOR: Add ability to customise the visibility of the `Previous`, `Next` and `Add` buttons at a `GridField` level
* Fix invalid action when pressing the `New` button in an edit form unless `betterbuttons` module was installed
* - Merge `showPrevious` and `showNext` to `showPagination` for grid fields
- Update documentation
- Improve performance for next/previous buttons by not fetching all list records
- Refactoring
* Refactor to fail gracefully on GridFieldPaginator
* BUGFIX many many through not sorting by join table
* #8534 added docs to support many many sorting fix
* #8534 added test cases for many_many default sorting
* BUGFIX many many through not sorting by join table
* #8534 added docs to support many many sorting fix
* #8534 added test cases for many_many default sorting
This variant of showqueries will include a backtrace after each query.
This is extremely verbose but can be helpful when diagnosing where
queries have come from.
This is something that I have frequently added as a local hack on my
environment, I figured that exposing it as a formal feature would be
useful.
* Allow use of display names with SwiftMailer
The syntax to allow display names with SwiftMailer is as follow:
`->setFrom(['john@doe.com' => 'John Doe'])`
Just like you set the `Email.admin_email`, you can set the default sender display name through the `Email.admin_email_displayname` configuration setting.
Refs:
- https://swiftmailer.symfony.com/docs/introduction.html#basic-usage
- https://docs.silverstripe.org/en/4/developer_guides/email/#administrator-emails
* Update Email.php
Simpler code using `Email.admin_email` as an associative array
* Update index.md
Added documentation showing how to add an email display name.
The ` $has_one` can be used both for `1-to-1` and `many-to-1` relations, depending on how is configured the inverse mapping on the related class. The documentation seems to suggest that `$has_one` implies a `1-to-1` relation, but then it gives an example of a `many-to-1` relationship. Since we are focusing on `$has_one` I would also put the `Player` class before the `Team` class.
I felt the negation docs didn't cover checking if a value was *not* another value and didn't point out that `not` can't be combined with other operators.
[ci skip]
- Stronger wording around "use composer"
- Consistent domain and email address naming
- Removed example for publishing non-composer modules (those shouldn't be encouraged)
- Removed instructions for installing modules from archives
[ci skip]
* WIP GridField action menu work, the gist of the idea is using a new gridfield component
* Add delete action to actions menu
* Actions are added automatically to action menu (allows for extension)
* Add test and minor changes
* Add docs and minor changes
* Refactor ActionMenuItem into distinct types, general ActionMenu cleanup
* Add icons and fix title
* Pass columnName, so it can be used by components
* Update test to open and find action menu buttons
* Add section in changelog upgrade section for GridField_ActionMenu
