Revert "Update UML diagrams from mermaid"

concepts/commerce/catalog/products.md

@@ -11,77 +11,30 @@ Products are sellable entities (physical and digital products) within your shop.
 
 Depending on your setup, Shopware can easily handle thousands of products. However, an upsurge in the product quantity (in millions) needs some tweaks for robust running of the environment as it depends on factors like the number of [categories](../../../../docs/concepts/commerce/catalog/categories), [sales channels](../../../../docs/concepts/commerce/catalog/sales-channels), [product properties](../../../../docs/concepts/commerce/catalog/products#property-groups--options), etc. Every product added to your shop can be made available on one or more [sales channels](../../../../docs/concepts/commerce/catalog/sales-channels).
 
-Let's delve into a more detailed understanding of products using the example of garments:
+Let us start understanding about product more in detail:
 
-* **Product details**: General information about a Product.
+* **Product details**: General information about a Product - for example, title, manufacturer, prices, media, etc.
+* **Product properties**: Product properties encapsulates property groups and options.
+* **Product variant**: A sellable good. Product Variants are generally mapped to products. Inventory is modeled per variant.
+* **Category**: Products in Shopware are organised in categories. It is a grouping of products based on characteristics, marketing or search concerns. Categories are represented as a hierarchical tree to form a navigation menu. A product can be contained in multiple categories.
 
-| Title | Product Id| Manufacturer | Prices | more.... |
-|-------|-----------|--------------|--------|----------|
-|levis Ocean Hoodie| SW1001 | CA | 40 | ... |
+Look at the below condensed overview of the product data model:
 
-* **Product properties**: Product properties encapsulates property groups and options. They can be displayed in a table on your product detail pages, in listings, or even be used for filtering.A product can have arbitrarily many property group options.
+![Condensed overview of the product data model](../../../assets/concept-catalog-products-datamodel.png)
 
-|Property Group| Property Group options|
-|--------------|-----------------------|
-|Size          |  *S*, *M*, *L*, *XL*, etc |
-|Color         | *Red*, *Blue*, *Green*, *Black* |
-|Material      | *Leather*, *Cotton*, *Jeans* |
+Besides their relation to categories, products can also link to a set of *property group options*.
 
-* **Category**: Products in Shopware are organized in categories. It is a grouping of products based on characteristics, marketing or search concerns. Categories are represented as a hierarchical tree to form a navigation menu. A product can be contained in multiple categories.
+## Property groups and options
 
-Look at the below condensed overview of the product data model:
+Product properties can be modeled using property groups and -options. They can be displayed in a table on your product detail pages, in listings, or even be used for filtering.
 
-```mermaid
-erDiagram
-    Product||--|{ ProductCategory : "m:1"
-    ProductCategory}|--|| Category : "1:m"
-    Product {
-        uuid product_id
-    }
-    ProductCategory {
-        uuid product_id 
-        uuid category_id 
-    }
-    Category {
-        uuid category_id
-    }
-    Product ||--|{ ProductOption : "1:m"
-    ProductOption{
-        uuid product_id
-        uuid property_group_option_id
-    }
-    ProductOption }|--|| PropertyGroupOption : "m:1"
-    PropertyGroupOption{
-        uuid property_group_option_id
-        uuid property_group_id
-    }
-        PropertyGroupOption }|--|| PropertyGroup : "m:1"
-    PropertyGroup{
-        uuid property_group_id
-    }
-```
+Examples of property group garments are *Size*, *Color* or *Material*. The corresponding values of each group are referred to as *property group options*. A product can have arbitrarily many property group options.
 
-Besides their relation to categories, products can also link to a set of *property group options*.
+## Product variants
+
+Different variations of a product can be modeled using *product variants*. Products are a self-referencing entity, which is interpreted as a parent-child relationship. This mechanism is also used to model variants. This also provides inheritance between field values from parent products to child products.
 
-* **Product variant**: A sellable product. Products are a self-referencing entity, which is interpreted as a parent-child relationship. Similarly, product variants are also generally mapped to products. This mechanism is used to model variants. This also provides inheritance between field values from parent products to child products.
-
-```mermaid
-erDiagram
-    Product||--|| Product : "uuid=variant"
-    Product {
-        uuid product_id
-        uuid parent_id
-    }
-    Product ||--|{ PropertyGroupOption : "1:m"
-    PropertyGroupOption{
-        uuid property_group_option_id
-        uuid property_group_id
-    }
-    PropertyGroupOption }|--|| PropertyGroup : "m:1"
-    PropertyGroup{
-        uuid property_group_id
-    }
-```
+![Variant model](../../../assets/concept-catalog-products-variantModel.png)
 
 However, it is also useful to attach some additional properties to differentiate product variants next to the field inheritance. For that reason, it is critical to understand the difference between *properties* and *options*:
 
@@ -99,12 +52,7 @@ Opposed to that **options** are considered variant defining, as they are the fac
 
 It is important to understand the difference between those two because both provide a relation between the product and the property group option entity. However only one constitutes to product variants.
 
-| Variant | Product | Category | Product group | Product group option |
-|---------|---------|----------|---------------|----------------------|
-|Variant 1| Levis Ocean Hoodie | Hoodie & Sweaters | Color | Red |
-|Variant 2| Levis Ocean Hoodie | Hoodie & Sweaters | Color | Black |
-
-## Configurator
+### Configurator
 
 When a variant product is loaded for a [Store API](../../api/store-api)-scoped request, Shopware assembles a configurator object which includes all different property groups and the corresponding variants. This way client applications, such as the [Storefront](../../../guides/plugins/plugins/storefront/) or the [PWA](../../../products/pwa) can display the different variant options of the product.
 

concepts/commerce/checkout-concept/cart.md

@@ -68,48 +68,13 @@ The price of all line items, including tax, delivery costs, voucher discounts, a
 
 Shopware 6 manages the cart's state through different services. The diagram below illustrates the different states the cart can have and the state changes it can go through.
 
-```mermaid
----
-title: Cart State
----
-stateDiagram-v2
-    [*] --> Empty
-    Empty --> Dirty : add line item
-    Dirty --> Calculated : calculate
-    Calculated --> Dirty : modify line item/shipping/payment
-    Calculated --> Calculated : order invalid
-    Calculated --> [*] : order
-```
-
-|Cart state | Description|
-|------|------------|
-|Empty | A cart with no items will have default shipping and payment settings. |
-|Dirty | On adding a new line item, the cart undergoes modifications with invalid prices, raw line items, and uncertain delivery validity. Consequently, calculations are necessary.|
-|Calculated | After accurate calculations, the cart can be either submitted as an order or may contain errors that need to be addressed. |
+![Cart state](../../../assets/cart-state.png)
 
 ## Calculation
 
 Calculating a cart is one of the more costly operations an ecommerce system must support. Therefore the interfaces of the cart are designed as precise and as quick as possible. The calculation is a multi-stage process that revolves around the mutation of the data structure of the cart struct shown in the diagram below:
 
-```mermaid
----
-title: Cart Calculation
----
-stateDiagram-v2
-    [*] --> Enrich
-    Enrich --> Process
-    Process --> Validate
-    Validate --> Validate : repeat until no changes occur
-    Validate --> Persist
-    Persist --> [*]
-```
-
-|Cart calculation state | Description|
-|------|------------|
-|Enrich | The calculation process in the "enrich" state for line items involves adding images, its descriptions and determining prices|
-|Process | During the process state, price updates occur, adjustments to shipping and payment are made|
-|Validate | In the validate state, validation is performed using the rule system and cart changes based on plausibility checks. |
-|Persist | The persist state is responsible for updating the storage. |
+![Cart calculation](../../../assets/cart-calculation-steps.png)
 
 ### Cart enrichment
 
@@ -140,28 +105,7 @@ A default set of collectors is implemented in Shopware 6, which has a set call o
 | Shopware\Core\Checkout\Promotion\Cart\CartPromotionsCollector | Enrich add, remove and validate promotions |
 | Shopware\Core\Checkout\Shipping\Cart\ShippingMethodPriceCollector | Handle shipping prices |
 
-```mermaid
----
-title: Enrichment
----
-sequenceDiagram
-Enrichment->>Enrichment : 
-box
-    participant Enrichment
-    participant ProductCartProcessor
-    participant CartPromotionsCollector
-    participant CartDiscountCollector
-    end
-    Note over Enrichment,CartDiscountCollector: Collect
-    Enrichment->>ProductCartProcessor: collect
-    Enrichment->>CartPromotionsCollector: collect
-    Enrichment->>CartDiscountCollector: collect
-    Note over Enrichment,CartDiscountCollector: Enrichment
-    Enrichment->>ProductCartProcessor: enrich
-    Enrichment->>CartPromotionsCollector: enrich
-    Enrichment->>CartDiscountCollector: enrich
-    Enrichment->>Enrichment : 
-```
+![Cart enrichment steps](../../../assets/cart-enrichtment-steps.png)
 
 ## Cart processors - price calculation and validation
 
@@ -180,16 +124,7 @@ After the cart has been processed, it is validated against the rules, which can
 * Everybody buying a car gets a pair of sunglasses for free.
 * Every cart containing two products gets a discount of 2%.
 
-```mermaid
-stateDiagram-v2
-    [*] --> Empty_cart : checkout started
-    Empty_cart --> Enrichment : User orders a car
-        state Enrichment {
-    Cart_with_lineitem(car) --> Cart_with_lineitem(car+sunglasses) : Iteration 1 - Cart automatically adds sunglasses
-    Cart_with_lineitem(car+sunglasses) --> Cart_with_lineitem(car+sunglasses+2%discount) : Iteration 2 - Cart automatically adds discount
-    }
-    Cart_with_lineitem(car+sunglasses+2%discount) --> [*] : valid
-```
+![Cart validation](../../../assets/cart-validation.png)
 
 As you can see in the diagram above, the cart is modified during the enrichment process. The sunglasses are added in the first iteration, and in the second iteration, the discount is added as the cart contains two products. This results in the expected state of one car, one pair of sunglasses, and a two-percent discount.
 

concepts/framework/flow-concept.md

@@ -43,35 +43,8 @@ In Shopware, you have multiple interfaces and classes for different types of eve
 
 Once the action on the Storefront or from the app happens, the FlowDispatcher will dispatch FlowEventAware to the FlowExecutor. From here, the FlowExecutor will check the condition to decide whether to execute the action.
 
-```mermaid
-flowchart-elk TD
-    A([Start])-->B["`FlowDispatcher::dispatch()`"]
-    B--dispatches (FlowEventAware)-->C["`FlowExecutor::execute()`"]
-    C-->D{"`FlowExecutor::sequenceRuleMatches()`"}
-    C--no condition-->E["`FlowExecutor::executeAction3()`"]
-    D--Yes-->I["`FlowExecutor::executeAction2()`"]    
-    E-->F["`StopFlowAction::handleFlow()`"]
-    F-->G([End])
-    D--No -->H["`FlowExecutor::executeAction1()`"]
-    H-->F
-    I-->F
-```
+![Flow builder concept for flow sequence](../../assets/flow-concept-1.png)
 
 Here is an example flow of what happens in the system when an order is placed on the Storefront.
 
-```mermaid
-flowchart-elk TD
-    A([Start])
-subgraph Storefront
-    B[User]
-end
-A-->Storefront
-Storefront--Place an order-->Core
-subgraph Core
-    C["`CartOrderRoute::Order()`"]--dispatch [checkout.order.place]-->D["`FlowDispatcher::dispatch()`"]
-    D-->E["`FlowExecutor::execute()`"]
-    E-->F["`FlowExecutor::executeAction()`"]
-    F-->G["`StopFlowAction::handleFlow()`"]
-end
-    G-->H([End])
-```
+![Flow builder concept for order placed](../../assets/flow-concept-2.png)

concepts/framework/rules.md

@@ -39,32 +39,11 @@ The center of the rule system is the `Rule`. It is realized as a variant of the
 
 As well as a Specification class, a Rule class represents a condition to fulfill. It implements the `match(RuleScope $scope)` function to validate user defined values against a runtime state. See the following object diagram for a better understanding:
 
-```mermaid
-classDiagram
-    root-OrRule .. lineItemCount - LineItemsInCartCountRule
-    root-OrRule .. cartPrice - GoodsPriceRule
-    class root-OrRule{
-        rules=[lineItemCount, cartPrice]
-    }
-    class lineItemCount - LineItemsInCartCountRule{
-      operator=">="
-      count="40"
-    }
-    class cartPrice - GoodsPriceRule{
-      operator=">="
-      count="500"
-    }
-```
+![](../../assets/rule-objects.png)
 
 This will result in the following call order:
 
-```mermaid
-sequenceDiagram
-    root-->>lineItemCount: match()?
-    lineItemCount-->>root: false
-    root-->>cartPrice: match()?
-    cartPrice-->>root: false
-```
+![](../../assets/rule-sequence.png)
 
 As you can see, a single rule can either contain user defined values or other user defined rules. These are Container rules. The rule system here bears some resemblance to the [SearchCriteria](../../guides/plugins/plugins/framework/data-handling/reading-data#Filtering), although independent. A Search Criteria is the representation of a query that gets translated and executed through the storage engine. The rule matches in-memory in PHP and does not access the underlying storage.
 

guides/plugins/plugins/api/multi-inventory.md

@@ -34,22 +34,7 @@ Meanwhile, refer to the following links regarding the general use of the Admin A
 
 The Multi-Inventory feature implements a specific data structure for its internal stock handling. The following entity-relationship model visually represents the new entities, as well as the relationships between them and platform entities.
 
-```mermaid
-erDiagram
-    order_warehouse_group }|..|| order : has
-    order_warehouse_group }|..|| warehouse_group : has
-    order_product_warehouse }|..|| order : has
-    order_product_warehouse }|..|| warehouse : has
-    warehouse_group }|..|| rule : has
-    warehouse_group }|..|| product_warehouse_group : has
-    warehouse_group }|..|| warehouse_group_warehouse : has
-    product_warehouse_group }|..|| product : has
-    order_product_warehouse }|..|| product : has
-    product_warehouse }|..|| product : has
-    warehouse_group_warehouse }|..|| warehouse_group : has
-    warehouse_group_warehouse }|..|| warehouse : has
-    product_warehouse }|..|| warehouse : has
-```
+![multi-inventory_data-structure](../../../../assets/multi-inventory-data-structure.png)
 
 ## Working with the API
 

products/extensions/b2b-suite/concept/line-item-list.md

@@ -17,6 +17,7 @@ The LineItemList component is the central representation of product lists in the
 * Guaranteed audit logging
 
 The component is used across multiple different child components throughout the B2B Suite.
+
 ![image](../../../../assets/line-item-list-outer-dependencies.svg)
 
 The yellow colored blocks represent components, while the smaller green ones are context objects that contain the component specific information.

products/extensions/b2b-suite/guides/core/audit-log.md

@@ -14,32 +14,7 @@ nav:
 The B2B Suite provides a general audit log that can be implemented in every component.
 The audit log component can save different log types and author information like first name, last name, and email. It provides a one-to-many association index. The database structure is described in the graphic below:
 
-```mermaid
-classDiagram 
-    b2b_audit_log_index o--> b2b_audit_log : n to 1
-    b2b_audit_log o--> b2b_audit_log_author : n to 1
-    class b2b_audit_log_index{
-        id 
-        audit_log_id 
-        reference_table 
-        reference_id
-    }
-    class b2b_audit_log{
-        id 
-        log_value 
-        log_type 
-        event_date 
-        author_hash
-    }
-    class b2b_audit_log_author{
-        hash
-        salutation
-        title
-        firstname
-        lastname
-        email
-    }
-```
+![image](../../../../../assets/auditlog-structure.svg)
 
 As you can see, the database structure is very flat. In the `b2b_audit_log` table, we save a log type and a serialized *AuditLogValueEntity*.
 All required author information is saved in the `b2b_audit_log_author` table.

products/extensions/b2b-suite/guides/storefront/ajax-panel.md

@@ -21,7 +21,7 @@ The most basic ajax panel looks like this:
 ```twig
 <div
     class="b2b--ajax-panel"
-    data-url="{{ path('frontend.b2b.b2bcontact.grid') }}"
+    data-url="{{ path('frontend.b2b.b2bcontact.grid' }}"
 >
     <!-- will load content here -->
 </div>