[create-pull-request] automated change

Author: shopwareBot

resources/references/adr/2020-06-25-implement-architecture-decision-records.md

@@ -3,7 +3,7 @@ title: Implement architecture decision records
 date: 2020-06-25
 area: core
 tags: [adr, workflow]
---- 
+---
 
 # Implement architecture decision records
 
@@ -53,7 +53,7 @@ The ADRs are markdown files inside the platform repository, located in the "adr"
    *  One developer must be a member of the core development team
    *  One developer must be a member of a team, other than the team of the creator
 * One product owner or higher role has to approve an ADR
-** This part of the decision is superseded by [2021-11-05 - Adjust ADR approval rules for the new org structure](2021-11-05-adjust-ADR-approval-rules.md), but the rest of this ADR is untouched.**
+** This part of the decision is superseded by [2021-11-05 - Adjust ADR approval rules for the new org structure](2021-11-05-adjust-adr-approval-rules.md), but the rest of this ADR is untouched.**
 
 **Should counter decisions also be documented?**   
 Not specific, but if there is more than one possible solution, all options should be outlined.
@@ -73,4 +73,3 @@ The status of an ADR is symbolized by the directory. All ADR located in the main
 
 **Can an ADR be changed?**  
 When an ADR is accepted and merged in to the code, it can no longer be changed. If a decision is outdated or has to be changed, the ADR has to be superseded by a new ADR. Superseded ADRs have to be moved to the `/adr/_superseded` directory.
-

resources/references/adr/2020-07-02-control-clone-behavior.md

@@ -3,7 +3,7 @@ title: Get control of association clone behavior as developer
 date: 2020-07-02
 area: core
 tags: [repository, entity, clone, flag, association]
---- 
+---
 
 # Get control of association clone behavior as developer
 

resources/references/adr/2020-07-02-implement-sales-channel-context-token-requirement.md

@@ -3,7 +3,7 @@ title: Implement sales channel context token requirement for store-api and sales
 date: 2020-07-02
 area: core
 tags: [context, token, sales-channel, store-api, sales-channel-api, api]
---- 
+---
 
 # Implement sales channel context token requirement for store-api and sales-channel-api
 

resources/references/adr/2020-08-03-implement-new-changelog.md

@@ -3,7 +3,7 @@ title: Implement new changelog
 date: 2020-08-03
 area: core
 tags: [changelog]
---- 
+---
 
 # Implement new changelog
 
@@ -118,4 +118,3 @@ If you just want to get the changes of a specific version or even just a special
 `bin/console changelog:change [<version>] [options]`
 
 Use the `--help` flag of the command to see all possible options.
-

resources/references/adr/2020-08-12-document-template-refactoring.md

@@ -3,7 +3,7 @@ title: Document template refactoring
 date: 2020-08-12
 area: customer-order
 tags: [document, template, twig]
---- 
+---
 
 # Document template refactoring
 

resources/references/adr/2020-08-12-implement-app-system-inside-platform.md

@@ -3,7 +3,7 @@ title: Implement app system inside platform
 date: 2020-08-12
 area: core
 tags: [app, cloud]
---- 
+---
 
 # Implement app system inside platform
 
@@ -56,7 +56,7 @@ Additionally, the storefront theme files (JS and CSS) only need to be accessed d
 
 * [Custom Fields](https://docs.shopware.com/en/shopware-platform-dev-en/app-system-guide/app-base-guide?category=shopware-platform-dev-en/app-system-guide#custom-fields): An app can register it's own custom fields sets, that are displayed along the other custom fields inside the administration.
 
-* [Storefront Customizations](https://docs.shopware.com/en/shopware-platform-dev-en/app-system-guide/app-examples-and-tutorials/create-own-theme?category=shopware-platform-dev-en/app-system-guide/app-examples-and-tutorials): An app should be able to customize the storefront in the same way a plugin does. This includes the theme system, custom twig templates and custom JS and CSS.
+* [Storefront Customizations](https://developer.shopware.com/docs/guides/plugins/apps/storefront/): An app should be able to customize the storefront in the same way a plugin does. This includes the theme system, custom twig templates and custom JS and CSS.
 In regard to the theme system apps are treated the same way as plugins are, especially regarding the theme inheritance. Apps can be explicitly set in the inheritance chain via `@TechnicalAppName`, if they are not referenced directly they are part of the fallback `@Plugins` namespace.
 
 Extension points may be added as new features of the app system, but we have to make sure that it does not violate one of the limitations mentioned above. Additionally, it needs to be taken into account that it's possible to deploy and run that feature in the cloud environment.

resources/references/adr/2020-08-14-implement-individual-sorting.md

@@ -3,7 +3,7 @@ title: Implement individual sorting
 date: 2020-08-14
 area: core
 tags: [repository, dal, entity, sort, product]
---- 
+---
 
 # Implement individual sorting
 

resources/references/adr/2020-08-14-merchant-registration.md

@@ -3,7 +3,7 @@ title: Merchant registration
 date: 2020-08-14
 area: customer-order
 tags: [merchant, registration, customer-group]
---- 
+---
 
 # Merchant registration
 

resources/references/adr/2020-08-21-unified-notification-titles.md

@@ -3,7 +3,7 @@ title: Notification titles are pre-defined and make use of the global namespace
 date: 2020-08-21
 area: administration
 tags: [administration, notification]
---- 
+---
 
 # Notification titles are pre-defined and make use of the global namespace
 
@@ -14,8 +14,8 @@ You can find the original version [here](https://github.com/shopware/platform/bl
 
 ## Context
 
-* Creating notifications messages in the administration caused the effort of making up not only a title but a message too.
-This has led to inconsistent notification appearances. In some cases the notification message simply duplicated the title, 
+* Creating notification messages in the administration caused the effort of making up not only a title but a message too.
+This has led to inconsistent notification appearances. In some cases, the notification message simply duplicated the title; 
 others wore the module's name as a title and so on.
 
 * Now, since it is a set design decision to use the following four types of notification as titles at the same time, 
@@ -39,7 +39,7 @@ it is just logical to make use of the global namespace and manage notification t
 * By introducing the global namespace as early as in the `notification.mixin.js`
 it is now unnecessary to define individual titles when implementing notifications within a module.
 * Notifications from now on only require a "notification message" and thus the creation of only snippet within each snippet file (en-GB and de-DE).
-* Consequently a whole bunch of unnused snippets have been removed.
+* Consequently, a bunch of unused snippets have been removed.
 For more information on snippets deleted in this course see CHANGELOG-6.3.md
 
 ### Examples
@@ -66,7 +66,7 @@ this.createNotificationError({
 * Messages should be translatable, precise and not redundant. An error notification's title literally says: "Error" - no need in repeating that. 
 Better find and present information on what exactly went wrong.
 
-* Make use of success notifications, but make them carry useful information, by e.g. including counters.
+* Make use of success notifications, but make them carry useful information, by e.g., including counters.
 
 * Make use of info and warning notifications to keep users informed about things that are ongoing or need a closer look!
 
@@ -78,6 +78,3 @@ It would cross the design idea of unified titles though and should only be consi
 > *When creating notifications, just decide on the correct type of notification, 
  add a meaningful message, don't waste even a thought on creating a title...
  And you're done!*
-
-
-

resources/references/adr/2020-08-28-import-acl-privileges-from-other-roles.md

@@ -3,7 +3,7 @@ title: Import ACL privileges from other roles
 date: 2020-08-28
 area: administration
 tags: [acl, privileges, dependency, administration]
---- 
+---
 
 # Import ACL privileges from other roles