Häufige Probleme bei der Migration von Plugins von Shopware 6.4 auf 6.5

Häufige Probleme bei der Migration von Plugins von Shopware 6.4 auf 6.5

Die Migration von Plugins von einer Version auf eine andere kann ein herausfordernder Prozess sein, und das ist bei der Migration von Plugins von Shopware 6.4 auf 6.5 nicht anders. Mit jeder neuen Version werden zwangsläufig Änderungen und Verbesserungen an der Plattform vorgenommen. Es ist wichtig, mit diesen Änderungen Schritt zu halten, um sicherzustellen, dass Ihre Plugins weiterhin wie erwartet funktionieren.

In diesem Blogbeitrag besprechen wir einige der häufigsten Probleme, auf die Entwickler bei der Migration von Plugins von Shopware 6.4 auf 6.5 stoßen können. Diese Probleme können von geringfügigen Kompatibilitätsproblemen bis hin zu größeren Funktionsänderungen reichen und es ist wichtig, sich ihrer bewusst zu sein, bevor man mit dem Migrationsprozess beginnt.

 

Bei der Migration von Plugins von Shopware 6.4 auf 6.5 können mehrere häufige Probleme auftreten:

jQuery wurde entfernt

Kürzlich gab es in Shopware 6.5 ein Update, das dazu führte, dass die jQuery-Nutzung in Storefront-Skripten entfernt wurde. Daher ist es notwendig, Änderungen an allen Plugins vorzunehmen, die auf jQuery basieren, und die jQuery-Skripte durch JavaScript zu ersetzen. Diese Änderung ist wichtig, um die Kompatibilität mit der aktualisierten Version von Shopware sicherzustellen und die Funktionalität Ihrer Plugins aufrechtzuerhalten.

 

RouteScope ist veraltet

Wenn die Fehlermeldung „Die Annotation ‚@Shopware\Core\Framework\Routing\Annotation\RouteScope‘ in Klasse […] wurde nie importiert“ angezeigt wird, bedeutet dies, dass die Annotation veraltet ist und Sie die aktualisierte Annotation verwenden müssen Stattdessen „@Symfony\Component\Routing\Annotation\Route“. Um dieses Problem zu beheben, können Sie die folgenden Änderungen an Ihrem Code vornehmen:

Anstatt zu verwenden:

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

Verwenden:

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

Dadurch wird der Routenbereich für Ihre Controller-Aktion mithilfe der aktualisierten Anmerkung ordnungsgemäß festgelegt. Durch diese Änderung sollten Sie in der Lage sein, den veralteten Fehler zu beheben und sicherzustellen, dass Ihr Code die neuesten Anmerkungen für das Symfony-Routing verwendet.

 

Parameter im Abfrage-Generator

Wenn im Abfrage-Builder die Fehlermeldung „Der benannte Parameter „productId“ hat keinen gebundenen Wert“ auftritt, bedeutet dies, dass der Parameter „productId“ nicht ordnungsgemäß an einen Wert in Ihrem Code gebunden ist. Um diesen Fehler zu beheben, können Sie versuchen, die folgende Änderung in Ihrem Abfrage-Builder-Code vorzunehmen.

Anstatt zu verwenden: 

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

Verwenden:

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

Dadurch wird der Wert von „$params[‘productId’]“ ordnungsgemäß an den Parameter „productId“ im Abfrage-Builder gebunden. Der Doppelpunkt ist für benannte Parameter im Doctrine Query Builder nicht erforderlich. Durch diese Änderung sollten Sie in der Lage sein, den Fehler zu beheben und Ihre Abfrage ordnungsgemäß auszuführen.

 

Rendern Sie Twig im Storefront-Controller

Wenn in Ihrem Storefront-Controller ein Fehler auftritt, der darauf hinweist, dass Twig nicht ordnungsgemäß injiziert wurde, können Sie ihn beheben, indem Sie einen Methodenaufruf zu setTwig mit der Twig-Instanz in Ihrer Datei „services.xml“ hinzufügen.

Dazu können Sie Ihre Datei „services.xml“ so aktualisieren, dass sie die folgende Konfiguration für Ihren Controller enthält:

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

Dadurch wird die Twig-Instanz ordnungsgemäß in Ihren Storefront-Controller eingefügt und Sie können Twig-Vorlagen innerhalb Ihrer Controller-Aktionen rendern. Durch diese Änderung sollten Sie in der Lage sein, den Fehler zu beheben und sicherzustellen, dass Ihr Storefront-Controller auf die Twig-Instanz zugreifen und diese verwenden kann.

 

EntityRepositoryInterface ist veraltet

Wenn die Fehlermeldung „EntityRepositoryInterface ist veraltet“ auftritt, bedeutet dies, dass die EntityRepositoryInterface-Schnittstelle veraltet ist und Sie stattdessen die EntityRepository-Klasse verwenden müssen. Um dieses Problem zu beheben, können Sie die folgenden Änderungen an Ihrem Code vornehmen:

Anstatt zu verwenden:

use Shopware\Core\Framework\DataAbstractionLayer\EntityRepositoryInterface;

Verwenden:

use Shopware\Core\Framework\DataAbstractionLayer\EntityRepository;<span>Dadurch wird die aktualisierte EntityRepository-Klasse importiert, die anstelle der veralteten EntityRepositoryInterface verwendet werden sollte. </span><span>Durch diese Änderung sollten Sie in der Lage sein, den Deprecation-Fehler zu beheben und sicherzustellen, dass Ihr Code die neueste Version des Shopware Core-Frameworks verwendet.</span>

 

Die getMa sterRequest-Methode ist undefiniert 

Wenn die Fehlermeldung „Es wurde versucht, eine undefinierte Methode mit dem Namen ‚getMasterRequest‘ der Klasse ‚Symfony\Component\HttpFoundation\RequestStack‘ aufzurufen“ angezeigt wird, bedeutet dies, dass die Methode „getMasterRequest()“ veraltet ist und in durch „getMainRequest()“ ersetzt wurde Symfony.

Um dieses Problem zu beheben, können Sie die folgende Änderung an Ihrem Code vornehmen:

Anstatt zu verwenden:

$this->requestStack->getMasterRequest();

Use:

$this->requestStack->getMainRequest();

Dadurch wird ordnungsgemäß auf die Hauptanforderung im Anforderungsstapel zugegriffen und Sie können die erforderlichen Daten abrufen. Durch diese Änderung sollten Sie in der Lage sein, den veralteten Fehler zu beheben und sicherzustellen, dass Ihr Code die neueste Version des Symfony-Frameworks verwendet.

 

Nutzung der Sitzung

Wenn Sie mit Shopware 6.5 arbeiten und beim Einfügen der Sitzung in Ihre Datei „services.xml“ Probleme auftreten, liegt das daran, dass diese Funktionalität nicht mehr unterstützt wird. Stattdessen sollten Sie das Anforderungsobjekt verwenden, um Zugriff auf die Sitzung zu erhalten.

Um das Sitzungsobjekt abzurufen, können Sie den folgenden Code verwenden:

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

Dadurch wird das Sitzungsobjekt aus der Anfrage abgerufen und Sie können es nach Bedarf in Ihrem Code verwenden. Durch diese Änderung sollten Sie in der Lage sein, alle Probleme im Zusammenhang mit der Einbindung der Sitzung in Shopware 6.5 zu lösen und sicherzustellen, dass Ihr Code die neuesten Best Practices für die Arbeit mit Sitzungen verwendet.

 

Der CSRF-Schutz wurde entfernt

Wenn in Ihrem Shopware-Projekt der Fehler „Unbekannte ‚sw_csrf‘-Funktion“ auftritt, liegt das wahrscheinlich daran, dass der CSRF-Schutz von Shopware entfernt wurde. In diesem Fall können Sie das CSRF-Feld aus Ihrem Formular entfernen, um das Problem zu beheben.

Sie können das CSRF-Feld aus Ihrem Formular entfernen, indem Sie einfach die folgende Codezeile aus Ihrer Formularvorlage löschen:

{{ sw_csrf() }}

Sobald Sie diese Zeile entfernt haben, ist das CSRF-Feld nicht mehr in Ihrem Formular enthalten und die Fehlermeldung sollte nicht mehr angezeigt werden.

Beachten Sie, dass das Entfernen des CSRF-Felds zwar die Fehlermeldung beheben kann, es jedoch wichtig ist, sicherzustellen, dass Ihr Shopware-Projekt weiterhin ausreichend vor CSRF-Angriffen geschützt ist. Wenn Sie sich nicht sicher sind, wie das geht, sollten Sie sich an einen Entwickler oder Sicherheitsexperten wenden, um sicherzustellen, dass Ihr Projekt ordnungsgemäß gesichert ist.

Empfehlungslink link

 

Nutzung des Dateisystems

In Shopware 6.5 ist die Verwendung von „League\Flysystem\Filesystem“ und „League\Flysystem\Adapter\Local“ nicht mehr verfügbar. Stattdessen können Sie „Symfony\Component\Filesystem\Filesystem“ verwenden, um Dateisystemvorgänge in Ihrem Projekt abzuwickeln.

Um „Symfony\Component\Filesystem\Filesystem“ zu verwenden, müssen Sie zuerst die Klasse oben in Ihrer Datei importieren:

use Symfony\Component\Filesystem\Filesystem;

Sobald Sie die Klasse importiert haben, können Sie eine neue Instanz des „Filesystem“-Objekts erstellen und seine Methoden verwenden, um Dateisystemoperationen auszuführen. Um beispielsweise ein neues Verzeichnis zu erstellen, können Sie die Methode „mkdir()“ wie folgt verwenden:

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

Dadurch wird ein neues Verzeichnis im angegebenen Pfad erstellt.

Durch die Verwendung von „Symfony\Component\Filesystem\Filesystem“ anstelle von „League\Flysystem\Filesystem“ können Sie sicherstellen, dass Ihr Shopware-Projekt die neuesten Best Practices für die Handhabung von Dateisystemvorgängen verwendet und Probleme im Zusammenhang mit veralteten Abhängigkeiten vermeiden können.

 

Problem mit Bootstrap-Modal.

Es scheint ein Problem mit dem Bootstrap-Modal zu geben, bei dem es nicht angezeigt wird und die Schaltfläche „Schließen“ nicht funktioniert. Um dieses Problem zu beheben, können Sie die folgenden Änderungen vornehmen:

 

  1. Ändern Sie für die modale Umschalttaste das Attribut „data-toggle“ in „data-bs-toggle“ und das Attribut „data-target“ in „data-bs-target“:

 

Alter Code: 

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

 

Neuer Code:

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

 

  1. Ändern Sie für die Schaltfläche „Schließen“ das Attribut „data-dismiss“ in „data-bs-dismiss“:

 

Alter Code: 

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

 

Neuer Code:

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

Diese Änderungen sollten das Problem beheben, dass das Bootstrap-Modal nicht angezeigt wird und die Schaltfläche „Schließen“ nicht funktioniert.

 

Bootstrap-modales Ein- und Ausblenden mithilfe eines Skripts

Um ein Bootstrap-Modal mithilfe von JavaScript anzuzeigen und auszublenden, können Sie den folgenden Code verwenden:

// Show the modal

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

myModal.show();

// Hide the modal

myModal.hide();

Beachten Sie, dass Sie „myModal“ durch die tatsächliche ID Ihres Modalelements ersetzen müssen. Außerdem wird die Option „{backdrop: false}“ verwendet, um den Hintergrund (dh die halbtransparente Überlagerung hinter dem Modal) zu deaktivieren, wenn das Modal angezeigt wird. Wenn Sie den Hintergrund beibehalten möchten, können Sie diese Option weglassen oder auf „{}“ setzen.

 

Nicht vorhandener Dienst ContainerInterface

Wenn der Fehler „Nicht vorhandener Service ContainerInterface“ auftritt, müssen wir die Datei „services.xml“ aktualisieren, um die richtige Service-ID für das ContainerInterface zu verwenden. Anstatt „<argument type=“service“ id=“Symfony\Component\DependencyInjection\ContainerInterface“/>` zu verwenden, sollten wir „<argument type=“service“ id=“service_container“ />` verwenden. Dadurch wird das ContainerInterface korrekt in den Dienst eingefügt.

 

SalesChannelRepositoryInterface ist veraltet

Die Schnittstelle „SalesChannelRepositoryInterface“ wurde in Shopware 6.5 veraltet und durch „SalesChannelRepository“ ersetzt. Stellen Sie sicher, dass Sie Ihren Code entsprechend aktualisieren, um Probleme zu vermeiden.

 

sw-order-detail-base nicht gefunden

In Shopware 6.5 wurde die Vorlage „sw-order-detail-base“ in „sw-order-detail-details“ umbenannt. Wenn Sie benutzerdefinierte Felder auf der Bestelldetailseite anzeigen möchten, sollten Sie anstelle der alten die neue Vorlage „sw-order-detail-details“ verwenden.

 

Verwendung von LoginRequired im Controller

In Shopware 6.5 wird die Verwendung von @LoginRequired im Controller in der Routendefinition auf [‘_loginRequired’ => true] geändert.

Ersetzen Sie den folgenden Code:

/**

* @LoginRequired()

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

*/

mit Standardwerten: [‘_loginRequired’ => true]

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

 

SnippetFileInterface ist veraltet

In Shopware 6.5 ist das SnippetFileInterface veraltet und Sie sollten eine Datei „storefront.de-DE.json“ im Ordner „Resources Snippet“ Ihres Plugins erstellen und Ihr Snippet dort hinzufügen. Diese Datei sollte ein JSON-Objekt mit allen Ihren Snippets enthalten.

Wenn Sie diese häufigen Probleme berücksichtigen und die erforderlichen Änderungen vornehmen, kann die Migration von Plugins von Shopware 6.4 auf 6.5 ohne größere Probleme durchgeführt werden.

Leave a Reply

Your email address will not be published. Required fields are marked *