Hi,
ist das nur bei mir so oder mag Shopware/QA Prüfung aktuell keiner mehr machen ? Seit glaube 10-14 Tagen hat sich zumindest bei mir in der Wartschlange nichts mehr verändert.
Ging zuletzt immer schleppender voran und jetzt ist völliger Stillstand…
Habt ihr aktuell ähnliche Probleme ?!
Hi @b.david 
Das war beim letzten Q&A mit erwaehnt - die Kollegen sind ordentlich ausgelastet, Besserung ist in Sicht, dauert aber noch eine kleine Weile. Das Problem ist bekannt und es soll natuerlich nicht so bleiben.
In dem Fall hilft also nur ein wenig Geduld.
Viele Gruesse
Marcus
Danke für die Rückmeldung, dass diese ausgelastet sind ist ja alles fein- aber wenn sich die Warteschlange um 0 Positionen verändert ist das keine „sind ausgelastet“ sondern „kein vorwärts“ gehen.
Aber am Ende bleibt ja auch wieder nichts als abzuwarten leider.
Etwa seit Herbst 2025 sind nach meiner Einschätzung die Prozesse mehr oder weniger ausgesetzt. Previews werden ohne Hinweis auf Cluster oder ohne klare Begründung abgelehnt, Testphasen fertiger Plugins sind zeitlich nicht mehr einschätzbar. Ich würde vom ersten Kickoff bis zum Go-Live aktuell 6 Monate kalkulieren.
Ferner war bis Herbst 2025 ein kleines Team von Experten am Werk, die unmissverständlich Ihre guidelines transparent gemacht haben, an denen man sich orientieren konnte, nun gibt es offenbar keine festen Personen im Team und entsprechend individuell sind die Einschätzungen.
Die Flows und Standards der Prüfung sind grundsätzlich gut und sinnvoll implementiert, es wäre schade, wenn diese nicht mehr greifen würden.
Also die letzten 14 Tagen muss ich sagen kam hier nun zumindest bei mir, Bewegung ins Spiel. Wie es bei anderen ist kann ich nicht sagen.
Vor diesen 14 Tagen hat sich knapp 3 Wochen gar nichts mehr getan.
Aktuell bin ich „zufrieden“.
Diese Woche ist übrigens noch der Shopware Community Day. Daher werden sicherlich ALLE Shopware Mitarbeiter aktuell alleine mit diesem Thema schwer beschäftigt sein.
Viele Grüße
Ich habe nur erwähnt, dass „übrigens“ noch der SCD statt findet - und sich daher die Bearbeitung (unter anderem) sicherlich noch etwas verzögern kann.
Viele Grüße
Erneut: ich habe den SCD als möglichen zusätzlichen Faktor erwähnt - und nicht als Erklärung für den gesamten Rückstau seit April. Bitte mehr lesen und weniger hineininterpretieren.
Viele Grüße
Klar ist der SCD bei Shopware intern sicherlich ein Thema. Was ich mir aber ziemlich sicher bin dass eben nicht die Entwickler hier stark involviert sind- außer eventuell welche die Vorträge vorbereiten oder ähnliches.
Ansonsten @bogx was vielleicht bei mir geholfen hatte war dass ich Shopware auch direkt mal per Mail einfach auch angeschrieben hatte. Es hat zwar ein paar Tage gedauert bis eine Antwort kam - wo ich auch mitteilte dass viele der Plugins sogar einfach nur auf die „Shopware Prüfung“ warteten nicht einmal den manuellen Codereview usw. und sich nichts tut kam die erwartete Antwort mit ja ist aktuell viel zu tun etc. und jetzt das große ABER - seit dieser Rückmeldung ging es wieder vorwärts. Egal ob es die „automatischen“ Prüfungen waren oder die Codereviews. Vielleicht hängt da einfach allgemein etwas ( einfach nur eine Vermutung )
Schreib doch einfach auch mal mit deiner Kundennummer an Shopware direkt - vielleicht hilft es dir auch.
Sonst, finde ich ja deinen Unmut kann ich mehr als verstehen - ging mir nicht anders. Aber es führt nicht weiter wütend um sich zu schlagen. 
Und Shopware betont bei jedem SCD wie wichtig die Community ist. Auch bei dem SCD26 (Keynote heute angeschaut). Bei der Verifizierung der Plugins scheint das nicht ganz aufzugehen.
Und ja der SCD kann das sicherlich etwas derzeit verzögern. Das Problem, wie man hier liest, besteht aber schon deutlich länger.
Bei aller Liebe zum SCD, aber Shopware sollte das Thema ernst nehmen und angehen. Mag sein das der SCD wichtig ist, sollte aber nicht als Grund davor geschoben werden um die Prüfung der Plugins zu vernachlässigen. Wenn die Leute dann nur noch gefrustet sind, kein Bock mehr auf Plugins haben, ist niemand damit geholfen und die sogenannte „Community“ leidet darunter. Am Ende leidet auch das Ansehen von Shopware. Nicht immer alles schön reden, sondern zeitnah das Problem lösen!
Viele Grüße
Hey,
ich kann eure Frustration verstehen und ich kann euch sagen, wir nehmen dieses Thema ernst. Wir bereiten gerade offizielle Kommunikation vor, aber schon mal vorab ein paar Infos:
Bei gleicher Teamstärke (ich bin z.B. einer, von denen, die den manuellen Code-Review machen) haben wir auf Grund der Cluster-Abschaffung und LLMs, die ganz großartig in viel Code-Produzieren sind, alleine im ersten Halbjahr dieses Jahr fast vier mal so viele Extensions zu checken released, als letztes Jahr im gleichen Zeitraum. Geprüft wurden dann noch mal mehr.
Was uns und euch hilft:
Haltet euch an unsere Qualitätsstandards und Anforderungen: Shopware Store review and quality | Shopware Documentation
Nutzt PHPStan: GitHub - shopware/phpstan-shopware: PhpStan Rules for Shopware · GitHub
Wenn die Extensions zumindest von vorneherein einen gewissen Mindest-Qualitätsstandard erfüllen, müssen am Ende weniger Extra-Runden gedreht werden.
Viele Grüße aus Schöppingen
Michael Telgmann
@Michael_Telgmann Danke für die gute Kommunikation. Das hier hatten wir schon befürchtet 
// " Bei gleicher Teamstärke (ich bin z.B. einer, von denen, die den manuellen Code-Review machen) haben wir auf Grund der Cluster-Abschaffung und LLMs, die ganz großartig in viel Code-Produzieren sind, alleine im ersten Halbjahr dieses Jahr fast vier mal so viele Extensions zu checken released, als letztes Jahr im gleichen Zeitraum. Geprüft wurden dann noch mal mehr."
Das ist ein guter Punkt. Das ist vielleicht auch das Problem, dass wir ein Plugin nutzen (demnächst 2) welches nicht im Pluginstore zu beziehen ist. Der erste Pluginanbieter hat uns das auf Nachfrage auch so bestätigt (diese waren mal im Store).
Das man sich die Plugin-ZIP Datei auf Seiten der Anbieter herunterladen muss, ist sicherlich nicht im Interesse von Shopware. Bei uns wie geschrieben nimmt das noch keine Überhand, aber ist sicherlich eine „interessante“ Entwicklung.
Ich bin ja selber öfters von diesen Problem und der teilweisen gefühlten Willkür einiger Entscheidungen betroffen - aber dein Beispiel spricht halt exakt davon, was Telgi eben geschrieben hat: „Haltet euch an unsere Qualitätsstandards und Anforderungen“
In Telgis verlinkten Quality Guidelines: Content and translations | Shopware Documentation
findest du z.B. den Hinweis
There must be no advertising for your own services or contact information in the Administration, description, or images. Links that encourage contact are not permitted, including support email addresses and backlinks.
Und wenn du dann auf deine Dokumentation mit Kontaktdaten und Eigenwerbung für andere Plugins verlinkst, dann wird das Plugin korrekterweise abgelehnt.
Hier nur mein Tipp: sollte das tatsächlich belegbar relevant sein, dann erwähne das z.B. im Video, das du für die QA zur Prüfung anlegst.
Viele Grüße
Ja, natürlich ändern sich Regelwerke und Anforderungen über die Zeit. Der zwingend notwendige Mehrwert wurde mit der Auflösung der Cluster abgeschafft - und die Quality Guidelines sind ebenfalls relativ frisch überarbeitet worden. Selbstverständlich können geänderte Regeln aber nur für neue Plugins gelten, da Shopware nicht alle 3.000 Plugin im Store nach jedem Regel-Update dagegen testen kann. Also halte dich an die dokumentierten Regeln ohne auf andere/ältere Plugins zu zeigen - und dann wird der Prozess auch für dich schneller gehen.
Viele Grüße
Zustimmung, Regeln ändern sich, zur Vereinfachung rege ich an, dass wir vor der Übergabe an die QA nochmal die entsprechenden Regeln im Detail anklicken. Also nicht wie jetzt „ich beachte die Guidelines“, sondern dann wirklich nochmal Punkt für Punkt. Ich schreibe jetzt seit 2 Monaten mit einem Kollegen aus der qa darüber, ob ein Plugin durch die Preview kommt oder nicht, erst heißt es nein, dann stelle ich Rückfragen, dann erklärt er es mir, ich mache ein Angebot zur Lösung, er sagt ok, ich ändere die Beschreibung, indem ich einen Satz ergänze, und nun warte ich auf die Freigabe der Preview. Prozessdauer: Monate.
→ simple Checkliste, die verbindlich eingehalten werden muss, ggf. mit einem simplen Muster (richtig/falsch).
Beispiel: Was ist bitte Marketing? Link auf die eigene Seite, weil da ne Doku liegt? Oder ein SEO-Sermon?
Ja, schnell"ER". Du hast ja von deinem Fall erzählt - und der wäre deutlich schneller erledigt gewesen, wenn ihr euch im Vorfeld an die Guidelines gehalten hättet. Klar, dann hätte der Prozess auch seine 4 Wochen gedauert, aber du hast ja explizit dieses „Problem“ angesprochen, warum sich die Freigabe für dieses Plugin so verzögert hat.
Viele Grüße
Was Marketing in dem Fall bedeutet? Alles was nicht zu der Erweiterung gehört wie Agenturverlinkung, Support ausserhalb des Shopwareaccounts, Werbung für das eigene Unternehmen etc., eben alles was nicht relevant für die Beschreibung der Erweiterung ist. Dies wird nicht gemacht, weil wir euch ärgern wollen, sondern um einen fairen Wettbewerb für alle zu ermöglichen. ALLE müssen sich daran halten, und ja, es wird jetzt schärfer darauf geachtet als zuvor, aber das gilt eben für alle.
Das nächste mal einfach diesen Prompt an Claude Code geben - und die Fehler korrigieren 
# SHOPWARE STORE READINESS DUE DILIGENCE – XXXXX
## Mission
Du agierst gleichzeitig als:
* Senior Shopware 6.7 Architect
* Shopware Store Reviewer
* Security Auditor
* QA Engineer
* PHPStan Specialist
* Technical Due-Diligence Reviewer
Dein Auftrag ist **nicht**, die Dokumentation zusammenzufassen.
Dein Auftrag ist:
> Herauszufinden, ob das Plugin `XXXXX` heute mit hoher Wahrscheinlichkeit im Shopware Store akzeptiert werden würde.
Arbeite wie ein echter Store-Reviewer.
Suche aktiv nach Gründen für eine Ablehnung.
Beende die Analyse erst, wenn keine weiteren relevanten Findings mehr identifiziert werden können.
---
# Projekt
Umgebung:
* Shopware 6.7
* DDEV Umgebung: `ddev/sw67`
* Plugin: `XXXXX`
---
# WICHTIGE ARBEITSREGELN
## Evidence First
Jede Feststellung muss belegt werden.
Jeder Fund benötigt:
* betroffene Datei
* betroffene Zeile(n)
* Code-Beweis
* Dokumentations-Beweis
* Begründung
* Risikoeinstufung
Keine Vermutungen.
Keine hypothetischen Probleme.
Keine allgemeinen Best Practices ohne konkreten Bezug zum Code.
Wenn etwas nicht geprüft werden kann:
* explizit dokumentieren
* Grund nennen
* Auswirkungen beschreiben
---
# PHASE 1 – Vollständige Codebase-Erfassung
Analysiere zunächst die gesamte Plugin-Struktur.
Dokumentiere:
## Architekturübersicht
* Plugin Bootstrap
* Services
* Service Definitionen
* Subscriber
* Event Listener
* Commands
* Controllers
* API Endpoints
* DAL Erweiterungen
* Entities
* Entity Extensions
* Repositories
* Scheduled Tasks
* Message Queue Komponenten
* Custom Fields
* Storefront Erweiterungen
* Twig Erweiterungen
* Administration Komponenten
* Vue Komponenten
* Migrations
* Composer Setup
Erstelle daraus eine technische Architekturübersicht.
Erst danach mit den Audits beginnen.
---
# PHASE 2 – Vollständiger Shopware Guidelines Audit
Verwende als Ausgangspunkt:
https://developer.shopware.com/docs/guides/development/testing/store/
Pflicht:
* Folge jedem Link innerhalb dieser Guideline.
* Folge sämtlichen relevanten Unterseiten.
* Lies alle referenzierten Anforderungen vollständig.
* Berücksichtige sämtliche Store-Anforderungen.
Prüfe jede einzelne Anforderung gegen den tatsächlichen Plugin-Code.
Nicht oberflächlich.
Nicht stichprobenartig.
Vollständig.
---
# PHASE 3 – Store Reviewer Simulation
Versetze dich in die Rolle eines echten Shopware Store Reviewers.
Frage bei jeder Komponente:
> Würde ich dieses Plugin wegen dieses Punktes ablehnen?
Analysiere insbesondere:
## Security
* XSS
* SQL Injection
* Command Injection
* CSRF
* Missing Escaping
* Unsichere Dateizugriffe
* Unsichere Uploads
* Rechteprüfungen
* ACL Nutzung
* Input Validation
* Output Escaping
* Session Handling
## Lifecycle
* Installation
* Update
* Deinstallation
* Reinstallation
* Datenrückstände
* Datenverlust
## Datenbank
* Migration Qualität
* Rollback Risiken
* Foreign Keys
* Indexe
* Performance
* DAL Konformität
## Storefront
* Twig Anti-Patterns
* Caching Probleme
* Performance Risiken
* SEO Risiken
## Administration
* Deprecated APIs
* Vue Anti-Patterns
* Event Handling
* State Management
* Memory Leaks
## Qualität
* Dead Code
* Debug Code
* Auskommentierter Code
* Hardcoded Strings
* Fehlende Übersetzungen
* Veraltete APIs
* Deprecated APIs
* BC-Risiken
---
# PHASE 4 – PHPStan Shopware Analyse
Dokumentation:
https://github.com/shopware/phpstan-shopware
## Vorbereitung
Prüfe:
* composer.json
* composer.lock
* phpstan.neon
* phpstan.neon.dist
* QA Tooling
* Dev Dependencies
Dokumentiere den aktuellen Zustand.
---
## Installation
Falls PHPStan Shopware nicht vorhanden ist:
Installiere gemäß offizieller Dokumentation.
Dokumentiere:
* installierte Pakete
* geänderte Dateien
* Konfigurationsänderungen
---
## Durchführung
Führe PHPStan gegen das komplette Plugin aus.
Nutze das höchstmögliche sinnvolle Analyse-Level für Shopware Plugins.
Wenn Fehler die Ausführung verhindern:
1. Ursache analysieren
2. Konfiguration korrigieren
3. Fehlende Pakete installieren
4. Erneut ausführen
Nicht nach dem ersten Fehler abbrechen.
Arbeite weiter bis:
* ein vollständiger Lauf möglich ist
* oder ein nachweislich unüberwindbares Problem dokumentiert wurde
---
## PHPStan Findings
Für jeden Fund:
* Datei
* Zeile
* Severity
* Originalmeldung
* Technische Erklärung
* Mögliche Auswirkung
* Lösungsvorschlag
* Beispiel-Fix
---
# PHASE 5 – Zusätzliche Qualitätsprüfungen
Unabhängig von den Shopware Guidelines.
## Composer Audit
Prüfe:
* unnötige Abhängigkeiten
* fehlende Abhängigkeiten
* Versionsprobleme
* Constraint-Probleme
---
## PHP Audit
Prüfe:
* fehlende Type Hints
* fehlende Return Types
* Mixed Usage
* Nullable Risiken
* Runtime Risiken
* Strict Typing
---
## Symfony Audit
Prüfe:
* DI Konfiguration
* Service Visibility
* Autowiring
* Event Subscriber Qualität
* Container Anti-Patterns
---
## Datenbank Audit
Prüfe:
* Migration Qualität
* Datensicherheit
* Performance
* Konsistenz
---
## Security Audit
Prüfe aktiv:
* XSS
* SQL Injection
* CSRF
* Privilege Escalation
* Unsichere Eingaben
* Unsichere Ausgaben
* ACL Verstöße
---
# PHASE 6 – Dreifach-Audit
Führe mindestens drei getrennte Prüfungsrunden durch.
## Runde 1
Breite Analyse.
---
## Runde 2
Überprüfe sämtliche Ergebnisse aus Runde 1 kritisch.
Suche gezielt nach:
* übersehenen Problemen
* falschen Einschätzungen
* fehlenden Nachweisen
Dokumentiere alle neu gefundenen Findings.
---
## Runde 3
Verhalte dich wie ein besonders strenger Shopware Store Reviewer.
Suche ausschließlich nach Gründen für eine Ablehnung.
Dokumentiere zusätzliche Findings.
---
## Vergleich
Vergleiche alle drei Runden.
Liste auf:
* neu entdeckte Findings
* korrigierte Findings
* geänderte Bewertungen
---
# PHASE 7 – Priorisierung
Ordne jedes Finding einer Kategorie zu.
## P0 – Store Blocker
Hohe Wahrscheinlichkeit einer Store-Ablehnung.
---
## P1 – Kritisch
Muss vor Release behoben werden.
---
## P2 – Wichtig
Sollte zeitnah behoben werden.
---
## P3 – Optional
Verbesserungspotenzial.
---
# PHASE 8 – Konkrete Fixes
Für jedes P0- und P1-Finding:
Erstelle:
* konkrete Lösung
* betroffene Datei
* notwendige Änderungen
* Beispiel-Patch
* Aufwandsschätzung
* Risiko der Änderung
---
# PHASE 9 – Abschlussberichte
## 1. Executive Summary
Management-taugliche Zusammenfassung.
---
## 2. Architekturübersicht
Technischer Überblick über das Plugin.
---
## 3. Store Compliance Report
Alle Verstöße gegen Shopware-Richtlinien.
---
## 4. PHPStan Report
Alle PHPStan Findings.
---
## 5. Security Report
Alle Security Findings.
---
## 6. Store Blocker Report
Nur P0 Findings.
---
## 7. Priorisierte TODO-Liste
Sortiert nach:
* Risiko
* Aufwand
* Nutzen
---
## 8. Quick Wins
Probleme mit geringem Aufwand und hoher Wirkung.
---
# PHASE 10 – Store Readiness Bewertung
Bewerte das Plugin numerisch.
## Security
0–100
## Code Quality
0–100
## Maintainability
0–100
## Upgrade Safety
0–100
## Store Compliance
0–100
Berechne daraus einen Gesamtscore.
---
# ABSCHLIESSENDE ENTSCHEIDUNG
Beantworte abschließend exakt diese Frage:
> Würde ich dieses Plugin heute in den Shopware Store einreichen?
Antwort ausschließlich mit einer dieser vier Optionen:
* Ja
* Eher Ja
* Eher Nein
* Nein
Anschließend die Begründung.
---
# ABBRUCHKRITERIUM
Die Analyse gilt erst als abgeschlossen, wenn:
* alle relevanten Shopware Guidelines geprüft wurden
* PHPStan vollständig ausgeführt wurde oder die Blockade dokumentiert wurde
* drei Audit-Runden abgeschlossen wurden
* keine neuen relevanten Findings mehr entstehen
* sämtliche Findings priorisiert wurden
* eine finale Store-Readiness-Empfehlung vorliegt
Arbeite gründlich. Suche aktiv nach Ablehnungsgründen. Behandle das Plugin so, als würde morgen die reale Shopware-Store-Prüfung stattfinden.
Viele Grüße