DOC Update references to CMS 3 and 4

For CMS5 docs, we don't care about CMS3.
silverstripe · Aug 9, 2022 · c8dc5b9 · c8dc5b9
1 parent e933bce
commit c8dc5b9
Show file tree

Hide file tree

Showing 22 changed files with 37 additions and 2,568 deletions.
diff --git a/en/02_Developer_Guides/00_Model/08_SQL_Select.md b/en/02_Developer_Guides/00_Model/08_SQL_Select.md
@@ -14,7 +14,7 @@ This object is used by the Silverstripe CMS ORM internally.
 
 Dealing with low-level SQL is not encouraged, since the ORM provides
 powerful abstraction APIs (see [datamodel](/developer_guides/model/data_model_and_orm)). 
-Starting with Silverstripe CMS 3, records in collections are lazy loaded,
+Records in collections are lazy loaded,
 and these collections have the ability to run efficient SQL
 such as counts or returning a single column.
 

diff --git a/en/02_Developer_Guides/01_Templates/06_Themes.md b/en/02_Developer_Guides/01_Templates/06_Themes.md
@@ -75,7 +75,7 @@ A `theme` within Silverstripe CMS is simply a collection of templates and other
 
 ![themes:basicfiles.gif](../../_images/basicfiles.gif)
 
-Silverstripe CMS 4 has support for cascading themes, which will allow users to define multiple themes for a project. This means you can have a template defined in any theme, and have it continue to look back through the list of themes until a match is found.
+Silverstripe CMS has support for cascading themes, which will allow users to define multiple themes for a project. This means you can have a template defined in any theme, and have it continue to look back through the list of themes until a match is found.
 
 To define extra themes simply add extra entries to the `SilverStripe\View\SSViewer.themes` configuration array. You will probably always want to ensure that you include `'$default'` in your list of themes to ensure that the base templates are used when required.
 

diff --git a/en/02_Developer_Guides/02_Controllers/05_Middlewares.md b/en/02_Developer_Guides/02_Controllers/05_Middlewares.md
@@ -8,10 +8,6 @@ summary: Create objects for modifying request and response objects across contro
 HTTP Middlewares allow you to add code that will run before or after a request has been delegated to the router. These might be used for
 authentication, logging, caching, request processing, and many other purposes.
 
-[notice]
-Note this interface replaces the Silverstripe CMS 3 interface [RequestFilter](api:SilverStripe\Control\RequestFilter), which still works but is deprecated.
-[/notice]
-
 To create a middleware class, implement `SilverStripe\Control\Middleware\HTTPMiddleware` and define the
 `process(HTTPRequest $request, callable $delegate)` method. You can do anything you like in this
 method, but to continue normal execution, you should call `$response = $delegate($request)`

diff --git a/en/02_Developer_Guides/04_Configuration/00_Configuration.md b/en/02_Developer_Guides/04_Configuration/00_Configuration.md
@@ -218,7 +218,7 @@ bitwise `|` operator.
 ## Configuration YAML Syntax and Rules
 
 [alert]
-As of Silverstripe 4, YAML files can no longer be placed any deeper than 2 directories deep. As this was an unintended bug, this change will only affect you if you nest your modules deeper than the top level of your project.
+YAML files can no longer be placed any deeper than 2 directories deep. This will only affect you if you nest your modules deeper than the top level of your project.
 [/alert]
 
 Each module can have a directory immediately underneath the main module directory called `_config/`. Inside this 

diff --git a/en/02_Developer_Guides/06_Testing/04_Fixtures.md b/en/02_Developer_Guides/06_Testing/04_Fixtures.md
@@ -189,7 +189,7 @@ test.
 
 ### Fixtures for namespaced classes
 
-As of Silverstripe CMS 4 you will need to use fully qualified class names in your YAML fixture files. In the above examples, they belong to the global namespace so there is nothing requires, but if you have a deeper DataObject, or it has a relationship to models that are part of the framework for example, you will need to include their namespaces:
+You will need to use fully qualified class names in your YAML fixture files. In the above examples, they belong to the global namespace so there is nothing requires, but if you have a deeper DataObject, or it has a relationship to models that are part of the framework for example, you will need to include their namespaces:
 
 
 ```yml

diff --git a/en/02_Developer_Guides/07_Debugging/01_Error_Handling.md b/en/02_Developer_Guides/07_Debugging/01_Error_Handling.md
@@ -12,6 +12,11 @@ configurations: one for development environments, and another for test or live e
 environments, Silverstripe CMS will deal harshly with any warnings or errors: a full call-stack is shown and execution
 stops for anything, giving you early warning of a potential issue to handle.
 
+[info]
+There are a range of monolog handlers available, both in the core package and in add-ons. See the
+[Monolog documentation](https://github.com/Seldaek/monolog/blob/master/doc/01-usage.md) for more information.
+[/info]
+
 ## Raising errors and logging diagnostic information.
 
 For general purpose logging, you can use the Logger directly. The Logger is a PSR-3 compatible LoggerInterface and
@@ -327,12 +332,5 @@ You should include any functions or methods here which have arguments that may b
 module that other developers may use, it is best practice to include this configuration in the module. Developers should
 not be expected to scan every Silverstripe module they use and add those declarations in their project configuration.
 
-## Differences from Silverstripe CMS 3
-
-In Silverstripe CMS 3, logging was based on the Zend Log module. Customisations were added using `SS_Log::add_writer()`.
-This function no longer works, and any Zend Log writers will need to be replaced with Monolog handlers. Fortunately,
-a range of handlers are available, both in the core package and in add-ons. See the
-[Monolog documentation](https://github.com/Seldaek/monolog/blob/master/doc/01-usage.md) for more information.
-
 ## Related Lessons
 * [Advanced environment configuration](https://www.silverstripe.org/learn/lessons/v4/advanced-environment-configuration-1)
diff --git a/en/02_Developer_Guides/09_Security/04_Secure_Coding.md b/en/02_Developer_Guides/09_Security/04_Secure_Coding.md
@@ -710,7 +710,7 @@ following in your .htaccess to ensure this behaviour is activated.
 </IfModule>
 ```
 
-As of Silverstripe CMS 4, this behaviour is on by default, and the environment variable is no longer required. For correct operation, it is necessary to always set `SS_TRUSTED_PROXY_IPS` if using a proxy.
+This behaviour is on by default; the environment variable is not required. For correct operation, it is necessary to always set `SS_TRUSTED_PROXY_IPS` if using a proxy.
 
 ## Secure Sessions, Cookies and TLS (HTTPS)
 

diff --git a/en/02_Developer_Guides/10_Email/index.md b/en/02_Developer_Guides/10_Email/index.md
@@ -12,7 +12,7 @@ Creating and sending email in Silverstripe CMS is done through the [Email](api:S
 
 Silverstripe CMS provides an API over the top of the [SwiftMailer](http://swiftmailer.org/) PHP library which comes with an extensive list of "transports" for sending mail via different services. 
 
-For legacy reasons, Silverstripe CMS 4 defaults to using the built-in PHP `mail()` command via a deprecated class `Swift_MailTransport`. However, using this layer is less secure and is strongly discouraged.
+For legacy reasons, Silverstripe CMS defaults to using the built-in PHP `mail()` command via a deprecated class `Swift_MailTransport`. However, using this layer is less secure and is strongly discouraged.
 
 It's highly recommended you upgrade to a more robust transport for additional security. The Sendmail transport is the most common one. The `sendmail` binary is widely available across most Linux/Unix servers.