1. Why is this change necessary?

Handling of more than 100 Custom-Field-Sets were broken. (For Sets which were not within the first 100 were unable to populate its fields.

2. What does this change do, exactly?

Fixes the described scenario.

1. Fetches the Product Fieldset without a limit and its related fields. (increases performance when there are 500 custom-field-sets for products (approx. 15MB were transfered before the page was usable))
2. Populates only the attached Field-Sets with fields
3. when adding new Sets to the Product we fetch the associated fields for this set only.

3. Describe each step to reproduce the issue or behaviour.

1. Create more than 100 Product Custom Field Sets (with at least 1 Field)
2. Create a product
3. Try to attach the 101st Field-Set

4. Please link to the relevant issues (if any).

#2448

5. Checklist

• [x] I have written tests and verified that they fail without my change
• [x] I have created a changelog file with all necessary information about my changes
• [ ] I have written or adjusted the documentation according to my changes
• [x] This change has comments for package types, values, functions, and non-obvious lines of code
• [x] I have read the contribution requirements and fulfil them.

PHP Version

7.4 & 8.0

Shopware Version

6.4.10.0

Expected behaviour

Admin plugins that are built under Shopware < 6.4.10.0 should be compatible with Shopware 6.4.10.0 either and vice versa.

I can also not use a plugin that is built under 6.4.10.0 in shopware <= 6.4.9.0

Actual behaviour

Plugin is built with bin/build-administration.sh under Shopware 6.4.9.0. The compiled .js file should also work under 6.4.10.0.

There is no error message in the admin and also no error message in the developer console.

How to reproduce

Just call bin/build-administration.sh in a shopware version smaller than 6.4.10.0 and try to use this in 6.4.10.0.

1. Why is this change necessary?

There is still no really good way to version community store plugins.

1. sw:store:download is not available in shopware 6 yet
2. packages.friendsofshopware.com is not officially supported

Now you can at least version a downloaded plugin file and simply do: bin/console plugin:zip-import SwagBundle.zip && bin/console plugin:install --activate SwagBundle

2. What does this change do, exactly?

Add a new command to import plugin zip files. Add optional parameter to disable file deletion on import via CLI.

3. Describe each step to reproduce the issue or behaviour.

1. Have a previously downloaded plugin zip file
2. Open /admin
3. Open plugin management
4. Upload zip file
5. Install plugin
6. Activate plugin
7. Be annoyed that it is not possible via CLI in an easy way to do the same

4. Checklist

• [ ] I have written tests and verified that they fail without my change
• [x] I have squashed any insignificant commits
• [ ] I have written or adjusted the documentation according to my changes
• [ ] This change has comments for package types, values, functions, and non-obvious lines of code
• [x] I have read the contribution requirements and fulfil them.

1. Why is this change necessary?

This prevents data loss.

2. What does this change do, exactly?

On constructing a collection it takes the same keys from the iteratable input for storing the elements internally.

3. Describe each step to reproduce the issue or behaviour.

1. Have a dataset indexed by a key so you can easily look that up
2. Add static types by wrapping in typed collection
3. Use get to get item by indexed key
4. Retrieved item is null

4. Checklist

• [ ] I have written tests and verified that they fail without my change
• [x] I have squashed any insignificant commits
• [ ] I have written or adjusted the documentation according to my changes
• [ ] This change has comments for package types, values, functions, and non-obvious lines of code
• [x] I have read the contribution requirements and fulfil them.

1. Why is this change necessary?

For better user experience there should be a function related title on the buttons in sw-text-editor-toolbar. Ref #669

2. What does this change do, exactly?

Introduced titles. Reset titles in submenu, to prevent displaying parent titles. Remove margin on left side of tooltips with light appearance, cause this doesn't sound relevant and looks weird in CMS. Special thanks to @taltholtmann and @tobiasberge :-)

3. Describe each step to reproduce the issue or behaviour.

4. Please link to the relevant issues (if any).

https://issues.shopware.com/issues/NEXT-7780

5. Checklist

• [ ] I have written tests and verified that they fail without my change
• [x] I have squashed any insignificant commits
• [x] I have written or adjusted the documentation according to my changes
• [x] This change has comments for package types, values, functions, and non-obvious lines of code
• [x] I have read the contribution requirements and fulfil them.

1. Why is this change necessary?

The phpdocs for the route defaults does not match the typehint in the arguments. This results in an an exception on the php side as the type constraint is not fulfilled. So the validity check whether the parameter is ok is never reached and no readable exception is thrown/logged.

2. What does this change do, exactly?

Loosen up the typehint by adding nullability.

3. Describe each step to reproduce the issue or behaviour.

1. Do not configure contact layout page
2. Click on contact in storefront
3. Do not get a contact form
4. Look in logs
5. Uncaught PHP Exception TypeError: "Argument 1 passed to Shopware\Storefront\Controller\CmsController::page() must be of the type string, null given
6. Expecting Parameter "Parameter id missing" is missing.
7. Wut?
8. Check message concatenation for MissingRequestParameterException
9. See weird refactoring result
10. Take notes for next pull request

4. Checklist

• [ ] I have written tests and verified that they fail without my change
• [x] I have squashed any insignificant commits
• [ ] I have written or adjusted the documentation according to my changes
• [ ] This change has comments for package types, values, functions, and non-obvious lines of code
• [x] I have read the contribution requirements and fulfil them.

1. Why is this change necessary?

It is useless to copy the same config fields accross themes. Why can I set a parentThemeId when it is not using the inheritance (confusing).

2. What does this change do, exactly?

It allows to inherit the config fields from a parent theme

3. Describe each step to reproduce the issue or behaviour.

Create two themes, add one theme as parentTheme via API, try to build the childTheme after that (there will be also a core bug) Create some config fields ... there is no inheritance from parent to child.

4. Please link to the relevant issues (if any).

See https://github.com/shopware/platform/issues/1227 and https://github.com/shopware/platform/issues/507

5. Checklist

• [X] I have run the core tests without any error
• [X] I have squashed any insignificant commits
• [X] I have created a changelog file with all necessary information about my changes
• [X] I have written or adjusted the documentation according to my changes
• [ ] This change has comments for package types, values, functions, and non-obvious lines of code
• [X] I have read the contribution requirements and fulfil them.

@OliverSkroblin As discussed. #1668 should be merged first. After that I can rebase my branch to the then-current trunk.

1. Why is this change necessary?

This PR fixes various transaction issues and improves data consistency.

2. What does this change do, exactly?

• All calls to beginTransaction have been replaced with the new RetryableTransaction class, as it provides a cleaner interface anyway and the previous code did not execute rollback on exceptions.
• MultiInsertQueryQueue now uses RetryableTransaction as well as there is no use case where it is desirable that half of the inserts is in the DB and then the execution of the script stops and the other half is left in the wide nothingness.
• Introduced transactions at multiple code positions to improve data consistency. Also removed all attempts to be smarter than the DBMS in case of a deadlock and try non-batchy execution of queries; executing single statements not within a transaction can lead to data inconsistency; executing single statements inside of a transaction is in no case beneficial to a batch statement. Catching exceptions also breaks the transaction control flow, i.e. they are not reverted correctly.

3. Describe each step to reproduce the issue or behaviour.

4. Please link to the relevant issues (if any).

This fixes all issues I mentioned in the pull request #1668. This also fixes https://issues.shopware.com/issues/NEXT-15805.

5. Checklist

• [ ] I have written tests and verified that they fail without my change
• [ ] I have squashed any insignificant commits
• [ ] I have created a changelog file with all necessary information about my changes
• [ ] I have written or adjusted the documentation according to my changes
• [ ] This change has comments for package types, values, functions, and non-obvious lines of code
• [ ] I have read the contribution requirements and fulfill them.

6. To-Do-List

• [x] If you have code-style enforcers, you might want to make sure that nobody introduces new beginTransaction, commit or rollback calls. All transactions should be implemented using RetryableTransaction.
• [x] I've encountered some other occurrences of catch (\Exception) or catch (\Throwable). This is code-smell, i.e. one likely never wants to catch ALL exceptions. You might want to review (i.e. remove) these.
• [ ] The last commit ("Make batch behave like previous non-batch") makes the code behave like previously, but I don't think it is a good idea to ignore all errors. The best way would be to fix the code such that the IGNOREs are not necessary anymore. The second-best solution is to change RetryableTransaction to pass an argument to the transactional closure (I guess this has to be done via Closure::bind to not interfere with Doctrine), passing in its retry $counter so the closure can determine if this is the first execution or a following one. In the following cases, it could perform an INSERT IGNORE instead.
• [ ] Call $connection->setNestTransactionsWithSavepoints(true) globally.

1. Why is this change necessary?

For easier usability of console commands.

Did you ever recognized a whole uuid? Do you know by heart what the plugin was spelled?

Examples in usage were already shown in the pull request for shopware 5.

2. What does this change do, exactly?

Implements for all core/shipped commands the CompletionAwareInterface Adds hints in the documentation

3. Describe each step to reproduce the issue or behaviour.

Press tab to complete your shopware console commands. It just does not work.

4. Which documentation changes (if any) need to be made because of this PR?

☑ https://docs.shopware.com should get a hint on the setup and pros. There is a complementary pull request to https://github.com/shopware/development/pull/20 to ensure this features is ready in the default docker container.

1. Why is this change necessary?

When you run in prod mode and have an elastichsearch falling back to database search you don't know why because neither a log message is logged or an exception is thrown.

2. What does this change do, exactly?

Log in any case of an exception before environment evaluation is done.

3. Describe each step to reproduce the issue or behaviour.

1. Use plugins that extend elasticsearch queries
2. Have a slow page or weird behaviour when enabling elastic based search
3. No hints in the log files

4. Checklist

Is there a legit way how to test it when the first check literally is: am I in a test?

• [ ] I have written tests and verified that they fail without my change
• [x] I have squashed any insignificant commits
• [x] I have created a changelog file with all necessary information about my changes
• [ ] I have written or adjusted the documentation according to my changes
• [ ] This change has comments for package types, values, functions, and non-obvious lines of code
• [x] I have read the contribution requirements and fulfil them.

1. Why is this change necessary?

As discussed with @OliverSkroblin when writing entities in multiple threads and/or transactions at the same time deadlocks may occur in the database. When a deadlock occurs within a transaction, MySQL rolls back the transaction internally. Therefore the whole transaction can be retried. This is also stated in the MySQL error message:

ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction

The EntityWriteGateway uses a transaction but uses a RetryableQuery inside this transaction (code). In case of a deadlock a single query of the transaction is now retried (code) even though the transaction was already rolled back internally by the database. Since queries inside a multi-query-transaction may depend on each other, this causes all kinds of unintended behaviour (i.e. foreign key constraint violations). The description of the RetryableException that is caught also suggest to retry the transaction, not a single query. Therefore the usage of the current RetryableQuery only works when running a single query in no transaction.

2. What does this change do, exactly?

This PR adds a RetryableTransaction class which can be used to execute a number of commands (queries) inside a transaction which can be rolled back and retried as a whole without side effects or unwanted behaviour. Additionally the current usages of RetryableQuery are updated to check whether or not the query is executed inside a transaction. Now if this is the case, the RetryableQuery will not be retried when a deadlock occurs. For that the functions execute and retryable have been backwards-compatibly updated to accept a Doctrine\DBAL\Connection $connection to ensure this new safe behaviour.

3. Describe each step to reproduce the issue or behaviour.

Run two complex processes, e.g. create new versions of an existing order and update many products at the same time. A real life example is the order document creation via the administration. This creates a new order version and triggers a complex product subscriber from the Pickware ERP plugin. Since this is a race condition error, your results may vary.

4. Please link to the relevant issues (if any).

5. Checklist

• [ ] I have written tests and verified that they fail without my change
• [x] I have squashed any insignificant commits
• [x] I have created a changelog file with all necessary information about my changes
• [x] I have written or adjusted the documentation according to my changes
• [x] This change has comments for package types, values, functions, and non-obvious lines of code
• [x] I have read the contribution requirements and fulfil them.

Please describe the feature you would like to see implemented.

Hi all,

In my opinion there are some setting missing in de (admin)user profile;

1. By default '25 items per page' are shown in the Admin, would be great if we can make this an option under (admin)user setting. This can be very handy with large amount of products/orders/clients.
2. Select default screen language (not interface language), if multi languages are available for the front-end.

Would be great if this can be added to SW. Thanks, Tim

PHP Version

8.1

Shopware Version

6.4.18

Expected behaviour

When I assign the 'Edit' permission on product (or media?) I should be able to change media of a product in the API.

Actual behaviour

I get the error

{"message":"Missing privilege","missingPrivileges":["product_media:update","product_media:update","product_media:update"]}

How to reproduce

Create a role with the above permissions and try to patch product media.

I think the product_media:read permission should be added to one of these admin permissions.

PHP Version

8.1.13

Shopware Version

6.4.18.0

Expected behaviour

After a fresh install on Windows and having generated the required jwt/config/private.pem and jwt/config/public.pem files, starting the server symfony server:start -d and accessing the admin login page, both files should be correctly read from disk so the authorization server can be instantiated by the container and the whole page can function.

Actual behaviour

You get an exception:

{
	code: "0",
	status: "500",
	title: "Internal Server Error",
	detail: "User Notice: Key file "file://C:\projects\personal\project/config/jwt/public.pem" permissions are not correct, recommend changing to 600 or 660 instead of 666",
	meta: {
		// ...
	}
}

{
	"errors": [
		{
			"code": "0",
			"status": "500",
			"title": "Internal Server Error",
			"detail": "User Notice: Key file \u0022file://C:\\projects\\personal\\project/config/jwt/public.pem\u0022 permissions are not correct, recommend changing to 600 or 660 instead of 666",
			"meta": {
				"trace": [
					{
						"file": "C:\\projects\\personal\\project\\var\\cache\\dev_hae705bf1e4f7057c4da9d57bc278047b\\Container5V6QJWM\\Shopware_Core_KernelDevDebugContainer.php",
						"line": 22661,
						"function": "__construct",
						"class": "League\\OAuth2\\Server\\CryptKey",
						"type": "-\u003E"
					},
					{
						"file": "C:\\projects\\personal\\project\\var\\cache\\dev_hae705bf1e4f7057c4da9d57bc278047b\\Container5V6QJWM\\Shopware_Core_KernelDevDebugContainer.php",
						"line": 11913,
						"function": "getApiAuthenticationListenerService",
						"class": "Container5V6QJWM\\Shopware_Core_KernelDevDebugContainer",
						"type": "-\u003E"
					},
					{
						"file": "C:\\projects\\personal\\project\\vendor\\symfony\\event-dispatcher\\EventDispatcher.php",
						"line": 245,
						"function": "Container5V6QJWM\\{closure}",
						"class": "Container5V6QJWM\\Shopware_Core_KernelDevDebugContainer",
						"type": "-\u003E"
					},
					{
						"file": "C:\\projects\\personal\\project\\vendor\\symfony\\event-dispatcher\\EventDispatcher.php",
						"line": 76,
						"function": "sortListeners",
						"class": "Symfony\\Component\\EventDispatcher\\EventDispatcher",
						"type": "-\u003E"
					},
					{
						"file": "C:\\projects\\personal\\project\\vendor\\shopware\\core\\Content\\Flow\\Dispatching\\FlowDispatcher.php",
						"line": 126,
						"function": "getListeners",
						"class": "Symfony\\Component\\EventDispatcher\\EventDispatcher",
						"type": "-\u003E"
					},
					{
						"file": "C:\\projects\\personal\\project\\vendor\\shopware\\core\\Framework\\Webhook\\WebhookDispatcher.php",
						"line": 161,
						"function": "getListeners",
						"class": "Shopware\\Core\\Content\\Flow\\Dispatching\\FlowDispatcher",
						"type": "-\u003E"
					},
					{
						"file": "C:\\projects\\personal\\project\\vendor\\shopware\\core\\Framework\\Event\\BusinessEventDispatcher.php",
						"line": 100,
						"function": "getListeners",
						"class": "Shopware\\Core\\Framework\\Webhook\\WebhookDispatcher",
						"type": "-\u003E"
					},
					{
						"file": "C:\\projects\\personal\\project\\vendor\\shopware\\core\\Framework\\Event\\NestedEventDispatcher.php",
						"line": 69,
						"function": "getListeners",
						"class": "Shopware\\Core\\Framework\\Event\\BusinessEventDispatcher",
						"type": "-\u003E"
					},
					{
						"file": "C:\\projects\\personal\\project\\vendor\\symfony\\event-dispatcher\\Debug\\TraceableEventDispatcher.php",
						"line": 293,
						"function": "getListeners",
						"class": "Shopware\\Core\\Framework\\Event\\NestedEventDispatcher",
						"type": "-\u003E"
					},
					{
						"file": "C:\\projects\\personal\\project\\vendor\\symfony\\event-dispatcher\\Debug\\TraceableEventDispatcher.php",
						"line": 148,
						"function": "preProcess",
						"class": "Symfony\\Component\\EventDispatcher\\Debug\\TraceableEventDispatcher",
						"type": "-\u003E"
					},
					{
						"file": "C:\\projects\\personal\\project\\vendor\\symfony\\http-kernel\\HttpKernel.php",
						"line": 139,
						"function": "dispatch",
						"class": "Symfony\\Component\\EventDispatcher\\Debug\\TraceableEventDispatcher",
						"type": "-\u003E"
					},
					{
						"file": "C:\\projects\\personal\\project\\vendor\\symfony\\http-kernel\\HttpKernel.php",
						"line": 75,
						"function": "handleRaw",
						"class": "Symfony\\Component\\HttpKernel\\HttpKernel",
						"type": "-\u003E"
					},
					{
						"file": "C:\\projects\\personal\\project\\vendor\\symfony\\http-kernel\\Kernel.php",
						"line": 202,
						"function": "handle",
						"class": "Symfony\\Component\\HttpKernel\\HttpKernel",
						"type": "-\u003E"
					},
					{
						"file": "C:\\projects\\personal\\project\\vendor\\symfony\\http-kernel\\HttpCache\\SubRequestHandler.php",
						"line": 86,
						"function": "handle",
						"class": "Symfony\\Component\\HttpKernel\\Kernel",
						"type": "-\u003E"
					},
					{
						"file": "C:\\projects\\personal\\project\\vendor\\symfony\\http-kernel\\HttpCache\\HttpCache.php",
						"line": 479,
						"function": "handle",
						"class": "Symfony\\Component\\HttpKernel\\HttpCache\\SubRequestHandler",
						"type": "::"
					},
					{
						"file": "C:\\projects\\personal\\project\\vendor\\symfony\\http-kernel\\HttpCache\\HttpCache.php",
						"line": 452,
						"function": "forward",
						"class": "Symfony\\Component\\HttpKernel\\HttpCache\\HttpCache",
						"type": "-\u003E"
					},
					{
						"file": "C:\\projects\\personal\\project\\vendor\\symfony\\http-kernel\\HttpCache\\HttpCache.php",
						"line": 346,
						"function": "fetch",
						"class": "Symfony\\Component\\HttpKernel\\HttpCache\\HttpCache",
						"type": "-\u003E"
					},
					{
						"file": "C:\\projects\\personal\\project\\vendor\\symfony\\http-kernel\\HttpCache\\HttpCache.php",
						"line": 224,
						"function": "lookup",
						"class": "Symfony\\Component\\HttpKernel\\HttpCache\\HttpCache",
						"type": "-\u003E"
					},
					{
						"file": "C:\\projects\\personal\\project\\vendor\\shopware\\core\\HttpKernel.php",
						"line": 154,
						"function": "handle",
						"class": "Symfony\\Component\\HttpKernel\\HttpCache\\HttpCache",
						"type": "-\u003E"
					},
					{
						"file": "C:\\projects\\personal\\project\\vendor\\shopware\\core\\HttpKernel.php",
						"line": 79,
						"function": "doHandle",
						"class": "Shopware\\Core\\HttpKernel",
						"type": "-\u003E"
					},
					{
						"file": "C:\\projects\\personal\\project\\public\\index.php",
						"line": 76,
						"function": "handle",
						"class": "Shopware\\Core\\HttpKernel",
						"type": "-\u003E"
					},
					{
						"file": "C:\\projects\\personal\\project\\vendor\\symfony\\runtime\\Runner\\Symfony\\HttpKernelRunner.php",
						"line": 35,
						"function": "handle",
						"class": "Symfony\\Component\\HttpKernel\\HttpKernelInterface@anonymous\u0000C:\\projects\\personal\\project\\public\\index.php:66$1776",
						"type": "-\u003E"
					},
					{
						"file": "C:\\projects\\personal\\project\\vendor\\autoload_runtime.php",
						"line": 29,
						"function": "run",
						"class": "Symfony\\Component\\Runtime\\Runner\\Symfony\\HttpKernelRunner",
						"type": "-\u003E"
					},
					{
						"file": "C:\\projects\\personal\\project\\public\\index.php",
						"line": 12,
						"args": [
							"C:\\projects\\personal\\project\\vendor\\autoload_runtime.php"
						],
						"function": "require_once"
					}
				],
				"file": "C:\\projects\\personal\\project\\vendor\\league\\oauth2-server\\src\\CryptKey.php",
				"line": 80
			}
		}
	]
}

How to reproduce

On a Windows 11 machine, with PHP v8.1.13, Symfony CLI v5.4.20 and Docker v20.10.21 installed, run the following commands, from this repository's README.md:

> composer create-project shopware/production:dev-flex project
> cd project
> docker compose up -d
> symfony console system:install --basic-setup --drop-database --create-database -f
> symfony server:start -d

Then, generate your secret files and remember to set the password to shopware:

> openssl genrsa -out ./config/jwt/private.pem -aes256 4096
> openssl rsa -pubout -in ./config/jwt/private.pem -out ./config/jwt/public.pem

Finally, visit localhost:8000/admin. You should be greeted with the previously mentioned error.

Further Context

This happens because League\OAuth2\Server\CryptKey::__construct by default checks for file permissions. While that is a perfectly valid idea in Linux, in Windows files don't follow a similar permission system as as such, when requested, PHP always returns 666. This can be a pain for Windows developers and packages such as laravel/passport have decided to disable it by default, by passing the false as the third parameter of the constructor. It seems to be the maintainers "recommendation" as per https://github.com/thephpleague/oauth2-server/issues/779.

Now I'm really new to Shopware (this really was my first attempt at installing it), but it seems to me that simply editing shopware\core\Framework\DependencyInjection\api.xml definitions to pass false as the last argument should work. For testing purposes, I replaced old definitions in my vendor folder with the ones below, and it worked™.

<service class="League\OAuth2\Server\CryptKey" id="shopware.private_key">
    <argument>file://%kernel.project_dir%/config/jwt/private.pem</argument>
    <argument>shopware</argument>
+    <argument>false</argument>
</service>
<service class="League\OAuth2\Server\CryptKey" id="shopware.public_key">
    <argument>file://%kernel.project_dir%/config/jwt/public.pem</argument>
+    <argument>null</argument>
+    <argument>false</argument>
</service>

Perhaps not always disabling it, but only on Windows? I think this could be done with <argument type="expression">PHP_OS_FAMILY !== 'Windows'</argument>, but I haven't tested it.

Either way, I would be happy to work on a PR to solve this issue if you could point me in the right direction.

1. Why is this change necessary?

To fix #2902

2. What does this change do, exactly?

Add the correct snippets, and improve consistent dotting in the fallback messages.

3. Describe each step to reproduce the issue or behaviour.

Create a random promotion and cause a error (place the end date before the start date)
See that the text is english

4. Please link to the relevant issues (if any).

#2902

5. Checklist

• [X] I have rebased my changes to remove merge conflicts
• [X] I have written tests and verified that they fail without my change
• [X] I have created a changelog file with all necessary information about my changes
• [X] I have written or adjusted the documentation according to my changes
• [X] This change has comments for package types, values, functions, and non-obvious lines of code
• [X] I have read the contribution requirements and fulfil them.

PHP Version

trunk

Shopware Version

trunk

Expected behaviour

Error messages (like "End date needs to be after the start date") should be localized to the users language

Actual behaviour

Only the english messages are shown

How to reproduce

1. Create a random promotion and cause a error (place the end date before the start date)
2. See that the text is english

This because here https://github.com/shopware/platform/blob/e91d42f995e192aac6f2504a950ad55fb9b13ccc/src/Core/Checkout/Promotion/Validator/PromotionValidator.php#L245-L251 and all the other buildViolation calls a snippet key is defined, but the snippet is not, so the default english fallback is used.

1. Why is this change necessary?

Plugins may want to add cart validators which prevent a user from submitting the order, but don't stop him from retrying.

2. What does this change do, exactly?

It adds a error collector which collects cart errors with a blockResubmit option, just like blockOrder. The error collector checks if the corresponding errors even own such a method, so it does not fail if a error does not have the attribute, it's purely optional and fully backwards compatible. And it adds a check in the Twig template for the cart submit button for this very attribute.

3. Describe each step to reproduce the issue or behaviour.

Trigger a cart error (add a product, set shipping to country XYZ, go to checkout, before you checkout remove that country from your storefront, try to submit), add the method blockResubmit to the error which returns a boolean false, and you should see that the order is blocked, but you can retry. E.g. ShippingAddressBlockedError.php

4. Please link to the relevant issues (if any).

#2898

5. Checklist

• [X] I have rebased my changes to remove merge conflicts
• [X] I have written tests and verified that they fail without my change Yes 0727377
• [X] I have created a changelog file with all necessary information about my changes
• [X] I have written or adjusted the documentation according to my changes https://github.com/shopware/docs/pull/800
• [X] This change has comments for package types, values, functions, and non-obvious lines of code
• [X] I have read the contribution requirements and fulfil them.