From f3e732267308e0ec76ff439571558de14903fadf Mon Sep 17 00:00:00 2001
From: Lukas Erni <le@kraftausdruck.ch>
Date: Tue, 19 Nov 2024 15:50:49 +0100
Subject: [PATCH] Change JS MIME Type & Remove Default type in <script>
 https://github.com/silverstripe/silverstripe-framework/pull/11446, fix few
 typos

---
 en/08_Changelogs/6.0.0.md | 21 ++++++++++++++++-----
 1 file changed, 16 insertions(+), 5 deletions(-)

diff --git a/en/08_Changelogs/6.0.0.md b/en/08_Changelogs/6.0.0.md
index acdd6cab..a8371045 100644
--- a/en/08_Changelogs/6.0.0.md
+++ b/en/08_Changelogs/6.0.0.md
@@ -36,6 +36,7 @@ title: 6.0.0 (unreleased)
   - [MySQL now defaults to utf8mb4](#mysql-utf8mb4)
   - [`DBDecimal` default value](#dbdecimal-default-value)
   - [`RedirectorPage` validation](#redirectorpage-validation)
+  - [Change JS MIME Type & Remove Default `type` Attribute in `<script>` Tags](#change-js-mime-type)
 - [Full list of removed and changed API (by module, alphabetically)](#api-removed-and-changed)
 
 ## Features and enhancements
@@ -44,9 +45,9 @@ title: 6.0.0 (unreleased)
 
 [`DBField`](api:SilverStripe\ORM\FieldType\DBField) is the base class for all database fields in Silverstripe CMS. For instance when you defined `'MyField' => 'Varchar(255)'` in your [`DataObject`](api:SilverStripe\ORM\DataObject) subclass, the `MyField` property would be an instance of [`DBVarchar`](api:SilverStripe\ORM\FieldType\DBVarchar).
 
-Validation has added been to most `DBField` subclasses. This means that when a value is set on a `DBField` subclass, it will be validated against the constraints of that field. This field validation is called as part of [`DataObject::validate()`](api:SilverStripe\ORM\DataObject::validate()) which itself is called as part of [`DataObject::write()`](api:SilverStripe\ORM\DataObject::write()). If a value is invalid then a [`ValidationException`](api:SilverStripe\ORM\Validation\ValidationException) will be thrown.
+Validation has been added to most `DBField` subclasses. This means that when a value is set on a `DBField` subclass, it will be validated against the constraints of that field. This field validation is called as part of [`DataObject::validate()`](api:SilverStripe\ORM\DataObject::validate()) which itself is called as part of [`DataObject::write()`](api:SilverStripe\ORM\DataObject::write()). If a value is invalid then a [`ValidationException`](api:SilverStripe\ORM\Validation\ValidationException) will be thrown.
 
-For example, if you have a `Varchar(64)`, and you try to set a value longer than 64 characters, a exception will now be thrown. Previously, the value would be truncated to 64 characters and saved to the database.
+For example, if you have a `Varchar(64)`, and you try to set a value longer than 64 characters, an exception will now be thrown. Previously, the value would be truncated to 64 characters and saved to the database.
 
 The validation is added through subclasses of the new [`FieldValidator`](api:SilverStripe\Core\Validation\FieldValidation\FieldValidator) abstract class, for instance the [`StringFieldValidator`](api:SilverStripe\Core\Validation\FieldValidation\StringFieldValidator) is used to validate [`DBVarchar`](api:SilverStripe\ORM\FieldType\DBVarchar).
 
@@ -345,7 +346,7 @@ We've removed this functionality. Please use an appropriate daemon tool such as
 
 Read-only replicas are additional databases that are used to offload read queries from the primary database, which can improve performance by reducing the load on the primary database.
 
-Read-only replicas are configured by adding environment variables that match the primary environment variable and suffixing `_REPLICA_<replica-number>` to the variable name, where `<replica_number>` is the replica number padding by a zero if it's less than 10, for example `SS_DATABASE_SERVER` becomes `SS_DATABASE_SERVER_REPLICA_01` for the first replica, or `SS_DATABASE_SERVER_REPLICA_12` for the 12th replica. Replias must be numbered sequentially starting from `01`.
+Read-only replicas are configured by adding environment variables that match the primary environment variable and suffixing `_REPLICA_<replica-number>` to the variable name, where `<replica_number>` is the replica number padding by a zero if it's less than 10, for example `SS_DATABASE_SERVER` becomes `SS_DATABASE_SERVER_REPLICA_01` for the first replica, or `SS_DATABASE_SERVER_REPLICA_12` for the 12th replica. Replicas must be numbered sequentially starting from `01`.
 
 Replicas cannot define different configuration values for `SS_DATABASE_CLASS`, `SS_DATABASE_NAME`, or `SS_DATABASE_CHOOSE_NAME`. They are restricted to prevent strange issues that could arise from having inconsistent database configurations across replicas.
 
@@ -632,7 +633,7 @@ The `tree_class` configuration property on `LeftAndMain` and its subclasses has
 
 A new [`SingleRecordAdmin`](api:SilverStripe\Admin\SingleRecordAdmin) class has been created which makes it easier to create an admin section for editing a single record.
 
-This is the new super class for [`SiteConfigLeftAndMain`](api:SilverStripe\SiteConfig\SiteConfigLeftAndMain) and [`CMSProfileController`](api:SilverStripe\Admin\CMSProfileController). Some of the CSS selectors that had been added to the edit forms in those classes are no longer avaialable - if you were using CSS selectors in those admin sections, you may need to change the way you're handling that.
+This is the new super class for [`SiteConfigLeftAndMain`](api:SilverStripe\SiteConfig\SiteConfigLeftAndMain) and [`CMSProfileController`](api:SilverStripe\Admin\CMSProfileController). Some of the CSS selectors that had been added to the edit forms in those classes are no longer available - if you were using CSS selectors in those admin sections, you may need to change the way you're handling that.
 
 As part of this change, we have removed the `updateCurrentSiteConfig` extension hook on [`SiteConfig`](api:SilverStripe\SiteConfig\SiteConfig) and updated the `canDelete()` permissions on `SiteConfig` to explicitly return `false` by default, even for administrators.
 
@@ -916,12 +917,22 @@ SilverStripe\ORM\Connect\MySQLDatabase:
 
 ### `DBDecimal` default value {#dbdecimal-default-value}
 
-Previously if an invalid default value was provided for a [`DBDecimal`](api:SilverStripe\ORM\FieldType\DBDecimal) database column, it would silently set the defalt value to `0`. This will now throw an exception instead, so that you're aware your configured value is invalid and can correct it.
+Previously if an invalid default value was provided for a [`DBDecimal`](api:SilverStripe\ORM\FieldType\DBDecimal) database column, it would silently set the default value to `0`. This will now throw an exception instead, so that you're aware your configured value is invalid and can correct it.
 
 ### `RedirectorPage` validation
 
 [`RedirectorPage`](api:SilverStripe\CMS\Model\RedirectorPage) now uses the [`Url` constraint](https://symfony.com/doc/current/reference/constraints/Url.html) from `symfony/validator` to validate the `ExternalURL` field. It will no longer add `http://` to the start of URLs for you if you're missing a protocol - instead, a validation error message will be displayed.
 
+### Change JS MIME Type & Remove Default `type` Attribute in `<script>` Tags {#change-js-mime-type}
+
+Updated the MIME type for JavaScript from `"application/javascript"` to `"text/javascript"`. Additionally, the `type` attribute has been omitted from `<script>` tags since it defaults to `"text/javascript"` in HTML5, and it is encouraged to omit it instead of redundantly setting it.
+
+  - **MIME Type Update:**
+    - **Before:** `<script type="application/javascript" src="..."></script>`
+    - **After:** `<script src="..."></script>`
+
+This change is generally backward-compatible and should not affect existing functionality. However, if your project explicitly relies on the `type` attribute for `<script>` tags, you may need to adjust accordingly.
+
 ### Full list of removed and changed API (by module, alphabetically) {#api-removed-and-changed}
 
 <!--- Changes below this line will be automatically regenerated -->