Hallo zusammen, um die Funktionalität von Import/Export Advanced zu testen, bin ich wie folgt vorgegangen: [list=1] [*] Neues Profil vom Typ “Articles” erstellt, alles unverändert gelassen[/*] [*] Einen Artikel sauber und möglichst vollständig über das Backend angelegt (laut Anleitung “Artikel anlegen” in der Knowledge Base)[/*] [*] Export mit dem erstellten Profil nach CSV durchgeführt und geguckt, was das System ausspuckt[/*] [*] Nach demselben Schema weitere Artikel in der Liste erfasst[/*] [*] Import mit demselben Profil durchgeführt, unter Berücksichtigung der Angaben im Knowledgebase-Artikel “Import/Export: Artikel”[/*][/list] Nach diesem Vorgang sollte man eigentlich erwarten können, dass die über die Liste erfassen Artikel exakt gleich wie der über das Backend angelegte Musterartikel im System stehen. Das tun sie aber nicht. Das Feld length wird exportiert, aber beim Import nicht beachtet, das Feld ist leer bei Neuanlage über die Importliste bzw. wird bei existierenden Artikeln nicht überschrieben. Gleiches gilt für das Feld date, auch hier keinerlei Funktion. Die Knoten im Profil sind richtig definiert. Fehlermeldungen gibt es auch keine. Beide Felder sind extrem wichtig bei Massenimport. Das Date-Feld, um die Anzeige “Neu” steuern zu können, denn mit dem defekten Importer werden alle importierten Artikel als Neu angezeigt, solange man nicht händisch über das Backend ein Datum einträgt. Auf die Length-Angabe kann man auch nicht verzichten, wenn man die Werte zur Anzeige im Frontend bzw. zur Berechnung des Versandvolumens etc. benutzen will. Warum wird so ein einfacher Test wie oben beschrieben nicht durchgeführt, bevor man das Modul auf die Allgemeinheit loslässt? Ich hab einen ganzen Nachmittag damit verbracht, herauszufinden wo da der Wurm drin ist. Und das sind nur die zwei Fehler, die mir auf Anhieb aufgefallen sind. Shopware-Version: 5.0.4 (Nur, weil automatisches Upgrade fehlschlägt und plötzlich statt Produkten nur noch lauter Uppse im Shop sind. Genaugenommen schlägt das Upgrade nicht fehl, sondern es heißt, alles sei korrekt gelaufen. Leider läuft es aber nicht korrekt. Ein uraltes bisher ungelöstes Problem, ich behaupte, kein Mensch hat auch nur die leisteste Ahnung, wo genau man ansetzen muss, diese unsägliche Foreign-Keys-Reparieren-Geschichte ist abendfüllend und funktioniert nicht. Statt zuzugeben, dass der Updater einen Fehler hat, wird das Problem auf die Hoster geschoben, ich hab dasselbe Problem aber auch auf einem lokalen Ubuntu Server, den ich zur Entwicklung benutze. Für Produktivumgebungen eigentlich schon fahrlässig verbuggt.) Plugin-Version: 1.1 Grüße Pierre Schmitz
Hallo, für Felder die nicht importiert/exportiert werden kannst du ja gerne ein Ticket einstellen auf jira.shopware.de. Das Plugin ist so umfangreich, dass hier auch mal etwas „durch die Lappen“ gehen kann. Sollte hier bei einem Update ein Feld nicht mehr importierbar/exportierbar sein, so können wir das ja mit dem nächsten Update fixen. Dafür gibt es ja den Bugtracker. Ein allgemeines Problem beim Updater gibt es definitiv nicht. Wenn du es auf zwei Umgebungen hast, dann liegt es nicht unbedingt am Hoster, sondern kann natürlich auch an deiner Datenbank und deinem Shop liegen. Ohne eine konkrete Angabe deiner Fehlermeldung - die man ja problemlos in den Logs oder mit der passenden Erweiterung auch direkt im Frontend auslesen kann, kann man dir sicherlich schon weiterhelfen. Hier findest du auch Angaben dazu, wie du die Meldung auslesen kannst: http://community.shopware.com/Fehlermel … _1880.html Moritz
Hallo Moritz, vielen Dank für die Information. Ticket PT-4099 ist seit 08.10. eingestellt. Wie lange dauert so eine Korrektur üblicherweise? Ich muss hier entscheiden, ob ich Manpower bereitstelle, um die Daten zur Not händisch über das Backend anzupassen. Oder gibt es einen vorübergehenden Workaround, die Daten direkt in der Datenbank zu ändern? Ohne genaue Kenntnis der Struktur ist mir das Risiko zu hoch… Das mit der Fehlermeldung beim Update schaue ich mir an, vielen Dank schon mal für die weitere Info. :thumbup: Grüße Pierre
Hallo Pierre, das genannte Ticket ist gestern/heute bereits umgesetzt worden. Aktuell gibt es einige Tickets, die wir jetzt am Stück umsetzen. Wir versuchen das als neue Plugin Version so schnell wie möglich bereitzustellen. Ich hoffe, dass es nächste Woche was wird, kann das aber nicht zu 100% versprechen Sebastian
Hallo, ich bleib mal in diesem Thread, hier die Fehlermeldung beim Update auf SW 5.1.1: [quote]The given alias ‘productCategory’ is not part of any FROM or JOIN clause table. The currently registered aliases are: product, variant, tax, productCategory2, availableVariant, avoidCustomerGroup, productAttribute. in vendor/doctrine/dbal/lib/Doctrine/DBAL/Query/QueryException.php on line 37[/quote] #0 vendor/doctrine/dbal/lib/Doctrine/DBAL/Query/QueryBuilder.php(1166): Doctrine\DBAL\Query\QueryException::unknownAlias('productCategory', Array) #1 vendor/doctrine/dbal/lib/Doctrine/DBAL/Query/QueryBuilder.php(1152): Doctrine\DBAL\Query\QueryBuilder-\>verifyAllAliasesAreKnown(Array) #2 vendor/doctrine/dbal/lib/Doctrine/DBAL/Query/QueryBuilder.php(1112): Doctrine\DBAL\Query\QueryBuilder-\>getFromClauses() #3 vendor/doctrine/dbal/lib/Doctrine/DBAL/Query/QueryBuilder.php(244): Doctrine\DBAL\Query\QueryBuilder-\>getSQLForSelect() #4 vendor/doctrine/dbal/lib/Doctrine/DBAL/Query/QueryBuilder.php(206): Doctrine\DBAL\Query\QueryBuilder-\>getSQL() #5 Shopware/Bundle/SearchBundleDBAL/ProductNumberSearch.php(117): Doctrine\DBAL\Query\QueryBuilder-\>execute() #6 Shopware/Bundle/SearchBundleDBAL/ProductNumberSearch.php(95): Shopware\Bundle\SearchBundleDBAL\ProductNumberSearch-\>getProducts(Object(Shopware\Bundle\SearchBundleDBAL\QueryBuilder)) #7 Shopware/Bundle/SearchBundle/ProductSearch.php(65): Shopware\Bundle\SearchBundleDBAL\ProductNumberSearch-\>search(Object(Shopware\Bundle\SearchBundle\Criteria), Object(Shopware\Bundle\StoreFrontBundle\Struct\ProductContext)) #8 Shopware/Core/sArticles.php(2258): Shopware\Bundle\SearchBundle\ProductSearch-\>search(Object(Shopware\Bundle\SearchBundle\Criteria), Object(Shopware\Bundle\StoreFrontBundle\Struct\ProductContext)) #9 Shopware/Core/sArticles.php(454): sArticles-\>getListing(6, Object(Shopware\Bundle\StoreFrontBundle\Struct\ProductContext), Object(Enlight\_Controller\_Request\_RequestHttp), Object(Shopware\Bundle\SearchBundle\Criteria)) #10 Shopware/Controllers/Frontend/Listing.php(211): sArticles-\>sGetArticlesByCategory(6, Object(Shopware\Bundle\SearchBundle\Criteria)) #11 Enlight/Controller/Action.php(158): Shopware\_Controllers\_Frontend\_Listing-\>indexAction() #12 Enlight/Controller/Dispatcher/Default.php(523): Enlight\_Controller\_Action-\>dispatch('indexAction') #13 Enlight/Controller/Front.php(227): Enlight\_Controller\_Dispatcher\_Default-\>dispatch(Object(Enlight\_Controller\_Request\_RequestHttp), Object(Enlight\_Controller\_Response\_ResponseHttp)) #14 Shopware/Kernel.php(148): Enlight\_Controller\_Front-\>dispatch() #15 vendor/symfony/http-kernel/HttpCache/HttpCache.php(492): Shopware\Kernel-\>handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #16 Shopware/Components/HttpCache/AppCache.php(255): Symfony\Component\HttpKernel\HttpCache\HttpCache-\>forward(Object(Symfony\Component\HttpFoundation\Request), true, NULL) #17 vendor/symfony/http-kernel/HttpCache/HttpCache.php(449): Shopware\Components\HttpCache\AppCache-\>forward(Object(Symfony\Component\HttpFoundation\Request), true) #18 vendor/symfony/http-kernel/HttpCache/HttpCache.php(349): Symfony\Component\HttpKernel\HttpCache\HttpCache-\>fetch(Object(Symfony\Component\HttpFoundation\Request), true) #19 Shopware/Components/HttpCache/AppCache.php(178): Symfony\Component\HttpKernel\HttpCache\HttpCache-\>lookup(Object(Symfony\Component\HttpFoundation\Request), true) #20 vendor/symfony/http-kernel/HttpCache/HttpCache.php(213): Shopware\Components\HttpCache\AppCache-\>lookup(Object(Symfony\Component\HttpFoundation\Request), true) #21 Shopware/Components/HttpCache/AppCache.php(114): Symfony\Component\HttpKernel\HttpCache\HttpCache-\>handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #22 shopware.php(101): Shopware\Components\HttpCache\AppCache-\>handle(Object(Symfony\Component\HttpFoundation\Request)) #23 {main} Grüße Pierre
Hab schon selbst gefunden 
post140275.html?hilit=the%20given%20alias#p140275
Hallo, das hängt ja nicht mit diesem Post zusammen, oder? Das Thema gab es z.B. hier: programmierung-f103/fehlermeldung-nach-5-1-0-update-im-kategorie-listing-t31681.html Ich tippe auch stark auf Plugins, die nicht kompatibel sind und Cache/Attribut-Cache der nicht aktuell ist Sebastian
Habe das Problem eingegrenzt. Der Fehler wird durch das Plugin “Individuelle Sortierung” von SWAG hervorgerufen. Im Shop ist Plugin-Version 1.03 installiert. Im Ticket PT-4147 wird ist das Plugin angefasst. Bitte guckt zusätzlich mal danach. Vielen Dank! Grüße Pierre
Das Ticket PT-4099 steht immernoch unverändert auf „Waiting für QA“. Wann geht es hier weiter? Grüße Pierre
Es sind weitere 11 Tage vergangen. Wann wird das Update bereitstehen? Wir sind dringend darauf angewiesen! Grüße Pierre
Hallo, das Modul wird derzeit mit mehreren Tickets überarbeitet. Nicht jedes Ticket bedeutet auch direkt eine neue Version im Store, diese werden gesammelt und dann in ein Release gepackt. Schreib mir mal eine Mail an forum@shopware.de dann kann ich dir gerne den aktuellen Entwicklungsstand zukommen lassen. Grüße Moritz
Langsam werde ich echt ungeduldig. Wann ist das Update verfügbar?
Alles klar, ich hab deine Antwort nicht gesehen. Mail kommt gleich Grüße Pierre
Hallo, ich bleibe mal in diesem Thread, ich habe in der Suche nichts gefunden. Ich habe jetzt die aktualisierte Plugin-Version von Github installiert und ein weiteres Problem festgestellt. Ich weiß nicht, ob es sich um einen Bug oder ein Feature handelt, deswegen frage ich erstmal hier nach. Die Kategorie-IDs (das Feld category) beim Artikelimport werden vom Importer immer nur hinzugefügt. Wenn man sich vertan hat und will über den Import eine Reihe Artikel einer anderen Kategorie zuordnen als ursprünglich gemacht, dann ist es nicht ausreichend, einfach aus der Liste die falsche Kategorie rauszulöschen und stattdessen die neue ID einzutragen. Der Importer löscht keine vorhandenen Kategoriezuordnungen aus dem System, sondern nach dem erneuten Import ist der Artikel in zwei Kategorien vorhanden. Das ist doch eigentlich verkehrt, oder? Wie soll man sonst gesammelt Produkte aus Kategorien löschen, wenn nicht darüber? Bitte um Rückmeldung und ggf. Aufnahme in den Bugtracker. Grüße Pierre
Hallo, über den Import kannst du nur Informationen zu den Artikeln hinzufügen. Das verhält sich hier identisch zum Bildimport. Es gibt aktuell keine Logik um Informationen bei einem Artikel komplett zu löschen. Die Anforderung bei diesem Modul war zunächst die Logik des alten Modules 1:1 zu ersetzen/abzubilden, damit man dies aus dem Core ablösen kann. Du kannst dafür gerne einen Feature-Request aufmachen, allerdings ist das wirklich eine komplett neue Funktion, die nicht kurzfristig im Modul umgesetzt werden wird. Also weder ein Feature, noch ein Bug. Die Funktion gibt es einfach nicht. Grüße Moritz
Hallo Moritz, genaugenommen nimmt man das als Nutzer hier nicht als “löschen” wahr. Man würde bei der Kategoriezuordnung eigentlich vermuten, dass es sich wie bei allen anderen Feldern verhält, nämlich dass vorhandene Daten bei einem erneuten Import mit den neuen Daten überschrieben werden. Das klappt hier aber nicht, weil wohl für die Zuordnung Artikel Kategorie in einer anderen Tabelle ein Datensatz angelegt wird. Der Importer kann diese Datensätze aber nur hinzufügen und vorhandene nicht verändern. Wahrscheinlich kann er an dieser Stelle auch gar nicht sagen, ob überhaupt schon welche vorhanden sind. Ein Feature Request muss man nicht unbedingt draus machen. Vielleicht könnt ihr ja einen Hinweis in die Doku aufnehmen, dass man hier aufpassen muss. Es gilt also hier ganz besonders, dass man vor dem Import eine Sicherung der Datenbank anfertigt. Tausendfaches Korrigieren über einen weiteren Import ist an dieser Stelle nicht möglich… Grüße Pierre