1. Why is this change necessary?

I'ts possible to use special translations for each shop at shopware's backend and to the db. When the Snippet-DB-Adapter dumps the snippets to an ini file, the only sections that will get interpreted are the locales. That causes trouble when snippets for the same locale BUT different shops are translated differently. When importing back, the snippets are ONLY imported for the shopID 1. That results in massive and unacceptable data missmatches when im/ex - porting several times.

2. What does this change do, exactly?

Now all relevant shop-ids will be collected before exporting. The snippets will be stored under its own ini section ({shopId}/{locale}). The sections also will get interpreted correctly upon import. Here you can take a look for new Ini-File Structure: excample.ini.txt

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

1. Configure 2 shops with the same locale.
2. Translate a snippet for the second shop.
3. Export Snippets to an ini file
4. Import Snippets from the same file back to db
5. Both Snippets will now contain the second shop's value.

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

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

6. Checklist

• [x] I have written tests and verified that they fail without my change
• [x] I have squashed any insignificant commits
• [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?

When a plugin registers an event listener, it creates a database entry with a callback for that listener. If this callback will later be not callable anymore and the listened event is triggered, it will result in a fatal error. For some reason this only seems to affect the cli. A listener could become not callable if e.g. the plugin is removed from the system without using the plugin manager to uninstall it.

2. What does this change do, exactly?

Before the event listeners are registered, it will now be checked if they are callable. If they are not, they are not registered in the event manager. So now, the error will not be triggered anymore.

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

1. Install e.g. SwagImportExport and activate it.
2. Go to the plugin directory and remove SwagImportExport.
3. Try to execute a command in the cli, e.g. sw:cache:clear.

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

None.

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

None.

6. Checklist

• [x] I have written tests and verified that they fail without my change
• [x] I have squashed any insignificant commits
• [ ] 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.

PS: While working on this, I discovered, that there are several event listeners in the default Shopware database, that are not callable. But since the listened events seem to not exist anymore, they do not actually matter.

1. Why is this change necessary?

This is a follow up to https://github.com/shopware/shopware/pull/1779. Please read the previous PR to be sure to get the main problem and followed discussion.

When using the ConfigReader there is an inheritance used that the shop structure has impact on the chosen value as they override each other. The ConfigWriter skips the inheritance that is used on reading.

I separated the squashed commits to check the major steps for their differences and use the new tests to verify the wrong behaviour.

2. What does this change do, exactly?

The configuration inheritance is now solved via php code and not via sql code. This adds more complexity by having new classes but also add more power to change the behaviour.

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

• Have a nullable boolean (default null) plugin configuration
• Use sw:plugin:config:set and set value for the default shop to true
• Use sw:plugin:config:set and set value for a sub shop to false
• Use sw:plugin:config:get and read value for the sub shop which is true

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

https://github.com/shopware/shopware/pull/1779

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

Some classes are now obsolete as they wrap other classes to maintain a similar interface structure while having backwards compatibility.

6. Checklist

• [x] I have written tests and verified that they fail without my change
• [x] I have squashed any insignificant commits
• [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?

I'm always looking for the numbers. Nobody would expect them in /themes/Frontend/Bare/frontend/checkout/cart_item.tpl. I think the right place is the model.

2. What does this change do, exactly?

Reducing developer pain.

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

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

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

6. Checklist

• [ ] I have written tests and verified that they fail without my change
• [x] I have squashed any insignificant commits
• [ ] 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?

Imagine a shop with a lot of customergroups and a big menu (that is always the same). Every time a user logs in, a new menu will be generated and this will take a long time if you have +150 categories. There should be a way to exclude customergroups to be in the cache key.

Espacially the checkout (login/register) is critical, because users will more likely dicard their shopping cart if the login takes longer then a few seconds.

2. What does this change do, exactly?

This change adds a new form field excludeCustomergroup which will decide if the customergroup will be used in the cache key or not.

The option (boolean) is set to 0 by default (same behavior as before) and even with the plugin not reinstalled it is not true and therefore the customergroups will be considered as usual. I also added the shop scope for caching, cachetime and hoverDelay.

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

Browse in a big shop (+150 categories) and login with customergroup which is not default.

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

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

6. Checklist

• [ ] I have written tests and verified that they fail without my change
• [x] I have squashed any insignificant commits
• [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?

Sometimes you want to add a attribute that should not be editable for your users but still visible in backend. This allows to make that attribute be readonly.

2. What does this change do, exactly?

Adding a new attribute configuration option that marks that attribute as readonly. This setting is then used to disable the input field in extjs. Therefore changes by code are of course still possible

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

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

PR https://github.com/shopware/shopware/pull/1645 https://issues.shopware.com/issues/SW-21676

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

New option "readonly" for attribute cru(d).

6. Checklist

• [ ] I have written tests and verified that they fail without my change
• [x] I have squashed any insignificant commits
• [ ] 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.

… attacks

1. Why is this change necessary?

By default openssl_public_encrypt does not use an algorithm with OAEP padding and so the generated strings are vulnerable to oracle padding and chosen ciphertext attacks.

2. What does this change do, exactly?

Set the padding parameter for openssl_public_encrypt to OPENSSL_PKCS1_OAEP_PADDING to improve the security.

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

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

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

6. Checklist

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

1. Why is this change necessary?

For easier usability of console commands.

Did you ever cloned a category tree and did not know what category ids you have? You wanted to configure a plugin via commandline and ~~rage~~ be upset when you had to copy/rewrite every single config key?

Here are some examples using improved commands:

Basic completion

Nice things

Plugin reinstall workflow

Still a downside. You have to register it in your .bashrc using source <(cd /home/vagrant/www/shopware && bin/console _completion --generate-hook). Maybe the big Shopware hosters will add this by default to make their customers happy.

2. What does this change do, exactly?

Implements for all core/shipped bundle commands the CompletionAwareInterface

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

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

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

Life with shopware 💙

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

You can add this feature to the documentation.

6. Checklist

• [ ] I have written tests and verified that they fail without my change
• [x] I have squashed any insignificant commits
• [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.

The given change will fetch the html content of a static page, processing it as a regular smarty template instead of directly assigning the html content to the view. Therefore, any smarty function (e.g., {url}) can be used in a static content site. For example, this enables a power user to easily create links between static pages.

1. Why is this change necessary?

Imagine a boolean config element which defaults to falsey and is changable for every sub-/language shop. The loading hierarchy of the config reader is requested shop, parent shop (if given), shop with id = 1, element default.

This change allows to set the config value for the requested shop to the default value without always falling back to shop with id 1 setted value.

2. What does this change do, exactly?

Always write a given value except it is null to match the coalasce in the reader.

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

Have the following shop tree.

|--* 1 Pan cake mixes
|--+ 2 Flux compensators
   |--* 3 Flux compensatoren (NL)

Have plugin (maybe for Regulation (EU) 1169/2011 better known as LMIV in :de:). This plugin has configuration element which allows being changed for every sub-/language shop (scope = 1) and a default value of null. For example the setting for being enabled. One sets the enabled configuration value to true for the pancake shop (id: 1). Therefore it is enabled everywhere. Afterwards you disable it for the flux compensators shop (id: 2). This is denied by the config writer as the false value is loosely equals to the null default value. Therefore it skips the writing of the value. The reader now falls back to shop with id 1 and reads the value true.

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

Maybe some comments in the documentation about the config reader/writer have to be changed.

5. Checklist

• [ ] I have written tests and verified that they fail without my change
• [x] I have squashed any insignificant commits
• [ ] 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.

This PR makes the fields s_order.partnerID and s_order_basket.partnerID nullable and sets their default values to NULL. Previuosly the partnerID was set to an empty string by default, which makes not much sense, since it mapps a foreign key relation to s_emarketing_partner. Besides making the field nullabel, I also changed the code to not cast partnerIDs to strings, but pass the value as it is, when creating an order, which preserves NULL values upon INSERTing.

This PR does not introduce any breaking changes.

Note: This change was first proposed in PR #196, but never merged.

improve php8.1 support

1. Why is this change necessary?

If you are running shopware 5 with php8.1 and run the command ./bin/console sw:es:index:populate you will get very much of this messages:

PHP Deprecated: explode(): Passing null to parameter #2 ($string) of type string is deprecated in /var/www/tiefenbach-it.com/vendor/shopware/shopware/engine/Shopware/Bundle/StoreFrontBundle/Gateway/DBAL/Hydrator/ProductHydrator.php on line 199

2. What does this change do, exactly?

fix the deprecated usage

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

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

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

6. Checklist

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