chore: creates dev folder and moves pages

.gitbook.yaml

@@ -109,4 +109,34 @@ redirects:
     resources/references/upgrades/core/translation/extension-translation.html: guides/upgrades-migrations/extension-translation.html
     resources/references/upgrades/core/translation/language-pack-migration.html: guides/upgrades-migrations/language-pack-migration.html
     resources/references/upgrades/administration/: guides/upgrades-migrations/administration/
-    resources/references/upgrades/: guides/upgrades-migrations/
+    resources/references/upgrades/: guides/upgrades-migrations/
+    guides/plugins/plugins/testing/php-unit.html: guides/development/testing/unit/php-unit.html
+    guides/plugins/plugins/testing/jest-storefront.html: guides/development/testing/unit/jest-storefront.html
+    guides/plugins/plugins/testing/jest-admin.html: guides/development/testing/unit/jest-admin.html
+    guides/development/testing/ci.html: guides/development/testing/index.html
+    resources/guidelines/testing/store/: guides/development/testing/testing-guidelines/
+    guides/integrations-api/general-concepts/: guides/development/integrations-api/general-concepts/
+    guides/integrations-api/general-concepts/api-versioning.html: guides/development/integrations-api/general-concepts/api-versioning.html
+    guides/integrations-api/general-concepts/request-headers.html: guides/development/integrations-api/general-concepts/request-headers.html  
+    guides/integrations-api/general-concepts/search-criteria.html: guides/development/integrations-api/general-concepts/search-criteria.html
+    guides/integrations-api/general-concepts/partial-data-loading.html: guides/development/integrations-api/general-concepts/partial-data-loading.html
+    guides/integrations-api/general-concepts/generated-reference.html: guides/development/integrations-api/general-concepts/generated-reference.html
+    resources/references/core-reference/dal-reference/filters-reference.html: guides/resources/references/core-reference/dal-reference/filters-reference.html
+    resources/references/core-reference/dal-reference/aggregations-reference.html: guides/resources/references/core-reference/dal-reference/aggregations-reference.html
+    guides/plugins/apps/app-scripts/data-loading.html: guides/integrations-api/general-concepts/search-criteria.html
+    resources/accessibility/accessibility-checklist.html: guides/development/accessibility/accessibility-checklist.html
+    resources/accessibility/storefront-accessibility.html: guides/development/accessibility/storefront-accessibility.html
+    guides/plugins/apps/in-app-purchases.html: guides/development/monetization/in-app-purchases.html
+    guides/plugins/plugins/testing/playwright/actor-pattern.html: guides/development/testing/e2e-playwright/actor-pattern.html
+    guides/plugins/plugins/testing/playwright/best-practices.html: guides/development/testing/e2e-playwright/best-practices.html
+    guides/plugins/plugins/testing/playwright/deployment.html: guides/development/testing/e2e-playwright/deployment.html
+    guides/plugins/plugins/testing/playwright/fixtures.html: guides/development/testing/e2e-playwright/fixtures.html
+    guides/plugins/plugins/testing/playwright/install-configure.html: guides/development/testing/e2e-playwright/install-configure.html
+    guides/plugins/plugins/testing/playwright/language-agnostic-testing.html: guides/development/testing/e2e-playwright/language-agnostic-testing.html
+    guides/plugins/plugins/testing/playwright/local-development.html: guides/development/testing/e2e-playwright/local-development.html
+    guides/plugins/plugins/testing/playwright/page-object.html: guides/development/testing/e2e-playwright/page-object.html
+    guides/plugins/plugins/testing/playwright/test-data-service.html: guides/development/testing/e2e-playwright/test-data-service.html
+    guides/plugins/plugins/testing/playwright/test-suite-types.html: guides/development/testing/e2e-playwright/test-suite-types.html
+    guides/plugins/plugins/testing/playwright/test.html: guides/development/testing/e2e-playwright/test.html
+    guides/plugins/plugins/testing/cypress/cypress-best-practises.html: guides/development/testing/legacy/cypress/cypress-best-practises.html
+    guides/plugins/plugins/testing/cypress/cypress-end-to-end-testing/: guides/development/testing/legacy/cypress/

.wordlist.txt

@@ -631,6 +631,7 @@ ORMs
 OSS
 OTEL
 OTLP
+OWASP
 ObjectField
 ObjectType
 OffCanvas
@@ -1768,6 +1769,7 @@ resolver's
 resolvers
 resubmittable
 rethrown
+retryability
 returnUrl
 revalidation
 rfc

concepts/framework/in-app-purchases.md

@@ -5,13 +5,13 @@
 
 ---
 
-# In-App purchases (IAP)
+# In-App Purchases (IAP)
 
 ::: info
 In-App Purchase is available since Shopware version 6.6.9.0
 :::
 
-In-App Purchases are a way to lock certain features behind a paywall within the same extension.
+In-App Purchases allow you to lock certain features behind a paywall within the same extension.
 This is useful for developers who want to offer a free version of their extension with limited features and a paid version with more features.
 
 ## Creation
@@ -25,7 +25,7 @@
 All bought In-App Purchases are part of the JWT claims.
 
 To verify the JWT signature, you can use the JSON Web Key Set (JWKS) available at [`https://api.shopware.com/inappfeatures/jwks`](https://api.shopware.com/inappfeatures/jwks)
-Shopware automatically verifies the signature for the use within the Core and Admin.
+Shopware automatically verifies the signature for use within the Core and Admin.
 
 Tokens are retrieved when a new purchase is made and during periodic updates.
 You can also manually trigger an update by running the command `bin/console scheduled-task:run-single in-app-purchase.update` or by calling the `/api/_action/in-app-purchases/refresh` endpoint.
@@ -37,12 +37,12 @@
 Whenever Shopware sends a request to the app server, it includes the [IAP JWT](#token).
 The app server can use this token to validate active purchases and unlock related features accordingly.
 
-Plugins are inherently less secure, as their open nature makes them more vulnerable to spoofing or tampering.
+Plugins are inherently less secure because their open nature makes them more vulnerable to spoofing and tampering.
 
-<PageRef page="../../guides/plugins/apps/in-app-purchases" title="In-App purchases for Apps" />
+<PageRef page="../../guides/development/monetization/in-app-purchases" title="In-App purchases for Apps" />
 <PageRef page="../../guides/plugins/plugins/in-app-purchases" title="In-App purchases for Plugins" />
 
-## Checkout Process
+## Checkout process
 
 When integrating In-App Purchases, Shopware handles the entire checkout process for you—including payment processing and subscription management.
 

resources/accessibility/accessibility-checklist.md → guides/development/accessibility/accessibility-checklist.md

@@ -10,101 +10,101 @@
 
 This checklist outlines the key principles and technical requirements for building accessible web interfaces, with a focus on semantic structure, keyboard usability, screen reader compatibility, and inclusive design practices.
 
-## Storefront Accessibility Checklist: Best Practices for Inclusive Web Design
+## Storefront accessibility checklist: Best practices for inclusive web design
 
-### Use Semantic HTML
+### Use semantic HTML
 
 Leverage native HTML elements that communicate their purpose effectively:
 
 - Use appropriate tags for actions: `<button>`, `<a>`, `<select>` instead of `<div>` or `<span>`.
 - Structure your layout with semantic elements: `<nav>`, `<main>`, `<header>`, `<footer>`.
 - Always pair `<label>` elements with form controls using `for` and `id`. Avoid relying solely on `placeholder` text for labeling.
 
-### Set the Correct Document Language
+### Set the correct document language
 
 Proper language settings help screen readers use accurate pronunciation and intonation:
 
 - Add `lang="en"` (or the appropriate language code) to the `<html>` tag.
 
-### Ensure Accessible Forms
+### Ensure accessible forms
 
-All form fields must be clearly labeled and error states must be identifiable:
+All form fields must be clearly labeled, and error states must be identifiable:
 
 - Use `<label for="input-id">`, `aria-label`, or `aria-labelledby`.
 - Provide error messages that are clear and easy to locate.
-- Don’t rely solely on color (e.g., red) to indicate errors. You can use icons or text additionally.
+- Don’t rely solely on color (e.g., red) to indicate errors. You can also use icons or text.
 - Use `aria-describedby` to connect input fields to help or error messages.
 
-### Manage Focus
+### Manage focus
 
 Ensure users know where they are and can move through the interface logically:
 
-- Use `tabindex="0"` for custom interactive elements. Try to not mess around with the tabindex if possible and keep the "natural" tab flow.
-- Do not remove focus outlines unless replaced with a clear visible alternative.
-- Use `focus()` to direct user attention (e.g. after form errors or modal open).
-- Each interactive element that can be clicked or navigated by keyboard (`<a>`, `<button>` etc.) must have a clearly visible focus indication.
+- Use `tabindex="0"` for custom interactive elements. Try not to mess around with the tabindex if possible, and keep the "natural" tab flow.
+- Do not remove focus outlines unless replaced with a clear, visible alternative.
+- Use `focus()` to direct user attention (e.g., after form errors or modal open).
+- Each interactive element that can be clicked or navigated by keyboard (`<a>`, `<button>`, etc.) must have a clearly visible focus indication.
 
-### Keyboard Accessibility
+### Keyboard accessibility
 
 Users should be able to navigate and interact with all features using only the keyboard:
 
 - Ensure `Enter` and `Space` activate interactive elements.
 - Avoid using `onclick` on non-focusable elements without keyboard support.
 - Custom widgets must respond to arrow keys and expected keyboard patterns.
 
-### Use ARIA Carefully
+### Use ARIA carefully
 
 Use ARIA roles and attributes only when native HTML doesn’t work.
 
 - Use `role="alert"` for live error messaging.
 - Apply `aria-expanded`, `aria-controls`, and `aria-hidden` for toggleable UI elements.
 - Prefer native HTML elements over ARIA whenever possible to reduce complexity.
 
-### Provide Live Region Updates
+### Provide live region updates
 
 Ensure real-time changes are accessible:
 
-- Use `aria-live="polite"` or `aria-live="assertive"` for real-time updates (e.g. validation messages, chat widgets).
+- Use `aria-live="polite"` or `aria-live="assertive"` for real-time updates (e.g., validation messages, chat widgets).
 
-### Manage Page Titles and Headings
+### Manage page titles and headings
 
 Headings and titles provide structure and orientation. It helps users understand page structure:
 
-- Always update the `<title>`  tag on page load or route change.
+- Always update the `<title>` tag on page load or route change.
 - Use one `<h1>` per page, followed by correct heading hierarchy (`<h2>`, `<h3>`, etc.).
 
-### Support Skip Links
+### Support skip links
 
 Help keyboard users skip repetitive content:
 
 - Include a skip link at the top of the page:
 
-  ```html
+ ```html
   <a href="#main-content" class="skip-link">Skip to main content</a>
-  ```
+ ```
 
-### Control Focus When Using Modals or Popovers
+### Control focus when using modals or popovers
 
 Focus should remain within the modal and return to the trigger element after closing:
 
 - Trap focus while the modal is open.
 - Return focus to the initiating element once it is closed.
 
-### Avoid Auto-Playing Audio or Video
+### Avoid auto-playing audio or video
 
 If unavoidable, make sure users can easily pause or stop it:
 
 - Provide controls on `<video>` or `<audio>` elements.
 - Avoid autoplay unless muted and non-disruptive.
 
-### Ensure Unique IDs and ARIA Attributes
+### Ensure unique IDs and ARIA attributes
 
 Avoid duplicated IDs to maintain screen reader reliability:
 
 - Validate that `id` attributes are unique.
 - Ensure any referenced IDs in `aria-labelledby` or `aria-describedby` exist and are not duplicated.
 
-### Test with Assistive Technologies
+### Test with assistive technologies
 
 Test your site with real-world tools and scenarios:
 
@@ -116,4 +116,4 @@
 
 Following this checklist will help ensure your storefront is usable by everyone, regardless of ability. It also improves SEO, performance, and user satisfaction for all visitors.
 
-Regularly audit your code, test with assistive technologies, and stay updated with evolving accessibility standards. Inclusive design is good design.
+Regularly audit your code, test with assistive technologies, and stay up to date with evolving accessibility standards. Inclusive design is good design.

guides/development/accessibility/index.md

@@ -0,0 +1,23 @@
+---
+nav:
+  title: Accessibility
+  position: 10
+---
+
+# Accessibility
+
+Shopware is committed to creating inclusive and barrier-free shopping experiences. Accessibility affects both the core Storefront and all custom themes and extensions. Developers are responsible for ensuring their implementations comply with accessibility standards, such as WCAG 2.1 Level AA.
+
+## In this section
+
+<PageRef page="./storefront-accessibility" />
+<PageRef page="./accessibility-checklist" />
+
+## Why accessibility matters
+
+* Legal compliance (e.g., EU accessibility regulations)
+* Better usability for all users
+* Improved SEO and performance
+* Future-proof storefront implementations
+
+Shopware continuously introduces accessibility improvements in new releases. Always test extensions with the `ACCESSIBILITY_TWEAKS` feature flag enabled to ensure compatibility.