Merge branch '5' into 6

.github/workflows/keepalive.yml

@@ -1,17 +1,21 @@
 name: Keepalive
 
 on:
-  # At 10:50 AM UTC, on day 3 of the month
+  # At 3:15 AM UTC, on day 16 of the month
   schedule:
-    - cron: '50 10 3 * *'
+    - cron: '15 3 16 * *'
   workflow_dispatch:
 
+permissions: {}
+
 jobs:
   keepalive:
     name: Keepalive
     # Only run cron on the silverstripe account
     if: (github.event_name == 'schedule' && github.repository_owner == 'silverstripe') || (github.event_name != 'schedule')
     runs-on: ubuntu-latest
+    permissions:
+      actions: write
     steps:
       - name: Keepalive
         uses: silverstripe/gha-keepalive@v1

.github/workflows/merge-up.yml

@@ -1,17 +1,22 @@
 name: Merge-up
 
 on:
-  # At 10:50 AM UTC, only on Tuesday
+  # At 3:15 AM UTC, only on Monday
   schedule:
-    - cron: '50 10 * * 2'
+    - cron: '15 3 * * 1'
   workflow_dispatch:
 
+permissions: {}
+
 jobs:
   merge-up:
     name: Merge-up
     # Only run cron on the silverstripe account
     if: (github.event_name == 'schedule' && github.repository_owner == 'silverstripe') || (github.event_name != 'schedule')
     runs-on: ubuntu-latest
+    permissions:
+      contents: write
+      actions: write
     steps:
       - name: Merge-up
         uses: silverstripe/gha-merge-up@v1

en/02_Developer_Guides/01_Templates/01_Syntax.md

@@ -293,6 +293,18 @@ page.
 > This demonstrates the concept of scope ([see scope below](#scope)). When inside a `<% loop %>` the scope of the template has changed to the
 > object that is being looped over.
 
+You can also use `<% loop %>` without explicitly saying what to loop over. This will result in looping over whatever is currently in scope.
+
+This can be particularly useful when you have collections within collections.
+
+```ss
+<% loop $MyLists %>
+  <% loop %>
+      This is looping over each of the collections that are contained inside the \$MyLists collection.
+  <% end_loop %>
+<% end_loop %>
+```
+
 ### Altering the list
 
 `<% loop %>` statements often iterate over [`SS_List`](api:SilverStripe\ORM\SS_List) instances. As the template has access to the list object,

en/08_Changelogs/5.3.0.md

@@ -67,9 +67,16 @@ This is particularly helpful if you need to update columns in one table to match
 - `silverstripe/linkfield` now has improved accessibility support for screen readers and keyboard navigation. Focus states have also been made consistent between keyboard and mouse interaction.
 - `silverstripe/graphql-devtools` contains a new `GraphQLSchemaInitTask` to help you initialise a basic GraphQL schema.
 - [`GridFieldDetailForm_ItemRequest`](api:SilverStripe\Forms\GridField\GridFieldDetailForm_ItemRequest) now uses a [`PjaxResponseNegotiator`](api:SilverStripe\Control\PjaxResponseNegotiator) to handle PJAX responses for the save and publish actions. This aligns it with responses from other form submissions in the CMS.
+- Primitive types inside an iterable object will now be automatically converted to relevant [`DBField`](api:SilverStripe\ORM\FieldType\DBField) types so can be rendered in a template. This allows the use of `return ArrayList::create(['lorem', 123]);` from a [`ContentController`](api:SilverStripe\CMS\Controllers\ContentController) method that is then looped over in a template.
+
+## API changes
+
+Passing a non-array `$fields` argument to both [`FieldList::addFieldsToTab()`](api:SilverStripe\Forms\FieldList::addFieldsToTab()) and [`FieldList::removeFieldsFromTab()`](api:SilverStripe\Forms\FieldList::removeFieldsFromTab()) has been deprecated.
 
 ## Bug fixes
 
+- If you use `<% loop %>` in your templates without telling it what to loop, previously the behaviour was to fail silently. This will now loop over what is currently in scope. See [looping over lists](/developer_guides/templates/syntax/#looping-over-lists) for more details.
+
 This release includes a number of bug fixes to improve a broad range of areas. Check the change logs for full details of these fixes split by module. Thank you to the community members that helped contribute these fixes as part of the release!
 
 ### Sanitisation of HTML

en/10_Contributing/02_Documentation.md

@@ -93,30 +93,53 @@ yarn lint --fix
 
 ## Writing style
 
-- Write in second person form, addressing the reader. For example "First you'll install a webserver" is good style.
-- If referring to maintainers of Silverstripe CMS, either explicitly say "the maintainers", or write in second person plural form (use "we" instead of "I").
-- Use gender neutral language throughout the document, unless referencing a specific person. Use them, they, their, instead of he and she, his or her.
-- Use simple language and words. Avoid uncommon jargon and overly long words. Remember that not everyone speaks English as their primary language.
-- Use UK English, not US English. Silverstripe CMS is proudly a New Zealand open source project we use the UK spelling and forms of English. The most common of these differences are -ize vs -ise, or -or vs our (eg color vs colour).
-- Write in an active and direct voice.
+### Voice and tone
+
+- Use an active voice.
+- Use plain language for easier comprehension. Avoid uncommon jargon and overly long words. Remember that not everyone speaks English as their primary language.
+- Keep sentences clear and concise.
+
+### Content structure
+
+- Structure content around a single topic.
+- Use appropriate markdown. The use of code blocks, lists, tables and callout blocks make technical writing easier to scan.
+- Use descriptive headings and subheadings organised in a hierarchy.
+- Avoid FAQs as they are not a replacement for coherent, well explained documentation.
+
+### Language and grammar
+
+- Use UK English. The most common differences are -ize vs -ise, and -or vs -our (eg color vs colour).
+- Spell out acronyms the first time, with the abbreviation in brackets.
+  - If an acronym is well established, such as "API", you don't need to spell it out.
+- Use gender-neutral language and singular "they" instead of "he/she/his/her".
 - Avoid saying words like "obviously" or "of course". Things that are obvious to you as the writer may not be so obvious to the person reading the documentation.
-- Avoid FAQs. FAQs are not a replacement for coherent, well explained documentation. If you've done a good job
-documenting, there shouldn't be any "frequently asked questions" left.
+- Use meaningful link text, i.e. avoid the use of "click here" link text.
+- Use i.e. and e.g. with dots.
 - We use sentence case for titles. Only capitalise the first letter of the first word of a title. The only exceptions to this are when using brand names (e.g. GitHub), acronyms (e.g. PHP) and class names (e.g. `ModelAdmin`).
-- Use `example.com` as the domain of sample URLs and `example.org` and `example.net` when additional domains are required. All of these domains are [reserved by the IANA](https://tools.ietf.org/html/rfc2606#section-3).
-- Use appropriate markdown. The use of code blocks, emphasis, lists, and tables make technical writing easier to scan.
-- Never leave spaces at the end of a line.
-- Use an empty line to separate paragraphs.
-- Sentence case your bullet points. If a bullet point is a full sentence then end with a full stop. If it is a sentence fragment or a comma separated list, full stops are not required.
-- All code blocks must have an appropriate syntax highlighting hint. For plain text, use "text".
+
+### Code blocks
+
+- All code fences must have an appropriate syntax highlighting hint. Use `text` for plain text.
+- Do not put a `$` in front of lines of bash code examples.
+- Code examples must follow [coding conventions](/contributing/coding_conventions/) for that language.
+- Use `App` when the code requires a vendor name (e.g. as the root for namespaces).
 - If it's useful to include the filename that a code block relates to, do so in a comment in the first line of the code block.
   - Don't place a blank line after this comment, unless the next line is also a comment.
-- Code examples should follow our [coding conventions](./coding_conventions).
-- Use `App` when the code requires a vendor name (e.g. as the root for namespaces).
-- Do not put a `$` in front of lines of bash code examples.
-- When referencing directories, always add a trailing slash to avoid confusions with regular files.
-- "Silverstripe CMS" is used to refer to the Silverstripe CMS open source project as a whole.
-- "Silverstripe" is used to refer to the company, where appropriate.
+
+### References to various things
+
+- Add a trailing slash to directory references to distinguish from regular files.
+- [Link to Silverstripe API docs](#links-to-api-documentation) for the first reference to a Silverstripe PHP class on a page. For subsequent references, use just the class name surrounded with backticks.
+- Use `example.com` as the domain of sample URLs and `example.org` and `example.net` when additional domains are required. All of these domains are [reserved by the IANA](https://tools.ietf.org/html/rfc2606#section-3).
+- Spell "Silverstripe" with an uppercase 'S' at the beginning and a lowercase 's' in the middle.
+- Refer to the company as "Silverstripe."
+- Use "Silverstripe CMS" to refer to the Silverstripe CMS open source project as a whole
+- If referring to maintainers of Silverstripe CMS, either explicitly say "the maintainers", or write in second person plural form (use "we" instead of "I").
+
+### Markdown linting
+
+- Documentation will be automatically linted in CI.
+- Many of the linting rules are not mentioned in this writing style guide, though all linting rules will need to be adherred to in order for your documentation pull-request to be merged. The failed linting CI build will clearly highlight what needs to be fixed.
 
 ## Extended markdown syntax