Shopware 6.5.4.0

[shyim]

Hey 👋 ,

We released Shopware 6.5.4.0 today. Here are some developer highlights:

Added generics to EntityRepository and EntitySearchResult

We added generics to EntityRepository and EntitySearchResult. With this feature, it is more comfortable to work with your IDE (better auto-completion), but you also achieve better type safety when working with tools like PHPStan or Psalm.

Example:

    /**
     * @param EntityRepository<CustomerAddressCollection> $addressRepository
     */
    public function __construct(
        private readonly EntityRepository $addressRepository,
        private readonly EventDispatcherInterface $eventDispatcher
    ) {
    }

any further call to search and getEntities will return a CustomerAddressCollection.

Fixed extending document templates with sw_extends

Finally, it's possible to extend the document partial templates like the header on any document type instead of overriding every document type once. NEXT-26513

Added configuration to disable fine-grained caches

A configuration to disable Shopware fine-grained caches was added. With this, the whole cache instead of just config changes can be cleared and hence, may increase the performance massively. Please also see the documentation about disabling fine-grained caching to learn how to use this feature.

Trusted proxies now configurable with normal Symfony settings

How to configure Shopware to work behind a load balancer or a reverse proxy? Trusted Proxies can now be configured utilizing the regular Symfony configuration. This feature now works out of the box in Shopware, as it was not easy before to configure. 😉

Loosen composer constraints

We loosened constraints in the composer to allow the installation of minor updates of some composer packages. This makes it easier to install, for example, specific versions of security updates or 3rd party packages. See this commit for more information.

Logging of extensions

Monolog instances of extensions consider now the project-wide configured Monolog handler.

And many more things

• Monolog instances of extensions consider now the project-wide configured Monolog handler.
• public/asset-manifest.json is now stored outside of public directory
• Doctrine profiler bridge is now only active in dev mode
• Multilingual Elasticsearch indices, create one Elasticsearch per entity. Improves indexing performance. Behind Feature flag until 6.6 ES_MULTILINGUAL_INDEX
• Salutation is now optional
• Apps installed with composer can be now installed with app:install
• Admin Worker now respects the poll interval
• Recurring Payment Handler
• CacheInvalidationSubscriber can be now manipulated
• Adjusted various log levels to be more consistent

Check out our blog post: https://www.shopware.com/en/news/shopware-6-release-news-august-2023/
Compare: v6.5.3.3...v6.5.4.0

[ioanok]

The changelog says that NEXT-25804 is fixed, but this is not true. The issue is generated by theme:refresh or system:update:finish commands.

[ssltg]

Hi @ioanok ,
checked it:
the issue is fixed for new setups. If your media database is once corrupt with generated duplicates like Logo(1), it cannot be fixed automatically. You have to go directly to the database and delete all the duplicates (as they may be still connected with the theme in the theme_media table, they cannot be deleted in the admin).

And ensure the id in the theme table is the one of the initial image (without (x) suffix )

If this not fixes your setup, please provide a detailed reproducing setup.

greets 👍

[ioanok]

Thank you for clarifications, the issue is solved now.

[7underlines]

We need to migrate a shop where the default images defaultThemePreview and favicon have been deleted, leaving only favicon_(1) and defaultThemePreview(1) in existence. I've cleaned the theme_media table and removed all duplicates. However, during the upgrade process, I still encounter the following error:
[Shopware\Core\Content\Media\Exception\DuplicatedMediaFileNameException] A file with the name "defaultThemePreview_(1).jpg" already exists.

[ssltg]

You can try to rename the file itself in the directory and in the database by removing the suffix and then try again.

[wannevancamp]

Since 6.5.4.0 our custom src/Resources/app/storefront/webpack.config.js breaks. After building the frontend with bin/build-storefront.sh the following error is shown: Module not found: Error: Can't resolve 'xyz.js' in ...

The bug is introduced in: 45054ab6

[shyim]

Is it possible that you provide us the extension where the error occurs?

[wannevancamp]

I've sent you the zip via PM

[tobiasberge]

Hi @wannevancamp, thank you for providing your plugin. I tested to revert the change you mentioned but I still got the "Module not found" error. I think it is related to this change here: aed3073.

The error only happens for the packages which have a .js suffix. For example the alias instantsearch.js. All other package aliases seem to work just fine. We have introduced a new extensionAlias which now conflicts with a regular alias if it also has a .js suffix.

The extensionAlias was added for migrating JS files to TypeScript gradually while preventing breaking changes (ironically) in case somebody imports a file with explicit .js suffix and the file is changed to .ts suffix.

extensionAlias: {
    '.js': ['.ts', '.js'],
},

I'm afraid we'll have to revert this and find another solution for it because it can break existing plugins which use an alias for package names with .js stuffix.

In the meantime you can fix by resolving all node_modules instead of explicit aliases for each package. Imo this is a better solution in general because it is much less maintenance when having multiple packages. In the docs we currently propose to use an alias, I made a PR to change this in the future: shopware/docs#1077

module.exports = (params) => {
    return {
        resolve: {
+            modules: [
+                `${params.basePath}/Resources/app/storefront/node_modules`,
+            ],
-            alias: {
-                'algoliasearch/lite': resolve(
-                    join(__dirname, '..', 'node_modules', 'algoliasearch/lite')
-                ),
-                'instantsearch.js': resolve(
-                    join(__dirname, '..', 'node_modules', 'instantsearch.js')
-                ),
-                'algoliasearch-helper': resolve(
-                    join(__dirname, '..', 'node_modules', 'algoliasearch-helper')
-                ),
-                'hogan.js': resolve(
-                    join(__dirname, '..', 'node_modules', 'hogan.js')
-                ),
-                '@algolia/autocomplete-core': resolve(
-                    join(__dirname, '..', 'node_modules', '@algolia/autocomplete-core')
-                ),
-                // etc...
-            }
        }
    };
}

[wannevancamp]

@tobiasberge , thanks for looking into this issue. I can confirm that this solution works.

[JoshuaBehrens]

I could not find anything about HTTP status codes in the BC promise. The exception to CONTENT__MEDIA_DUPLICATED_FILE_NAME has been changed from 500 to 409 with NEXT-26928. It was sort-of breaking for a piece of code for me. Are there plans to integrate the HTTP status code to the BC promise?