update changes as per vitepress (#1219)

* update changes as per vitepress * feat: reuse workflows * fix: vitepress syntax * fix: missing end dl tag --------- Co-authored-by: Bojan Rajh <[email protected]>
shopware · Dec 5, 2023 · fa7a863 · fa7a863
1 parent 16b3650
commit fa7a863
Show file tree

Hide file tree

Showing 8 changed files with 107 additions and 133 deletions.
diff --git a/.github/workflows/deploy-developer-portal.yml b/.github/workflows/deploy-developer-portal.yml
@@ -0,0 +1,24 @@
+# This workflow is triggered whenever the main branch is updated
+name: Deploy to DevHub
+
+on:
+  push:
+    branches:
+      - main
+
+jobs:
+  trigger-deployment:
+    name: Trigger deployment
+    runs-on: ubuntu-latest
+    steps:
+
+      - uses: octokit/[email protected]
+        name: Trigger deployment
+        with:
+          route: POST /repos/{owner}/{repo}/actions/workflows/{workflow_id}/dispatches
+          owner: shopware
+          repo: developer-portal
+          ref: main
+          workflow_id: checkout-test-build-deploy.yml
+        env:
+          GITHUB_TOKEN: ${{ secrets.DEV_HUB_PERSONAL_ACCESS_TOKEN }}
diff --git a/.github/workflows/developer-portal-healthckeck.yml b/.github/workflows/developer-portal-healthckeck.yml
@@ -0,0 +1,19 @@
+name: Healthcheck
+
+on:
+  pull_request:
+    branches:
+      - main
+
+jobs:
+
+  create-healthcheck:
+    uses: shopware/developer-portal/.github/workflows/healthcheck.yml@main
+    with:
+      owner: ${{ github.repository_owner }}
+      repo: ${{ github.event.repository.name }}
+      branch: ${{ github.event.pull_request.head.ref }}
+      sha: ${{ github.event.pull_request.head.sha }}
+    secrets:
+      GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+      PERSONAL_TOKEN: ${{ secrets.DEV_HUB_PERSONAL_ACCESS_TOKEN }}
diff --git a/.github/workflows/update-healthcheck.yml b/.github/workflows/update-healthcheck.yml
@@ -0,0 +1,39 @@
+# This workflow is triggered from developer-portal
+name: Update healthcheck
+
+on:
+  workflow_dispatch:
+    inputs:
+      owner:
+        description: "Owner to checkout"
+        required: true
+        type: string
+      repo:
+        description: "Repo to checkout"
+        required: true
+        type: string
+      check:
+        description: "Check ID"
+        required: true
+        type: string
+      conclusion:
+        description: "Healthcheck conclusion"
+        required: true
+        type: string
+      run_id:
+        description: "Workflow run ID"
+        required: true
+        type: string
+
+jobs:
+
+  update-healthcheck:
+    uses: shopware/developer-portal/.github/workflows/update-healthcheck.yml@main
+    with:
+      owner: ${{ inputs.owner }}
+      repo: ${{ inputs.repo }}
+      check: ${{ inputs.check }}
+      conclusion: ${{ inputs.conclusion }}
+      run_id: ${{ inputs.run_id }}
+    secrets:
+      TOKEN: ${{ secrets.GITHUB_TOKEN }}
diff --git a/guides/plugins/apps/app-base-guide.md b/guides/plugins/apps/app-base-guide.md
@@ -13,9 +13,7 @@ This guide will walk you through the process of adding your own app to Shopware
 
 ## Prerequisites
 
-If your're not familiar with the app system, please take a look at the concept first.
-
-<PageRef page="../../../concepts/extensions/apps-concept" />
+If your are not familiar with the app system, take a look at the [App concept](../../../concepts/extensions/apps-concept.md) first.
 
 ## File structure
 
@@ -322,7 +320,7 @@ You can use a variety of events to react to changes in Shopware that way. See th
 | `product_price.written` | Triggers if product price is written | `product_price:read` |
 | `category.written` | Triggers if a category is written | `category:read` |
 
-### **App lifecycle events**
+### App lifecycle events
 
 Apps can also register to lifecycle events of its own lifecycle, namely its installation, updates and deletion. For example they maybe used to delete user relevant data from your data stores once somebody removes your app from their shop.
 
@@ -373,108 +371,3 @@ Additionally, you can specify which app should be validated by providing the app
 ```bash
 bin/console app:validate MyExampleApp
 ```
-
-## API Docs
-
-{% api-method method="get" host="https://my.example.com" path="" %}
-{% api-method-summary %}
-registration
-{% endapi-method-summary %}
-
-{% api-method-description %}
-
-{% endapi-method-description %}
-
-{% api-method-spec %}
-{% api-method-request %}
-{% api-method-headers %}
-{% api-method-parameter name="shopware-app-signature" type="string" required=true %}
-The hmac-signature of the query string, signed with the app secret
-{% endapi-method-parameter %}
-{% endapi-method-headers %}
-
-{% api-method-query-parameters %}
-{% api-method-parameter name="timestamp" type="integer" required=true %}
-The current Unix timestamp when the request was created
-{% endapi-method-parameter %}
-
-{% api-method-parameter name="shop-url" type="string" required=true %}
-The URL of the shop, where the app was installed, can be used to access to the Shopware API
-{% endapi-method-parameter %}
-
-{% api-method-parameter name="shop-id" type="string" required=true %}
-The unique identifier of the shop, where the app was installed
-{% endapi-method-parameter %}
-{% endapi-method-query-parameters %}
-{% endapi-method-request %}
-
-{% api-method-response %}
-{% api-method-response-example httpCode=200 %}
-{% api-method-response-example-description %}
-
-{% endapi-method-response-example-description %}
-
-```text
-{
-  "proof": "94b42d39280141de84bd6fc8e538946ccdd182e4558f1e690eabb94f924e7bc7",
-  "secret": "random secret string",
-  "confirmation_url": "https://my.example.com/registration/confirm"
-}
-```
-{% endapi-method-response-example %}
-{% endapi-method-response %}
-{% endapi-method-spec %}
-{% endapi-method %}
-
-{% api-method method="post" host="https://my.example.com" path="" %}
-{% api-method-summary %}
-confirmation
-{% endapi-method-summary %}
-
-{% api-method-description %}
-
-{% endapi-method-description %}
-
-{% api-method-spec %}
-{% api-method-request %}
-{% api-method-headers %}
-{% api-method-parameter name="shopware-shop-signature" type="string" required=true %}
-The hmac-signature of the body content, signed with the shop secret returned from the registration request
-{% endapi-method-parameter %}
-{% endapi-method-headers %}
-
-{% api-method-body-parameters %}
-{% api-method-parameter name="shopId" type="string" required=true %}
-The unique identifier of the shop
-{% endapi-method-parameter %}
-
-{% api-method-parameter name="shopUrl" type="string" required=true %}
-The URL of the shop
-{% endapi-method-parameter %}
-
-{% api-method-parameter name="timestamp" type="integer" required=true %}
-The current Unix timestamp when the request was created
-{% endapi-method-parameter %}
-
-{% api-method-parameter name="secretKey" type="string" required=true %}
-SecretKey used to authenticate against the Shopware API
-{% endapi-method-parameter %}
-
-{% api-method-parameter name="apiKey" type="string" required=true %}
-ApiKey used to authenticate against the Shopware API
-{% endapi-method-parameter %}
-{% endapi-method-body-parameters %}
-{% endapi-method-request %}
-
-{% api-method-response %}
-{% api-method-response-example httpCode=200 %}
-{% api-method-response-example-description %}
-
-{% endapi-method-response-example-description %}
-
-```text
-```
-{% endapi-method-response-example %}
-{% endapi-method-response %}
-{% endapi-method-spec %}
-{% endapi-method %}
diff --git a/guides/plugins/plugins/administration/customizing-components.md b/guides/plugins/plugins/administration/customizing-components.md
@@ -30,7 +30,7 @@ Now that we know where to place our override, we need to decide what to override
 {% endblock %}
 ```
 
-This overrides the entire Twig block with our new markup. However, if we want to retain the original content of the Twig block and just add our markup to the existing one, we can do that by including a `\{% parent %\}` somewhere in the Twig block. Learn more about the capabilities of twig.js [here](https://github.com/twigjs/twig.js/wiki).
+This overrides the entire Twig block with our new markup. However, if we want to retain the original content of the Twig block and just add our markup to the existing one, we can do that by including a <code v-pre>{% parent %\}</code> somewhere in the Twig block. Learn more about the capabilities of twig.js [here](https://github.com/twigjs/twig.js/wiki).
 
 As you might have noticed the heading we just replaced had a `{ $tc() }` [string interpolation](https://vuejs.org/v2/guide/syntax.html#Text) which is used to make it multilingual. Learn more about internationalization in the Shopware 6 Administration and about adding your own snippets to the administration [here](adding-snippets).
 

diff --git a/guides/plugins/plugins/content/cms/add-cms-block.md b/guides/plugins/plugins/content/cms/add-cms-block.md
@@ -127,7 +127,7 @@ Just like most components, it has a custom template and also some styles. Focus
 
 This template now has to define the basic structure of your custom block. In this simple case, you only need a parent container and two sub-elements, whatever those are. That's also were the slots come into play: You've used two slots in your block's configuration, `left` and `right`. Make sure to create those slots in the template as well now.
 
-```text
+```twig
 // <plugin root>/src/Resources/app/administration/src/module/sw-cms/blocks/text-image/image-text-reversed/component/sw-cms-block-image-text-reversed.html.twig
 {% block sw_cms_block_image_text_reversed %}
     <div class="sw-cms-block-image-text-reversed">
@@ -154,11 +154,6 @@ In there, use a grid to display your elements next to each other. You've set a C
 
 That's it for this component! Make sure to import your `component` directory in your `index.js` file, so your new component actually gets loaded.
 
-{% code title="<plugin root>/src/Resources/app/administration/src/module/sw-cms/blocks/text-image/image-text-reversed/index.js" %}
-```
-
-```
-
 ```javascript
 import './component';
 
@@ -185,7 +180,7 @@ Shopware.Component.register('sw-cms-preview-image-text-reversed', {
 
 The preview element doesn't have to deal with mobile viewports or anything alike, it's just a simplified preview of your block. Thus, create a template containing a text and an image and use the styles to place them next to each other. Create a `sw-cms-preview-image-text-reversed.html` file in your `preview` directory with the following content.
 
-```text
+```twig
 // <plugin root>/src/Resources/app/administration/src/module/sw-cms/blocks/text-image/image-text-reversed/preview/sw-cms-preview-image-text-reversed.html.twig
 {% block sw_cms_block_image_text_reversed_preview %}
     <div class="sw-cms-preview-image-text-reversed">
@@ -273,7 +268,7 @@ In there create a new twig template named after your block, so `cms-block-image-
 
 Since the [original 'image\_text' file](https://github.com/shopware/platform/blob/v6.3.4.1/src/Storefront/Resources/views/storefront/block/cms-block-image-text.html.twig) is already perfectly fine, you can go ahead and extend from it in your storefront template.
 
-```text
+```twig
 // <plugin root>/src/Resources/views/storefront/block/cms-block-image-text-reversed.html.twig
 {% sw_extends '@Storefront/storefront/block/cms-block-image-text.html.twig' %}
 ```

diff --git a/guides/plugins/plugins/framework/data-handling/add-data-translations.md b/guides/plugins/plugins/framework/data-handling/add-data-translations.md
@@ -25,7 +25,16 @@ In this guide we'll name our table `swag_example_translation` since our entity i
 
 The translation table's columns should be the following:
 
-swag\_example\_idThis will refer to the swag\_example this translation belongs to. This is also a foreign key.language\_idThis will contain the ID of the language for this translation. This is also a foreign key.nameThe actual translated value, the translated name of the swag\_example.created\_atNot much explanation required here.updated\_atNot much explanation required here.
+<dl>
+    <dt>`swag_example_id`</dt>
+    <dd>This will refer to the `swag_example` entity this translation belongs to. This is also a foreign key.</dd>
+    <dt>`language_id`</dt>
+    <dd>This will contain the ID of the language for this translation. This is also a foreign key.</dd>
+    <dt>`name`</dt>
+    <dd>The actual translated value, the translated name of the `swag_example.created_atNot` much explanation required here.</dd>
+    <dt>updated_at</dt>
+    <dd> Not much explanation required here.</dd>
+</dl>
 
 Therefore, this is how your migration could then look like:
 
@@ -207,12 +216,10 @@ class ExampleTranslationEntity extends TranslationEntity
 
 Now we need our translation definition to know its custom entity class. This is done by overriding the method `getEntityClass` in our `ExampleTranslationDefinition`.
 
-{% code title="<plugin root>/src/Core/Content/Example/Aggregate/ExampleTranslation/ExampleTranslationDefinition.php" %}
-```
+```php
 
-```
+// "<plugin root>/src/Core/Content/Example/Aggregate/ExampleTranslation/ExampleTranslationDefinition.php"
 
-```php
 class ExampleTranslationDefinition extends EntityTranslationDefinition
 {
     [...]

diff --git a/guides/plugins/themes/add-css-js-to-theme.md b/guides/plugins/themes/add-css-js-to-theme.md
@@ -21,9 +21,8 @@ When it comes to CSS and SCSS, they are processed by a PHP SASS compiler.
 
 The main entry point to deploy your SCSS code is defined in the `theme.json` file. By default it is the `<plugin root>/app/storefront/src/scss/base.scss` file.
 
-{% code title="<plugin root>/src/Resources/theme.json" %}
-```
-
+```javascript
+//"<plugin root>/src/Resources/theme.json"
 ```
 
 When the storefront gets compiled the PHP SASS compiler will look up the files declared in the `style` section of the theme configuration. You can define the SCSS entry-points individually if you want to.
@@ -45,9 +44,8 @@ In order to add some custom SCSS in your theme, you just need to edit the `base.
 
 To apply your styles and test them, please use some test code:
 
-{% code title="<plugin root>/src/Resources/app/storefront/src/scss/base.scss" %}
-```
-
+```css
+//<plugin root>/src/Resources/app/storefront/src/scss/base.scss"
 ```
 
 Afterwards, you need to compile your theme by running the `bin/console theme:compile` command in terminal.
@@ -77,9 +75,8 @@ Since Shopware knows where your style files are located, they are automatically
 
 Add some test code in order to see if it works out:
 
-{% code title="<plugin root>/src/Resources/app/storefront/src/js/main.js" %}
-```
-
+```javascript
+// <plugin root>/src/Resources/app/storefront/src/js/main.js"
 ```
 
 In the end, by running the command `bin/console theme:compile` your custom JS plugin is loaded. By default, the compiled JavaScript file is saved as `<plugin root>/src/resources/app/storefront/dist/storefront/js/swag-basic-example-theme.js`. It is detected by Shopware automatically and included in the Storefront. So you do not need to embed the JavaScript file yourself.
@@ -112,5 +109,5 @@ This command starts a NodeJS web server on port `9998`. If you open the Storefro
 
 Now that you know how to customize the styling via SCSS and add JavaScript, here is a list of things you can do.
 
-* [Override Bootstrap variables in a theme](override-bootstrap-variables-in-a-theme) 
+* [Override Bootstrap variables in a theme](override-bootstrap-variables-in-a-theme)
 * [Customize templates](../plugins/storefront/customize-templates)