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?
This was discussed and agreed in #8556. The two changes are
composer.json and travis. The docs have also been updated. No other
code changes have been made.
* DOCS Update "release numbering" to document the fact that lock step releases are not required
[ci skip]
* DOCS Update "making a SilverStripe core release" to clarify recipe versus module without lock step
Also adds note about peer reviewing the plan before release
[ci skip]
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
* Add `getFieldMap` method to retrieve a list of all fields for any given class
* Add `TagsToShortcodeTask` to upgrading guide
Adding after the file migration part as this is where it makes the most sense to run it.
* `getFieldMap` accepts an array
* Move to `DataObjectSchema`
* Add `HTMLVarchar` to documentation
Minor refactoring
* Add test for checking that `subclassesfor` works without the base class
Add test `DataObjectSchema::getFieldMap` returns the correct array
* Remove cms dependency
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
The upgrading docs reference webconfig.php, which is incorrect and has never existed. I presume the docs mean to reference web.config, which is the IIS configuration file.
I've also fixed a couple of minor spelling mistakes and mentioned Apache for htaccess and IIS for web.config so people know what they're for.
[ci skip]
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
The upgrading docs reference webconfig.php, which is incorrect and has never existed. I presume the docs mean to reference web.config, which is the IIS configuration file.
I've also fixed a couple of minor spelling mistakes and mentioned Apache for htaccess and IIS for web.config so people know what they're for.
[ci skip]
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
We're adopting CVSS (https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator),
which allows us to classify the impact of security issues
based on industry standard metrics.
While there is still a lot of room for interpretation,
it is more objective than our previous system of "critical/high/medium/low",
with one sentence descriptions on how we interpret that "severity rating".
This effectively changes our process to only apply
security fixes to release lines in "limited support" (currently 3.6 and 3.7)
if they're considered "critical" (CVSS > 9.0).
We've already limited preannounces to CVSS >7.0 in these docs.
Moved the guts to "making a core release", since it's only really relevant to that audience.
There's more work to do around making security and non-security releases the same (less special handling),
but I think this is a good start.
[ci-skip]
