Common issues when you migrate plugins from Shopware 6.4 to 6.5

Migrating plugins from one version to another can be a challenging process, and this is no different when it comes to migrating plugins from Shopware 6.4 to 6.5. With every new release, there are bound to be changes and improvements made to the platform, and it is essential to keep up with these changes to ensure that your plugins continue to function as expected.

In this blog post, we will discuss some of the common issues that developers may encounter when migrating plugins from Shopware 6.4 to 6.5. These issues can range from minor compatibility issues to more significant changes in functionality, and it is crucial to be aware of them before starting the migration process.

When migrating plugins from Shopware 6.4 to 6.5, there are several common issues that may arise:

• jQuery is removed

Recently, there has been an update in Shopware 6.5 which has resulted in the removal of jQuery usage in storefront scripts. As a result, it is necessary to make changes to any plugins that rely on jQuery and replace the jQuery scripts with JavaScript. This change is important in order to ensure compatibility with the updated version of Shopware and to maintain the functionality of your plugins.

• RouteScope is deprecated

If you’re encountering the error message “The annotation ‘@Shopware\Core\Framework\Routing\Annotation\RouteScope’ in class […] was never imported”, it means that the annotation is deprecated and you need to use the updated annotation ‘@Symfony\Component\Routing\Annotation\Route’ instead. To fix this issue, you can make the following changes to your code:

Instead of using:

/**
* @RouteScope(scopes={"storefront"})
*/

Use:

#[Route(defaults: ['_routeScope' => ['storefront']])]here

This will properly set the route scope for your controller action using the updated annotation. By making this change, you should be able to resolve the deprecation error and ensure that your code is using the latest annotations for Symfony routing.

• Parameter In query builder

If you’re encountering the error “Named parameter ‘productId’ does not have a bound value” in query builder, it means that the parameter ‘productId’ is not being properly bound to a value in your code. To fix this error, you can try making the following change in your query builder code.

Instead of using: 

->setParameter(':productId', Uuid::fromHexToBytes($params['productId']))your code here

Use:

->setParameter('productId', Uuid::fromHexToBytes($params['productId']))our code here

This will properly bind the value of `$params[‘productId’]` to the ‘productId’ parameter in the query builder. The colon is not necessary for named parameters in Doctrine Query Builder. By making this change, you should be able to resolve the error and properly execute your query.

• Render Twig in storefront controller

If you encounter an error in your storefront controller indicating that Twig has not been properly injected, you can fix it by adding a method call to setTwig with the Twig instance in your services.xml file.

To do this, you can update your services.xml file to include the following configuration for your controller:

<service id="Hatslogic\Sw\SocialProof\Storefront\Controller\ProductViewsController" public="true">
   ……
   <call method="setTwig">
       <argument type="service" id="twig"/>
   </call>
</service>

This will properly inject the Twig instance into your storefront controller and allow you to render Twig templates within your controller actions. By making this change, you should be able to resolve the error and ensure that your storefront controller is able to access and use the Twig instance.

• EntityRepositoryInterface is deprecated

If you’re encountering the error “EntityRepositoryInterface is deprecated”, it means that the EntityRepositoryInterface interface has been deprecated and you need to use the EntityRepository class instead. To fix this issue, you can make the following changes to your code:

Instead of using:

use Shopware\Core\Framework\DataAbstractionLayer\EntityRepositoryInterface;

Use:

use Shopware\Core\Framework\DataAbstractionLayer\EntityRepository;

This will import the updated EntityRepository class, which should be used in place of the deprecated EntityRepositoryInterface. By making this change, you should be able to resolve the deprecation error and ensure that your code is using the latest version of the Shopware Core framework.

• getMasterRequest method is undefined 

If you’re encountering the error message “Attempted to call an undefined method named ‘getMasterRequest’ of class ‘Symfony\Component\HttpFoundation\RequestStack'”, it means that the getMasterRequest() method has been deprecated and replaced with getMainRequest() in Symfony.

To fix this issue, you can make the following change to your code:

Instead of using:

$this->requestStack->getMasterRequest();

Use:

$this->requestStack->getMainRequest();

This will properly access the main request in the request stack and allow you to retrieve the necessary data. By making this change, you should be able to resolve the deprecation error and ensure that your code is using the latest version of the Symfony framework.

• Usage of session

If you’re working with Shopware 6.5 and you’re encountering issues with injecting the session in your services.xml file, it’s because this functionality is no longer supported. Instead, you should use the request object to get access to the session.

To retrieve the session object, you can use the following code:

$event->getRequest()->getSession();

This will retrieve the session object from the request and allow you to use it as needed in your code. By making this change, you should be able to resolve any issues related to injecting the session in Shopware 6.5 and ensure that your code is using the latest best practices for working with sessions.

• CSRF protection is removed

If you are encountering the error “Unknown ‘sw_csrf’ function” in your Shopware project, it is likely because CSRF protection has been removed by Shopware. In this case, you can remove the CSRF field from your form to resolve the issue.

You can remove the CSRF field from your form by simply deleting the following line of code from your form template:

{{ sw_csrf() }}

Once you have removed this line, the CSRF field will no longer be included in your form and the error message should no longer be displayed.

Note that while removing the CSRF field may resolve the error message, it is important to ensure that your Shopware project is still adequately protected against CSRF attacks. If you are unsure about how to do this, you may want to consult with a developer or security expert to ensure that your project is properly secured.

Referal link

• Usage of Filesystem

In Shopware 6.5, the usage of `League\Flysystem\Filesystem` and `League\Flysystem\Adapter\Local` is no longer available. Instead, you can use `Symfony\Component\Filesystem\Filesystem` to handle file system operations in your project.

To use `Symfony\Component\Filesystem\Filesystem`, you need to first import the class at the top of your file:

use Symfony\Component\Filesystem\Filesystem;

Once you have imported the class, you can create a new instance of the `Filesystem` object and use its methods to perform file system operations. For example, to create a new directory, you can use the `mkdir()` method like this:

$filesystem = new Filesystem();
$filesystem->mkdir('/path/to/directory');

This will create a new directory at the specified path.

By using `Symfony\Component\Filesystem\Filesystem` instead of `League\Flysystem\Filesystem`, you can ensure that your Shopware project is using the latest best practices for handling file system operations and can avoid any issues related to outdated dependencies.

• Issue with bootstrap modal.

There seems to be an issue with the bootstrap modal where it is not showing up and the close button is not working. To fix this issue, you can make the following changes:

1. For the modal toggle button, change the data-toggle attribute to data-bs-toggle and data-target attribute to data-bs-target:

Old code: 

<span data-toggle="modal" data-delete-image-id="sabcd11" data-target="#deleteReviewModal" class="delete_product_review_image" />

New code:

<span data-bs-toggle="modal" data-delete-image-id="sabcd11" data-bs-target="#deleteReviewModal" class="delete_product_review_image" />

2. For the close button, change the data-dismiss attribute to data-bs-dismiss:

Old code:

<button type="button" class="btn btn-secondary" data-dismiss="modal" />

New code:

<button type="button" class="btn btn-secondary" data-bs-dismiss="modal" />

These changes should fix the issue with the bootstrap modal not showing and the close button not working.

• Bootstrap modal show & hide using script

To show and hide a Bootstrap modal using JavaScript, you can use the following code:

// Show the modal

let myModal = new bootstrap.Modal(document.getElementById("myModal"), {backdrop: false});

myModal.show();

// Hide the modal

myModal.hide();

Note that you need to replace “myModal” with the actual ID of your modal element. Also, the `{backdrop: false}` option is used to disable the backdrop (i.e., the semi-transparent overlay behind the modal) when showing the modal. If you want to keep the backdrop, you can omit this option or set it to `{}`.

• Non-existent service ContainerInterface

When encountering the error “Non-existent service ContainerInterface”, we need to update the `services.xml` file to use the correct service ID for the ContainerInterface. Instead of using `<argument type=”service” id=”Symfony\Component\DependencyInjection\ContainerInterface”/>`, we should use `<argument type=”service” id=”service_container” />`. This will correctly inject the ContainerInterface into the service.

• SalesChannelRepositoryInterface is deprecated

The interface “SalesChannelRepositoryInterface” has been deprecated in Shopware 6.5, and replaced with “SalesChannelRepository”. Make sure to update your code accordingly to avoid any issues.

• sw-order-detail-base not found

In Shopware 6.5, the template `sw-order-detail-base` has been renamed to `sw-order-detail-details`. If you want to display custom fields in the order detail page, you should use the new template `sw-order-detail-details` instead of the old one.

• Usage of LoginRequired in controller

In Shopware 6.5, the usage of @LoginRequired in controller is changed to [‘_loginRequired’ => true] in the route definition.

Replace the following code:

/**

* @LoginRequired()

* @Route("/abandonedCartNotification/saveConfirmation", name="frontend.account.saveAbandonedCartNotificationConfirmation", methods={"POST"}, defaults={"XmlHttpRequest"=true})

*/

with defaults: [‘_loginRequired’ => true]

#[Route(path: '/abandonedCart/saveConfirmation', name: 'frontend.account.saveAbandonedCartNotificationConfirmation', defaults: ['XmlHttpRequest' => true,'_loginRequired' => true], methods: ['POST'])]

Resolve the Issues now

• SnippetFileInterface is deprecated

In Shopware 6.5, the SnippetFileInterface is deprecated, and you should create a storefront.de-DE.json file in your plugin’s Resources Snippet folder and add your snippet there. This file should contain a JSON object with all of your snippets.

By keeping these common issues in mind and making necessary changes, migrating plugins from Shopware 6.4 to 6.5 can be done without any major issues.

Conclusion

In conclusion, migrating plugins from Shopware 6.4 to 6.5 presents a series of common challenges, from adapting to removed features like jQuery to addressing deprecated interfaces and adjusting routing annotations. By addressing these issues methodically, developers can ensure seamless compatibility with the updated platform. Adhering to best practices, such as utilizing Symfony’s latest features and handling file operations, ensures smoother transitions and future-proofed plugins. With proper attention to detail and adherence to recommended changes, the migration process can be successfully navigated, preserving plugin functionality and compatibility with Shopware 6.5.