Merge branch '4.13' into 4

en/02_Developer_Guides/15_Customising_the_Admin_Interface/02_CMS_Architecture.md

@@ -774,6 +774,38 @@ The URL endpoints `{$AdminURL}mytabs/tab1` and `{$AdminURL}mytabs/tab2`
 should return HTML fragments suitable for inserting into the content area,
 through the `PjaxResponseNegotiator` class (see above).
 
+### Lazy loading fields on tab activation
+
+When a tab is not lazy loaded via ajax, it might still be necessary to
+delay some work (for example when doing HTTP requests) until the tab is activated. This is how, for example, the
+[`GridFieldLazyLoader`](api:SilverStripe\Forms\GridField\GridFieldLazyLoader) works.
+
+In order to open up the same kind of features to other fields, a custom event is fired on all nodes with the `lazy-loadable` class inside the activated tab panel.
+They will receive a `lazyload` event that can be listened to in the following way (you will have to implement your own logic for "loading" the content):
+
+```js
+jQuery('input.myfield.lazy-loadable').entwine({
+  // Use onmatch so we apply the event handler as soon as the element enters the DOM
+  onmatch(e) {
+    // Use the one() function so the lazyload only happens once for this field
+    this.one('lazyload', () => {
+      // Some init code here
+    });
+  },
+});
+```
+
+[info]
+The `myfield` CSS class isn't strictly necessary here (nor is the input for that matter) - it's just being used so we have a more specific selector. That way we know our JavaScript code will only trigger for the relevant element, and not for every lazy-loadable element in the DOM.
+[/info]
+
+If you apply the `myfield` and `lazy-loadable` CSS classes to some form field on a tab other than main, then when you swap to the tab containing that field it will trigger the lazyload event for that element.
+
+```php
+use SilverStripe\Forms\TextField;
+$fields->addFieldToTab('Root.AnyTab', TextField::create('MyField')->addExtraClass('myfield lazy-loadable'));
+```
+
 ## Related
 
 - [Howto: Extend the CMS Interface](/developer_guides/customising_the_admin_interface/how_tos/extend_cms_interface)

en/05_Contributing/00_Issues_and_Bugs.md

@@ -91,7 +91,7 @@ The current GitHub labels are grouped into five sections:
 1. *Impact* - What impact does this issue have, does it break a feature completely, is it just a side effect or is it trivial and not a big problem (but a bit annoying), etc. Impact is evaluated in the context of the CMS as a whole, rather than against the individual module the issue is raised on.
 1. *Complexity* - What level of technical proficiency is required to address this issue?
 1. *Type* - The type of solution required to address this issue
-1. *Affects* - The release line this issue is relevant to
+1. *Affects* - The major release line this issue is relevant to - for instance `silverstripe/admin 2.0.0` is on the CMS 5 major release line, so use `affects/v5`. Do not add this label for unreleased major release lines, instead use `type/api-break`.
 1. *RFC* - The issue is a request-for-comment
 
 | Label | Purpose |
@@ -109,6 +109,7 @@ The current GitHub labels are grouped into five sections:
 | type/ux | Impact on the CMS user interface |
 | type/docs | A docs change |
 | type/userhelp | A userhelp documentation change |
+| type/other | Any issue that does not is not covered by another type label e.g. general maintainence |
 | affects/* | Issue has been observed on a specific CMS release line |
 | rfc/draft | [RFC](/project_governance/request_for_comment) under discussion |
 | rfc/accepted | [RFC](/project_governance/request_for_comment) where agreement has been reached |