From f0046b4173af06c39f55fa17739c65941d7f2698 Mon Sep 17 00:00:00 2001 From: Tomasz Turkowski Date: Mon, 8 Jun 2026 13:47:57 +0200 Subject: [PATCH] docs: fix typos, improve clarity and structure across plugin guides --- guides/plugins/plugins/bundle.md | 22 ++++---- guides/plugins/plugins/creating-plugins.md | 24 +++------ .../database/custom-fields-of-type-media.md | 12 ++--- .../plugins/database/database-migrations.md | 20 +++----- guides/plugins/plugins/database/index.md | 4 +- guides/plugins/plugins/in-app-purchases.md | 14 ++--- guides/plugins/plugins/index.md | 6 +-- .../plugins/install-activate-plugin.md | 12 +++-- guides/plugins/plugins/mcp-server.md | 4 +- guides/plugins/plugins/plugin-base-guide.md | 26 ++++------ .../add-custom-commands.md | 27 +++++++++- .../add-plugin-configuration.md | 51 ++++++++++++------- .../plugin-fundamentals/add-scheduled-task.md | 20 ++++---- .../plugins/plugin-fundamentals/index.md | 8 ++- .../plugins/plugin-fundamentals/logging.md | 19 ++++--- .../plugin-fundamentals/plugin-lifecycle.md | 30 +++++------ .../use-plugin-configuration.md | 26 ++++------ .../plugins/services/add-custom-service.md | 19 +++---- .../plugins/services/adjusting-service.md | 22 ++++---- .../plugins/services/dependency-injection.md | 15 ++---- 20 files changed, 193 insertions(+), 188 deletions(-) diff --git a/guides/plugins/plugins/bundle.md b/guides/plugins/plugins/bundle.md index 3042d3c020..9a243637ca 100644 --- a/guides/plugins/plugins/bundle.md +++ b/guides/plugins/plugins/bundle.md @@ -29,7 +29,7 @@ Shopware plugins extend Symfony bundles and add: * Asset building integration * Administration management -Class hierarchy: Plugin → Shopware\Bundle → Symfony\Bundle +Class hierarchy: `Plugin` → `Shopware\Bundle` → `Symfony\Bundle` ## When to use a bundle @@ -79,7 +79,7 @@ project-root/ └── .shopware-project.yaml ``` -The Bundle is typically placed in a project's `src/` folder, which is the standard location for custom code. You still will need to register the Bundle in the project's `config/bundles.php` file. +The Bundle is typically placed in a project's `src/` folder, which is the standard location for custom code. You will still need to register the Bundle in the project's `config/bundles.php` file. ## Choosing the right bundle class @@ -144,7 +144,7 @@ if (Feature::isActive('YOUR_FEATURE_FLAG') && InstalledVersions::isInstalled('ve You can add services, Twig templates, routes, etc., to your Bundle just as you would to a plugin. Create `Resources/config/services.php` and `Resources/config/routes.php` files, or `Resources/views` for Twig templates. The Bundle will be automatically detected, and the files will be loaded. To mark your Bundle as a theme, you only need to implement the `Shopware\Core\Framework\ThemeInterface` interface in your bundle class. -This will automatically register your Bundle as a theme and make it available in the Shopware administration. +This will automatically register your Bundle as a theme and make it available in the Administration. You can also add a `theme.json` file to define the theme configuration like [described here](../themes/configuration/theme-configuration.md). ## Adding migrations @@ -170,7 +170,7 @@ class YourBundleName extends Bundle } ``` -Since Bundles don't have a lifecycle, migrations aren't automatically executed. Execute them manually via the console command: +Since bundles don't have a lifecycle, migrations aren't automatically executed. Execute them manually via the console command: ```bash bin/console database:migrate --all @@ -193,11 +193,11 @@ The Shopware CLI cannot automatically detect bundles. Therefore, bundle assets a { "extra": { "shopware-bundles": { - "src/": { - "name": "", - } - } - } + "src/": { + "name": "" + } + } + } } ``` @@ -207,8 +207,8 @@ This will tell Shopware CLI where the Bundle is located and its name. Now that you know about the differences between a Symfony bundle and a Shopware plugin, review the following guides: -* [Dependency Injection](../plugins/services/dependency-injection.md) -* [Listening to events](../plugins/framework/event/listening-to-events.md) +* [Dependency Injection](services/dependency-injection.md) +* [Listening to events](framework/event/listening-to-events.md) Also check out these useful videos: diff --git a/guides/plugins/plugins/creating-plugins.md b/guides/plugins/plugins/creating-plugins.md index 256217139b..f020813d04 100644 --- a/guides/plugins/plugins/creating-plugins.md +++ b/guides/plugins/plugins/creating-plugins.md @@ -5,14 +5,10 @@ nav: --- -## Creating Plugins +# Creating Plugins This guide walks you through creating and scaffolding a basic Shopware plugin so it can be installed locally on your Shopware 6 instance. -::: info -Refer to this video on [Creating a plugin](https://www.youtube.com/watch?v=_Tkoq5W7woI) that shows how to bootstrap a plugin. Also available on our free online training ["Shopware 6 Backend Development"](https://academy.shopware.com/courses/shopware-6-backend-development-with-jisse-reitsma). -::: - ## Prerequisites You'll need: @@ -21,8 +17,6 @@ You'll need: * A running Shopware 6 instance; refer to our [Install Shopware 6](../../installation/index.md) guide * full file system and command line access -`/custom/plugins` contains all plugins from the Shopware store. You install and manage these plugins via the Shopware Administration. - ## 1. Choose a name Use **UpperCamelCase**, which means that your plugin name must begin with a capital letter too. Whenever possible, begin it with a company prefix to avoid duplicate names (e.g., `SwagBasicExample`). Choose a name that describes your plugin as succinctly and clearly as possible. @@ -33,6 +27,8 @@ A vendor prefix is required if you plan to publish your plugin in the [Shopware ## 2. Generate the plugin structure +Plugins are located in `/custom/plugins` and managed via the Shopware Administration. + From your Shopware project's root directory, run: ```bash @@ -93,7 +89,7 @@ This file contains basic metadata that Shopware needs to know about your plugin, * The technical name * The description * The author -* The used license +* The license * The current plugin version * The required dependencies * and other configuration details. @@ -157,7 +153,7 @@ Here's an example `composer.json` you can refer to: If you change the `autoload.psr-4` path (for example, not using `src/`), adjust your directory structure accordingly. ::: -::: Info +::: info Set up [CI](../../development/testing/ci.md) early. Run static analysis, tests, and `shopware-cli extension build` in CI so your plugin ZIP is reproducible and safe to promote across environments. ::: @@ -171,7 +167,7 @@ composer config repositories.shopware composer https://packages.shopware.com Authentication via API token is required. Refer to ["Using Composer for plugin installation in Shopware"](https://www.shopware.com/en/news/using-composer-for-plugin-installation-in-shopware/) for detailed information. -### Manual creation (optional) +## Manual creation (optional) In most cases, you should use `bin/console plugin:create`. Manual creation is only useful if you need full control over the structure or are working in a custom setup. @@ -190,7 +186,7 @@ SwagBasicExample/ └── SwagBasicExample.php ``` -* **namespace**: here, it's `Swag\BasicExample`. We recommend using a combination of your manufacturer prefix and the technical name to name it. +* **Namespace**: here, it's `Swag\BasicExample`. We recommend using a combination of your manufacturer prefix and the technical name to name it. * **`src/` directory**: recommended but not strictly required. * **PHP class**: `SwagBasicExample.php`, which you name after your plugin. @@ -209,12 +205,6 @@ class SwagBasicExample extends Plugin } ``` -::: warning -If you change the `autoload.psr-4` path (for example, not using `src/`), your directory structure must match that configuration. -::: - -And that's it. The basic structure and all necessary files for your plugin to be installable are done. - ## Next steps [Install and activate](./install-activate-plugin.md) your plugin. diff --git a/guides/plugins/plugins/database/custom-fields-of-type-media.md b/guides/plugins/plugins/database/custom-fields-of-type-media.md index 63374d4591..f8f93428f5 100644 --- a/guides/plugins/plugins/database/custom-fields-of-type-media.md +++ b/guides/plugins/plugins/database/custom-fields-of-type-media.md @@ -6,11 +6,9 @@ nav: # Using Custom Fields of Type Media -## Overview - After adding a custom field of type media in the Administration or via a plugin, you can assign media objects to different entities. This is often used on products to add additional images to the product detail page. -If you want to learn more about custom fields, take a look at [Adding custom fields](../framework/custom-field/add-custom-field.md). +For more on custom fields, see [Adding custom fields](../framework/custom-field/add-custom-field.md). ## Resolve media custom fields in Twig @@ -21,10 +19,10 @@ In the product detail page template, `page.product.translated.customFields.xxx` public function searchMedia(array $ids, Context $context): MediaCollection { ... } ``` -This function resolves the corresponding media entities for the given IDs. Here is an example with a custom field \(`custom_sports_media_id`\) on the product detail page: +This function resolves the corresponding media entities for the given IDs. Here is an example with a custom field (`custom_sports_media_id`) on the product detail page: ```twig -// /src/Resources/views/storefront/page/content/product-detail.html.twig +{# /src/Resources/views/storefront/page/content/product-detail.html.twig #} {% sw_extends '@Storefront/storefront/page/product-detail/index.html.twig' %} {% block page_product_detail_media %} @@ -48,10 +46,10 @@ After loading the entity, you can use fields like `sportsMedia.url`, `sportsMedi This function performs a database query on every invocation and should therefore not be used inside a loop. To resolve multiple IDs at once, pass them as one array. -To read the media objects within the product listing, we recommend the following procedure: +To read the media objects within the product listing, use the following approach: ```twig -// /src/Resources/views/storefront/component/product/listing.html.twig +{# /src/Resources/views/storefront/component/product/listing.html.twig #} {% sw_extends '@Storefront/storefront/component/product/listing.html.twig' %} {% block element_product_listing_col %} diff --git a/guides/plugins/plugins/database/database-migrations.md b/guides/plugins/plugins/database/database-migrations.md index 05f349d57d..b3b59b6c09 100644 --- a/guides/plugins/plugins/database/database-migrations.md +++ b/guides/plugins/plugins/database/database-migrations.md @@ -7,10 +7,6 @@ nav: # Database Migrations -## Overview - -This guide covers what migrations are and how to use them. - Migrations are PHP classes used to manage incremental and reversible database schema changes. Shopware comes with a pre-built Migration System, to take away most of the work for you. Throughout this guide, you will find the `$` symbol representing your command line. ## Prerequisites @@ -34,7 +30,7 @@ By default, Shopware 6 is looking for migration files in a directory called `Mig └── SwagBasicExample.php ``` -As you can see there is one file in the `/src/Migration` directory. Below you find a break down of what each part of its name means. +As you can see there is one file in the `/src/Migration` directory. Below you'll find a breakdown of what each part of its name means. | File Name Snippet | Meaning | |:-------------------|:------------------------------------------------| @@ -106,11 +102,11 @@ class Migration1611740369ExampleDescription extends MigrationStep As you can see, your migration contains three methods: -* getCreationTimestamp\(\) -* update\(\) -* updateDestructive\(\) +* `getCreationTimestamp()` +* `update()` +* `updateDestructive()` -There is no need to change `getCreationTimestamp()`, it returns the timestamp that's also part of the file name. In the `update()` method you implement non-destructive changes which should always be **reversible**. The `updateDestructive()` method is the follow up step, that is run after `update()` and used for **destructive none reversible changes**, like dropping columns or tables. Destructive migrations are only executed explicitly. +There is no need to change `getCreationTimestamp()`, it returns the timestamp that's also part of the file name. In the `update()` method you implement non-destructive changes which should always be **reversible**. The `updateDestructive()` method is the follow-up step, that is run after `update()` and used for **destructive non-reversible changes**, like dropping columns or tables. Destructive migrations are only executed explicitly. ::: info You do not add instructions to revert your migrations within the migration class itself. `updateDestructive` is not meant to revert instructions in `update`. Reverting changes in the database is done explicitly in plugin lifecycle method `uninstall`, as explained in the [Plugin Lifecycle guide](../plugin-fundamentals/plugin-lifecycle.md#uninstall). @@ -169,7 +165,7 @@ This command will generate a new migration file including the `CREATE TABLE` or | Option | Meaning | |:-----------|:---------------------------------------------------------------------------------------------------------------------| | --bundle | The name of the plugin, when not provided the command will generate a migration in the core | -| --entities | Comma-seperated list of the entities it should create migrations for, it will generate one migration file per entity | +| --entities | Comma-separated list of the entities it should create migrations for, it will generate one migration file per entity | _Note: Your plugin has to be activated, otherwise your custom entity definition cannot be found._ @@ -194,7 +190,7 @@ $ ./bin/console database:migrate SwagBasicExample --all ## Advanced migration control -Once you have become familiar with the migration process and the development flow, you may want to have finer control over the migrations performed during the installation and update. In this case the `MigrationCollection` which is only filled with your specific migrations, can be accessed via the `InstallContext` and all its subclasses \(UpdateContext, ActivateContext, ...\). A plugin must reject the automatic execution of migrations in order to have control over the migrations that are executed. +Once you have become familiar with the migration process and the development flow, you may want to have finer control over the migrations performed during the installation and update. In this case the `MigrationCollection` which is only filled with your specific migrations, can be accessed via the `InstallContext` and all its subclasses (`UpdateContext`, `ActivateContext`, ...). A plugin must reject the automatic execution of migrations in order to have control over the migrations that are executed. Therefore, a typical update method might look more like this: @@ -213,4 +209,4 @@ Therefore, a typical update method might look more like this: } ``` -If you don't use the Shopware migration system, an empty collection \(NullObject\) will be in the context. +If you don't use the Shopware migration system, an empty collection (`NullObject`) will be in the context. diff --git a/guides/plugins/plugins/database/index.md b/guides/plugins/plugins/database/index.md index 024224b551..4efab2fe01 100644 --- a/guides/plugins/plugins/database/index.md +++ b/guides/plugins/plugins/database/index.md @@ -14,9 +14,7 @@ This section covers: * How to generate migrations from entity definitions * How to work with custom fields (e.g., media custom fields) -## Guides +Use migrations for schema changes and structural updates. Use custom fields to extend existing entities without modifying the core schema. * * - -Use migrations for schema changes and structural updates. Use custom fields to extend existing entities without modifying the core schema. diff --git a/guides/plugins/plugins/in-app-purchases.md b/guides/plugins/plugins/in-app-purchases.md index 5207d00c8d..1efc4a1367 100644 --- a/guides/plugins/plugins/in-app-purchases.md +++ b/guides/plugins/plugins/in-app-purchases.md @@ -8,7 +8,7 @@ nav: # In-App Purchases ::: info -In-App Purchase is available since Shopware version 6.6.9.0 +In-App Purchases are 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. @@ -20,9 +20,9 @@ and then offer a paid version with more features. ## Allow users to buy an In-App Purchase -In order to enable others to purchase your In-App Purchase, you must request a checkout for it via the `inAppPurchaseCheckout` store in the administration. +In order to enable others to purchase your In-App Purchase, you must request a checkout for it via the `inAppPurchaseCheckout` store in the Administration. The checkout process itself is provided by Shopware. -As this is purely functional, it is your responsibility to provide a button and hide it if the IAP cannot be purchased more than once. +It is your responsibility to provide a button and hide it if the IAP cannot be purchased more than once. ```ts { @@ -69,13 +69,15 @@ class Example If you want to check an in-app purchase in the administration: ```js -if (Shopware.InAppPurchase.isActive('MyExtensionName', 'my-iap-identifier')) {}; +if (Shopware.InAppPurchase.isActive('MyExtensionName', 'my-iap-identifier')) { + // ... +} ``` -## Event +## Listen to In-App Purchase events Apps are also able to manipulate the available In-App Purchases as described in - +. Plugins can listen to the `Shopware\Core\Framework\App\InAppPurchases\Event\InAppPurchasesGatewayEvent`. This event is dispatched after the In-App Purchases Gateway has received the app server response from a gateway diff --git a/guides/plugins/plugins/index.md b/guides/plugins/plugins/index.md index 3b8c7f01f2..556b61bef5 100644 --- a/guides/plugins/plugins/index.md +++ b/guides/plugins/plugins/index.md @@ -20,7 +20,7 @@ Plugins run directly inside the Shopware environment and provide full access to: Technically, plugins are extensions of [Symfony bundles](./bundle.md). They follow a defined directory structure and, when used as managed extensions, provide a lifecycle (install, update, deactivate, uninstall). -Plugins can ship their own assets, controllers, services, and tests, enabling deep platform and full extensibility across core and custom functionality. +Plugins can ship their own assets, controllers, services, and tests, enabling deep extensibility across core and custom functionality. ## When to create and use a plugin @@ -99,7 +99,7 @@ Managed plugins are commonly used for marketplace-distributed extensions. They a ### Bundles -Symfony-based [bundles](../plugins/bundle.md) are installed via Composer. They do not have a Shopware plugin lifecycle and are not managed via the Administration. +Symfony-based [bundles](./bundle.md) are installed via Composer. They do not have a Shopware plugin lifecycle and are not managed via the Administration. Bundles are useful when you want: @@ -119,7 +119,7 @@ For custom projects, it is often preferable to: * Share one CI pipeline and one set of static analysis rules * Organize functionality through clean internal directory structure -It does not matter whether static plugins or Symfony bundles internally are used, as much as having: +It does not matter whether static plugins or Symfony bundles are used internally, as much as having: * Clear domain boundaries * Consistent structure diff --git a/guides/plugins/plugins/install-activate-plugin.md b/guides/plugins/plugins/install-activate-plugin.md index ef4ccd9b29..076e6ae078 100644 --- a/guides/plugins/plugins/install-activate-plugin.md +++ b/guides/plugins/plugins/install-activate-plugin.md @@ -15,7 +15,7 @@ From your Shopware project root directory, refresh the list of plugins: bin/console plugin:refresh ``` -A warning about the `version` field of the `composer.json` file might appear; this can be ignored. You should see a list like this: +You should see a list like this: ```bash Shopware Plugin Service @@ -28,7 +28,11 @@ Shopware Plugin Service ------------------------------ -------------------------------------------- ----------- ----------------- ---------------------------- ----------- -------- ------------- ``` -This output is a **good sign**, because this means Shopware recognized your plugin successfully. +This output confirms the plugin was loaded correctly. + +::: info +If a warning about the `version` field in `composer.json` appears, it is expected and does not affect the result. +::: Now install and activate: @@ -36,7 +40,7 @@ Now install and activate: bin/console plugin:install --activate SwagBasicExample ``` -This should print the following output: +This prints the following output: ```bash Shopware Plugin Lifecycle Service @@ -48,7 +52,7 @@ Shopware Plugin Lifecycle Service Plugin "SwagBasicExample" has been installed and activated successfully. ``` -If successful, your plugin is now active and ready to use! +Your plugin is now installed and active. ## Next steps diff --git a/guides/plugins/plugins/mcp-server.md b/guides/plugins/plugins/mcp-server.md index 54f53b2456..31a033cabf 100644 --- a/guides/plugins/plugins/mcp-server.md +++ b/guides/plugins/plugins/mcp-server.md @@ -93,7 +93,7 @@ class MyTool extends McpToolResponse **Key rules:** -- `#[McpTool]` goes on the class, not on `__invoke()`. The MCP compiler passes read class-level attributes; method-level attributes are silently ignored. +- `#[McpTool]` goes on the class, not on `__invoke()`. The MCP compiler reads class-level attributes; method-level attributes are silently ignored. - `title` is optional. When set, MCP clients (Claude Desktop, Cursor, etc.) display it in their tool list instead of the machine-readable `name`. Omit it if you have no better label to offer. - Names must only contain `a-zA-Z0-9_-`. - Parameter types on `__invoke()` are mapped to JSON schema. Supported: `string`, `int`, `float`, `bool`. Default values make parameters optional. @@ -153,7 +153,7 @@ In `src/Resources/config/services.xml`, tag the service with `shopware.mcp.tool` ``` -Plugin tools use `shopware.mcp.tool` (not `mcp.tool`). The MCP compiler passes remap this tag to `mcp.tool` at compile time and registers the tool with the MCP server builder. You do not need a `shopware.feature` flag tag; the MCP feature flag gates the server endpoint itself, and once it is enabled, all registered tools are available. +Plugin tools use `shopware.mcp.tool` (not `mcp.tool`). The MCP compiler remaps this tag to `mcp.tool` at compile time and registers the tool with the MCP server builder. You do not need a `shopware.feature` flag tag; the MCP feature flag gates the server endpoint itself, and once it is enabled, all registered tools are available. ### Available tags diff --git a/guides/plugins/plugins/plugin-base-guide.md b/guides/plugins/plugins/plugin-base-guide.md index c863a34cde..e71626751a 100644 --- a/guides/plugins/plugins/plugin-base-guide.md +++ b/guides/plugins/plugins/plugin-base-guide.md @@ -7,24 +7,22 @@ nav: # Plugin Base Guide -## Overview - This guide outlines the typical development flow when creating a Shopware plugin, using the recommended static plugin approach. Core concepts apply to all plugin types. Not every plugin requires all steps. ## Typical plugin development flow 1. [Create the plugin structure](creating-plugins.md) 2. [Install and activate the plugin](install-activate-plugin.md) -3. [Understand the plugin lifecycle](../plugins/plugin-fundamentals/plugin-lifecycle.md) -4. [Add plugin configuration](../plugins/plugin-fundamentals/add-plugin-configuration.md) -5. [Register services](../plugins/services/index.md) and use [dependency injection](../plugins/services/dependency-injection.md) -6. [Listen to events](../plugins/framework/event/listening-to-events.md) or [decorate services](../plugins/services/adjusting-service.md#decorating-the-service) -7. Extend the platform (either or both): [Storefront](../plugins/storefront/index.md), [Administration](../plugins/administration/index.md) -8. [Add database migrations](../plugins/database/database-migrations.md) (if required) -9. [Add scheduled tasks](../plugins/plugin-fundamentals/add-scheduled-task.md) or [CLI commands](../plugins/plugin-fundamentals/add-custom-commands.md) (if required) -10. Add configuration: [npm](../plugins/dependencies/using-npm-dependencies.md), [Composer](../plugins/dependencies/using-composer-dependencies.md) (if required) -11. [Write tests](../../development/testing/index.md): CI and upgrade safety: Configure [CI](../../development/testing/ci.md) to run static analysis, tests, and produce reproducible artifacts to avoid upgrade regressions. -12. Add [diagnostics](../plugins/plugin-fundamentals/logging.md) +3. [Understand the plugin lifecycle](plugin-fundamentals/plugin-lifecycle.md) +4. [Add plugin configuration](plugin-fundamentals/add-plugin-configuration.md) +5. [Register services](services/index.md) and use [dependency injection](services/dependency-injection.md) +6. [Listen to events](framework/event/listening-to-events.md) or [decorate services](services/adjusting-service.md#decorating-the-service) +7. Extend the platform (either or both): [Storefront](storefront/index.md), [Administration](administration/index.md) +8. [Add database migrations](database/database-migrations.md) (if required) +9. [Add scheduled tasks](plugin-fundamentals/add-scheduled-task.md) or [CLI commands](plugin-fundamentals/add-custom-commands.md) (if required) +10. Add dependencies: [npm](dependencies/using-npm-dependencies.md), [Composer](dependencies/using-composer-dependencies.md) (if required) +11. [Write tests](../../development/testing/index.md) and configure [CI](../../development/testing/ci.md) +12. Add [diagnostics](plugin-fundamentals/logging.md) ## Upgrade readiness @@ -35,7 +33,3 @@ Design plugins so that: * Domain logic is encapsulated behind services Upgrades are easier when the plugin surface area is small and well-structured. - -## Getting started - -The first step is to [create the plugin structure](../plugins/creating-plugins.md). diff --git a/guides/plugins/plugins/plugin-fundamentals/add-custom-commands.md b/guides/plugins/plugins/plugin-fundamentals/add-custom-commands.md index e7eb2d8b13..c017c06314 100644 --- a/guides/plugins/plugins/plugin-fundamentals/add-custom-commands.md +++ b/guides/plugins/plugins/plugin-fundamentals/add-custom-commands.md @@ -18,6 +18,31 @@ $services->set(Swag\BasicExample\Command\ExampleCommand::class) Commands registered as services in a Shopware plugin are automatically available via `bin/console`. -## Other interesting topics +A minimal command class: + +```php +// /src/Command/ExampleCommand.php +writeln('Hello from ExampleCommand'); + + return Command::SUCCESS; + } +} +``` + +## Next steps * [Adding a scheduled task](add-scheduled-task.md) diff --git a/guides/plugins/plugins/plugin-fundamentals/add-plugin-configuration.md b/guides/plugins/plugins/plugin-fundamentals/add-plugin-configuration.md index 2274a54eb7..03be359df3 100644 --- a/guides/plugins/plugins/plugin-fundamentals/add-plugin-configuration.md +++ b/guides/plugins/plugins/plugin-fundamentals/add-plugin-configuration.md @@ -77,27 +77,32 @@ By default, the `lang` attribute is set to `en-GB`, to change the locale of a `< ... English Title - German Titel + German Title ... ``` ### Input fields -As you can see above, every `` has to contain at least a `` element. +Every `` must contain at least a `` element. The `` element is not translatable and has to be unique, since it will be used as the technical identifier for the config element. The field `` must at least be 4 characters long and consist of only lower and upper case letters. It can contain numbers, but not at first place - see this RegEx pattern: `[a-zA-Z][a-zA-Z0-9]*` +```html + ... + + exampleField + + ... +``` + ### The different types of input field Your `` can be of different types, this is managed via the `type` attribute. Unless defined otherwise, your `` will be a text field. Below you'll find a list of all available ``. -
-Supported input field types - | Type | Configuration settings | Renders | Default value example | |:--------------|:------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|:------------------|:----------------------------------------| | text | [copyable](add-plugin-configuration.md#copyable), [placeholder](add-plugin-configuration.md#label-placeholder-and-help-text), [length](add-plugin-configuration.md#text-length-restrictions) | Text field | Some text | @@ -116,14 +121,12 @@ Below you'll find a list of all available ``. | single-select | [options](add-plugin-configuration.md#options), [placeholder](add-plugin-configuration.md#label-placeholder-and-help-text) | Single-Select box | option_id | | multi-select | [options](add-plugin-configuration.md#options), [placeholder](add-plugin-configuration.md#label-placeholder-and-help-text) | Multi-Select box | [option_id1, option_id2] | -
- ### Input field settings These settings are used to configure your ``. **Every `` has to start with the `` element.** After the `` element you can configure any of the other settings mentioned above. -Beside these settings, they have the following in common: +Besides these settings, they have the following in common: [label](add-plugin-configuration.md#label-placeholder-and-help-text), [helpText](add-plugin-configuration.md#label-placeholder-and-help-text), [defaultValue](add-plugin-configuration.md#defaultvalue), @@ -136,6 +139,18 @@ The settings `