KM-Agentur Posted March 21, 2017 Share Posted March 21, 2017 Der Shop fügt Artikel dem Warenkorb hinzu (Allerdings) ohne Berechnung Wenn man den Artikel lösch, wird der Betrag der Summe abgezogen und die Gesamtsumme stimmt nicht mehr ! Wie kann ich das schnellstens korrigieren.. der Shop ist scharf und der Kunde steigt mir aufs Dach Link to comment Share on other sites More sharing options...
selectshop.at Posted March 21, 2017 Share Posted March 21, 2017 Die Produkte werden gekauft ? Wenn nur Artikel dem Warenkorb hinzugefügt werden und nicht gekauft werden, dann sind das sicher Suchmaschinen. Und ein gaz normales Indexierungsverhalten. Nicht eingekaufte Warenkörbe von Zeit zu Zeit aus den Statistiken löschen, oder deinen Webspace mit Firewalls sichern. Link to comment Share on other sites More sharing options...
KM-Agentur Posted March 21, 2017 Author Share Posted March 21, 2017 (edited) Herzlichen Dank für die Idee, aber das kann ich mir nicht vorstellen, denn selbst das manuelle eingeben einer Bestellung hat dieses Phänomen zur Folge !?! Der Warenkorb ist im Prinzip OK, erst nach dem Bestellen ist dann ein Artikel mehr im Warenkorb und verhält sich eben so, daß eine Berechnung nicht erfolgt, wenn man ihn aber dann aus der Bestellung löscht, ist der Gesamtbetrag der Rechnung genau um den Betrag, den der (seltsam) hinzugefügte Artikel kosten würde zu gering... Edited March 21, 2017 by KM-Agentur (see edit history) Link to comment Share on other sites More sharing options...
selectshop.at Posted March 21, 2017 Share Posted March 21, 2017 1 Artikel mehr im Warenkorb, deutet daraufhin, dass manuell in die Datenbank eingegriffen wurde und ID-Zuordnung geschossen sind. Es sind Phantromdatensätze mit nicht zuordenbaren Abhängigkeiten vorhanden. Die einzige Methode diesen Fehler zu beheben, ist: Datenbankaufbau komplett neu, oder die Zuordnungen aller Abhägingkeiten in der Datenbank zu überprüfen (kann nur ein Prestaprofi machen). Am Besten alles exportieren was du hast, die Datenbank leeren und dann alles neu importieren. Also von Null anfangen, oder du beauftragst einen Experten, der dir den Fehler der Zuordnungen sucht, identifiziert und behebt. Je nach Größe der Datenbank eine langwierige Arbeit. Link to comment Share on other sites More sharing options...
KM-Agentur Posted March 21, 2017 Author Share Posted March 21, 2017 Also einen manuellen Eingriff in die Datenbank kann ich ausschliessen. Abhängigkeiten in der Datenbank, die dann einen Warenkorb mit Artikeln (bei bestimmten Kunden, mit unbestimmten Artikeln) füllen ? Der Shop ist noch am Anfang, obwohl er schon scharf ist... er wurde geprüft und getestet, bevor er online ging... und der Fehler wird seit 2 Tagen wahrgenommen.. da müsste der Fehler doch zu finden sein? Ohne langwierig ?!? Link to comment Share on other sites More sharing options...
Whiley Posted March 21, 2017 Share Posted March 21, 2017 Welche PS-Version? Welche Module verwendet? Welche Caches verwendet? Werden sonst noch Fehler angezeigt beim aktivieren von "error-reporting"? Ev url posten! Link to comment Share on other sites More sharing options...
KM-Agentur Posted March 21, 2017 Author Share Posted March 21, 2017 Hallo, die Version ist 1.6.1.1 Caches habe ich ausgeschaltet Error-Reporting ist ohne Ausgabe Verwaltung 1-Click-Upgrade v1.6.7 - von PrestaShop Statistiken & Analysen Artikeldetails v1.5.0 - von PrestaShop Front-Office Funktionen Ausgewählte Artikel auf der Startseite v1.8.1 - von PrestaShop Zahlungsarten & Schnittstellen Banküberweisung v1.1.2 - von PrestaShop Content-Management Benutzerdefinierte Felder v1.3.9 - von modulesmarket.com Statistiken & Analysen Beste Kunden v1.5.1 - von PrestaShop Fügt der Statistik-Übersicht eine Liste der besten Kunden hinzu Statistiken & Analysen Besucher online v1.3.1 - von PrestaShop Fügt der Statistik-Übersicht eine Liste der Kunden und Besucher, die aktuell online sind, hinzu Statistiken & Analysen Besuche und Besucher v1.6.1 - von PrestaShop Fügt der Statikstik-Übersicht eine Auswertung der Beusche und Besucher hinzu. Front-Office Funktionen Block Angesehene Produkte v1.3.1 - von PrestaShop Fügt einen Block hinzu, der die zuletzt angesehenen Artikel anzeigt Front-Office Funktionen Block Facebook v1.4.1 - von PrestaShop Zeigt einen Block an, auf dem man Ihre Facebook-Seite abonnieren kann. Front-Office Funktionen Block Kontakt v1.4.1 - von PrestaShop Zeigt Informationen über Ihren Kundenservice an. Front-Office Funktionen Block Kontaktinformationen v1.2.1 - von PrestaShop Fügt einen anpassbaren Block hinzu, der die Kontaktinformationen Ihres Shops im Footer anzeigt. Front-Office Funktionen Block Kunden-Datenschutz v2.0.2 - von PrestaShop Fügt einen Block hinzu, um Informationen zum Kunden-Datenschutz anzuzeigen. Front-Office Funktionen Block Kundenbereich v1.4.1 - von PrestaShop Zeigt einen Block mit Links des Benutzerkontos an. Front-Office Funktionen Block Kundenbereich im Footer v1.6.1 - von PrestaShop Zeigt ein Block mit Links des Kundenkontos an. Front-Office Funktionen Block Login v0.4.1 - von PrestaShop Fügt einen Block hinzu, der Informationen über den Kunden anzeigt Front-Office Funktionen Block Newsletter v2.3.2 - von PrestaShop Fügt einen Block für Newsletter-Abos hinzu Preise & Sonderangebote Block Sonderangebote v1.3.1 - von PrestaShop Fügt einen Block mit aktuellen Sonderangeboten hinzu Front-Office Funktionen Block Soziale Netzwerke v1.2.2 - von PrestaShop Ermöglicht Ihnen, zusätzliche Informationen für soziale Netzwerke hinzuzufügen. Front-Office Funktionen Block Stichwörter v1.3.1 - von PrestaShop Fügt einen Block mit einer Tag-Cloud hinzu Front-Office Funktionen Block Verkaufshits v1.8.1 - von PrestaShop Block mit Verkaufshits des Shops hinzufügen. Front-Office Funktionen Block Warenkorb v1.6.1 - von PrestaShop Fügt einen Block mit dem Warenkorb des Kunden hinzu Front-Office Funktionen Block Zahlungslogos v0.4.1 - von PrestaShop Fügt einen Block mit allen Zahlungslogos hinzu Statistiken & Analysen Browser und Betriebssysteme v1.3.1 - von PrestaShop Fügt der Statistik-Übersicht eine graphische Auswertung der Browser und Betriebsysteme Ihrer Kunden hinzu Front-Office Funktionen CMS Block v2.1.2 - von PrestaShop Fügt einen Block mit mehreren CMS-Links ein. Verwaltung Cron Tasks Verwaltung v1.3.4 - von PrestaShop Hier können Sie alle automatisierten Web Aufgaben verwalten. Übersicht Dashboard Aktivitäten v1.0.0 - von PrestaShop Übersicht Dashboard Artikel v1.0.0 - von PrestaShop Fügt einen Block mit einer Tabelle der letzten Bestellungen und einem Ranking Ihrer Artikel hinzu Übersicht Dashboard Trends v1.0.0 - von PrestaShop Fügt einen Block mit einer grafischen Darstellung zur Entwicklung Ihres/r Shops basierend auf ausgewählten Kenndaten hinzu. Übersicht Dashboard Ziele v1.0.0 - von PrestaShop Fügt einen Block mit Ihrer Shop-Prognose hinzu. Front-Office Funktionen Deluxe Private Categories v1.5.0 - von innovaDeluxe This module allows the access to categories, to the customers or customer groups you want. Verwaltung Easy Delete Orders v1.2.0 - von idnovate Delete orders safe and easily. Front-Office Funktionen Eigener CMS-Block v1.6.1 - von PrestaShop Fügt dem Shop eigene CMS-Blocks hinzu Verwaltung Einfache HTML-Tabelle v1.3.1 - von PrestaShop Statistik in tabellarischer Form darstellen Verwaltung Handelserfolg v1.12.3 - von PrestaShop E-Commerce-Experte im Handumdrehn! Statistiken & Analysen Herkunft der Besucher v1.4.1 - von PrestaShop Fügt der Statistik-Übersicht eine graphische Auswertung der Herkunfts-Webseiten Ihrer Besucher hinzu Front-Office Funktionen Horizontale Navigationsleiste v2.2.4 - von PrestaShop Zeigt eine frei konfigurierbare horizontale Navigationsleiste im Kopf Ihrer Website an. Front-Office Funktionen Image Slider für Ihre Webseite v1.6.1 - von PrestaShop Fügt Ihrer Website einen Slider hinzu. Statistiken & Analysen Information zu registrierten Kunden v1.4.1 - von PrestaShop Fügt der Statistik-Übersicht Informationen über registrierte Kunden (z.B. Geschlecht und Alter) hinzu Statistiken & Analysen Katalogauswertung v1.5.0 - von PrestaShop Fügt der Statistik-Übersicht eine Schnellauswertung Ihres Warenkatalogs hinzu Statistiken & Analysen Katalogstatistik v1.4.0 - von PrestaShop Fügt der Statistik-Übersicht einen Tab mit allgemeinen statistischen Auswertungen zu Ihrem Katalog hinzu Statistiken & Analysen Kundenkonten v1.4.1 - von PrestaShop Fügt der Statistik-Übersichteinen Tab zur Entwicklung der Anmeldezahlen hinzu Verwaltung Mail alerts v3.6.1 - von PrestaShop Sends e-mail notifications to customers and merchants. Bestellvorgang Maximum product quantity per customer v1.5.5 - von MyPresta.eu With this module you can define maximum quantity of product per customer group. Customers will not be able to order more products. Front-Office Funktionen Neukunden Alarm v1.0.0 - von idnovate Per E-Mail benachrichtigen, wenn sich ein neuer Kunde in Ihrem Shop registriert . Statistiken & Analysen Newsletter v1.4.2 - von PrestaShop Fügt der Statistik-Übersicht einegraphische Auswertung der Newsletter-Anmeldungen hinzu Verwaltung NVD3 Charts v1.5.1 - von PrestaShop Zahlungsarten & Schnittstellen PayPal v3.11.3 - von PrestaShop - Standard Accepts payments by credit cards (CB, Visa, MasterCard, Amex, Aurore, Cofinoga, 4 stars) with PayPal. Statistiken & Analysen Seiten nicht gefunden v1.5.1 - von PrestaShop Zeigt in der Statistik die Seiten an, die Besucher aufrufen wollten, aber nicht gefunden haben. Werbung & Marketing Soziale Netzwerke v1.4.3 - von PrestaShop Zeige die Buttons Sozialer Netzwerke (Twitter, Facebook, Google+ and Pinterest) auf jeder Artikelseite. Statistiken & Analysen Statistik v1.6.2 - von PrestaShop Dieses Modul muss aktiviert sein, wenn Sie die Statistiken verwenden möchten Statistiken & Analysen Statistik-Kontrollzentrum v1.4.1 - von PrestaShop Dies ist das Hauptmodul der Statistik. Dieses Kontrollzentrum zeigt eine Zusammenfassung Ihrer aktuellen Statistikdaten. Zahlungsarten & Schnittstellen Stripe payment module v1.3.1 - von 202 ecommerce - Standard Start accepting stripe payments today, directly from your shop! Statistiken & Analysen Suchmaschinen-Schlüsselworte v1.4.1 - von PrestaShop Zeigt an, über welche Suchbegriffe Besucher Ihre Webseite gefunden haben Front-Office Funktionen Template-Konfigurator v2.1.2 - von PrestaShop Richten Sie die Elemente Ihres Templates ein. Statistiken & Analysen Verkäufe und Bestellungen v1.3.1 - von PrestaShop Fügt der Statistik-Übersicht eine Grafik zur Entwicklung der Verkäufe und Bestellungen hinzu. Statistiken & Analysen Verteilung der Lieferanten v1.4.1 - von PrestaShop Fügt der Statistik-Übersicht eine Grafik des Verteilungsraums jedes einzelnen Versanddienstes hinzu Front-Office Funktionen Währungsblock v0.4.1 - von PrestaShop Fügt einen Block zur Auswahl der Währung hinzu Link to comment Share on other sites More sharing options...
rictools Posted March 21, 2017 Share Posted March 21, 2017 (edited) Tatsächlich Version 1.6.1.1? Spricht etwas gegen ein Upgrade auf 1.6.1.11? Tritt der Fehler regelmäßig und ggf. nachvollziehbar auf? Sind bestimmte Produkte betroffen (ggf. diese löschen und neu anlegen)? Lassen sich die betroffenen Produkte auch ganz normal bestellen und wird dann der Preis angezeigt? Gibt es irgendwelche nicht mehr benötigten Preisregeln (ausmisten)? Edited March 21, 2017 by rictools (see edit history) Link to comment Share on other sites More sharing options...
KM-Agentur Posted March 21, 2017 Author Share Posted March 21, 2017 Ohh Sorry, natürlich ist es die Version 1.6.11 Leider ist der Fehler überhaupt nicht nachvollziehbar. Preisregeln gibt es keine Die willkürlich hinzugefügten Artikel gehören zu einer anderen Kundengruppe und können auch über diese ganz normal gekauft werden mit korrekter Berechnung Link to comment Share on other sites More sharing options...
Whiley Posted March 21, 2017 Share Posted March 21, 2017 kann es sein, daß der Fehler erstmals nach dem Einsatz von "Easy Delete Orders" aufgetreten ist? Ist der Fehler reproduzierbar, also bei gleichen bestellten Artikeln wird der gleiche Falschartikel hinzuaddiert? Link to comment Share on other sites More sharing options...
KM-Agentur Posted March 21, 2017 Author Share Posted March 21, 2017 Beides mal "Nein" der Shop lief in der Testphase mit den angegebenen Modulen Fehlerfrei und die Artikel werden "so meine ich" willkürlich hinzugefügt. Irgendwo müssen die Artikel doch herkommen.. kann es irgendwie am Cache liegen ? Link to comment Share on other sites More sharing options...
Claudiocool Posted March 21, 2017 Share Posted March 21, 2017 Eventuell mal die Sache so angehen, dass im Debug-Mode mal die Overrides und Module weggeschaltet werden. Link to comment Share on other sites More sharing options...
rictools Posted March 21, 2017 Share Posted March 21, 2017 Ohh Sorry, natürlich ist es die Version 1.6.11 Diese Version gibt es nicht ... Andere Kundengruppe? D. h. der Kunde, der die Artikel in den Warenkorb gelegt bekommt, bekommt diese normalerweise gar nicht zu sehen und kann sie auch nicht bestellen? Diese Funktion wird wohl von diesem Modul ermöglicht: Front-Office Funktionen Deluxe Private Categories v1.5.0 - von innovaDeluxe This module allows the access to categories, to the customers or customer groups you want. Dann würde ich zunächst das Modul resetten, ggf. zeitweise deaktivieren, evtl. den Modulautor kontaktieren. Link to comment Share on other sites More sharing options...
Whiley Posted March 21, 2017 Share Posted March 21, 2017 kann es irgendwie am Cache liegen ? Na klar, deshalb meine Frage nach dem Cache du hattest geschrieben "Caches habe ich ausgeschaltet" Also schalte alle Caches ab, auch den Smarty-Cache und lösche alle File-u. Memory-Caches - und lösche auch jeweils den Browser-Cache - dann erneut testen. Link to comment Share on other sites More sharing options...
KM-Agentur Posted March 21, 2017 Author Share Posted March 21, 2017 Dies habe ich bereits gemacht... alles Caches wurden ausgeschaltet und der Cache gelöscht... Zudem habe ich natürlich auch meinen eigenen Browsercache gelöscht.. aber irgendwo müssen doch trotzdem die Produktdaten herkommen ?!?? Link to comment Share on other sites More sharing options...
Claudiocool Posted March 21, 2017 Share Posted March 21, 2017 wie wäre es mal mit einem Link, zum nachvollziehen? Link to comment Share on other sites More sharing options...
KM-Agentur Posted March 21, 2017 Author Share Posted March 21, 2017 www.dealsandbenefits.ch Link to comment Share on other sites More sharing options...
Claudiocool Posted March 21, 2017 Share Posted March 21, 2017 Bei mir zickt der nicht.... Link to comment Share on other sites More sharing options...
KM-Agentur Posted March 21, 2017 Author Share Posted March 21, 2017 (edited) Bei manchen Kunden eben schon, daß ist ja das verwunderliche.... Vielleicht hat es auch etwas mit den Kundengruppen zu tun ?!? Edited March 21, 2017 by KM-Agentur (see edit history) Link to comment Share on other sites More sharing options...
Claudiocool Posted March 21, 2017 Share Posted March 21, 2017 Kann ich mir jetzt nicht direkt vorstellen, aber unmöglich ist es nicht Link to comment Share on other sites More sharing options...
Whiley Posted March 21, 2017 Share Posted March 21, 2017 Link to comment Share on other sites More sharing options...
KM-Agentur Posted March 21, 2017 Author Share Posted March 21, 2017 Ahhh.. das ist doch schon einmal etwas ! Aber wie kann er im Cache suchen, wenn alle ausgeschaltet sind ? Link to comment Share on other sites More sharing options...
Claudiocool Posted March 21, 2017 Share Posted March 21, 2017 (edited) leere den Cache einfach mal manuell also in ....cache/smarty/compile/ alles ausser der index.php Aber nicht mit dem Radiergummi Presta, sondern per FTP-Zugang Edited March 21, 2017 by Claudiocool (see edit history) 1 Link to comment Share on other sites More sharing options...
frezzo Posted July 30, 2017 Share Posted July 30, 2017 Vielen Dank für die Inputs. Wir haben das selbe Problem und sind am debuggen des Smarty Cache Problem - wobei wir den Ursprung nicht finden. Der Button Clear Cache von Prestashop tut überhaupt nicht was er soll - die Cache bleiben vorhanden. Deswegen kommt man nicht drum herum um den Inhalt (ausser die index.php) von: /cache/smarty/cache und (wie auch Claudiocool schon gesagt hat: cache/smarty/compile/ zu löschen. Wir nutzen Prestashop 1.6.1.15. Ich versuche euch hier auf dem Laufenden zu halten, vielleicht schlägt sich ja wieder jemand mit dem Problem herum. Jeder Hinweis den SmartyCache in den Griff zu bekommen ist willkommen. ich würde auch jemand, der sich wirklich damit gut auskennt gerne für das debuggen ins Boot holen. Hat jemand Ahnung wie man das Problem löst? Gerne per PM eine Mitteilung welche Ansätze und welches Honorar du dir vorstellst. Grüsse Link to comment Share on other sites More sharing options...
rictools Posted July 31, 2017 Share Posted July 31, 2017 Der TE hat es jedenfalls nicht für erforderlich gehalten, uns zu informieren, ob sein Problem denn jetzt gelöst ist. Bei dir werden auch eigenständig falsche Produkte in den Warenkorb gelegt? Was ist denn dann bei dir, nachdem du per FTP die Smarty-Cache-Ordner gelöscht hast? Und wo liegt jetzt eigentlich das Problem? Läßt sich der Smarty-Cache nicht ausschalten? Oder mußt /willst du diesen unbedingt benutzen und hast nur ein Problem mit dem einfachen Löschen? Es gibt zum Löschen der verschiedenen Caches übrigens massenhaft Module (auch kostenlos), da werden ja wohl welche dabei sein die funktionieren ...). Link to comment Share on other sites More sharing options...
Scully Posted July 31, 2017 Share Posted July 31, 2017 (edited) Wir haben eine 1.6.1.15 testhalber am Laiufen. Gerade mal geschaut: Clear Cache löscht die Files in ./cache/smarty/compile Löscht jedoch nicht die Files in ./cache/smarty/cache Kann jemand mal testen, ob die Files in smarty/cache nicht auch weg sein müssten? Ich halte das für einen Fehler - zumindest frühere Versionen haben m.E. auch ./smarty/cache gelöscht. Edited July 31, 2017 by Scully (see edit history) Link to comment Share on other sites More sharing options...
selectshop.at Posted July 31, 2017 Share Posted July 31, 2017 Also cache/smarty/cache is bei mir leer. Wenn ich cache/smarty/compile lösche wird der Ordner geleert und sofort wieder neue Unterordner und Dateien geschrieben, was ja korrekt wäre. PS 1.6.1.15 1 Link to comment Share on other sites More sharing options...
frezzo Posted July 31, 2017 Share Posted July 31, 2017 Hallo rictools und community Vorabinfo: Wir haben von 1.6.1.1 auf die Version 1.6.1.15 upgegradet. Da aber auf unserer alten Umgebung so viele individuellen Programmierungen vorgenommen worden sind - haben wir uns dazu entschieden nur ein DB Upgrade zu machen und dieses dann in unsere 1.6.1.15er Version (und nur die nötigen Tabellen) zu importieren. Der Fehler kann also auch daher rühren... Die Testings auf dem DEV Server verliefen reibungslos - aber ohne sämtlichen Cache ... dann wurde der Umzug auf einen Cloud Server vollzogen. Um das Problem in den Griff zu bekommen sind wir bis jetzt (ohne Erfolg) so vorgegangen: Zuerst haben wir den Mem-Cache deaktiviert Zuerst Smarty Cache im BO deaktiviert mit der Einstellung (immer neu kompilieren) - dann Cache gelöscht Da cache/smarty/cache und /compile nicht alles gecleert war - mit SFTP gelöscht (ausser index.php File) den Debug Modus eingeschaltet - festgestellt das BVK eine Table in unserer DB sucht - BVK Fees wurde vorgängig deinstalliert Im Serverlogg sind waren smarty warnings (dazu unten noch mehr) Da dies keine Wirkung zeigte - aus dem OriginalFolgeder unter tools/smarty der Ordner von der Version 1.6.1.15 replaced Anschliessend IMG/tmp geleert und sämtliche cache Folders Update: So - nun ist es vollbracht - es war das BVK Fees Modul was scheinbar in den Overrides nach unserer Deinstallation für Chaos gesorgt hat - jedoch nicht aus den Overrides genommen wurde. Link to comment Share on other sites More sharing options...
Scully Posted July 31, 2017 Share Posted July 31, 2017 Also cache/smarty/cache is bei mir leer. Wenn ich cache/smarty/compile lösche wird der Ordner geleert und sofort wieder neue Unterordner und Dateien geschrieben, was ja korrekt wäre. cache.pngcompile.png PS 1.6.1.15 @Selectshop: Da haben wir in der Tat ein abweichends Verhalten, bei Dir m.E. ok, hier bei uns im Test nicht i.O. @Frezzo: gut ist das auch geklärt. Link to comment Share on other sites More sharing options...
rictools Posted July 31, 2017 Share Posted July 31, 2017 Da aber auf unserer alten Umgebung so viele individuellen Programmierungen vorgenommen worden sind - haben wir uns dazu entschieden nur ein DB Upgrade zu machen und dieses dann in unsere 1.6.1.15er Version (und nur die nötigen Tabellen) zu importieren. Meiner bescheidenen Meinung kann das im besten Fall keine Probleme bringen, aber keinesfalls irgendwelche Vorteile. Ich wüßte überhaupt nicht, welche Fehlerbeseitigungen oder Verbesserungen durch ein Datenbank-Update bewirkt werden sollten, wenn nicht gleichzeitig der eigentliche Programmcode, der ja ausschließlich in den Dateien sitzt, mitupgedatet wird. 1 Link to comment Share on other sites More sharing options...
frezzo Posted July 31, 2017 Share Posted July 31, 2017 Hey Ric Natürlich haben wir auch gleichzeitig ein neues Theme gewählt mit weniger Fehlern. Deswegen haben wir nur die Datenbank-Felder mitgenommen, die wir gebraucht haben. Aber scheinbar muss da wirklich noch dieses BVK Modul in den overrides reingefunkt haben. Zumindest ist nach auscooden der Zeilen der Fehler nun behoben. Bezüglich dem Cache - der leert sich bei uns schlichtweg nicht sauber über den Button Cache leeren. Link to comment Share on other sites More sharing options...
Scully Posted July 31, 2017 Share Posted July 31, 2017 Bezüglich dem Cache - der leert sich bei uns schlichtweg nicht sauber über den Button Cache leeren. Das scheint korrekt, bei uns sowohl mit 1.6.1.13 als auch 1.6.1.15. @RIC Kannst Du mir mal die Dateiversion bei Dir benennen - cirka Zeile 15? ./tools/smarty/Smarty.class.php Wir haben da 3.1.19 drinn mit einer Dateigrösse von 48428 Bytes. Link to comment Share on other sites More sharing options...
frezzo Posted July 31, 2017 Share Posted July 31, 2017 Meine Vorfreude hat nicht lange gehalten - wie RIC schon vermutet hat - war es wohl nicht die ganze Wahrheit an was es gelegen hat. Denn der Fehler ist in gleicher Form heute wieder aufgetreten. Nach dem Compile löschen scheint es wieder zu gehen - fragt sich nur wie lange. Wir melden uns, wenn wir einen Anhaltspunkt haben. Zwischenzeitlich sind Ideen sehr gefragt - falls jemand noch einen Anhaltspunkt hat. Diese Warnung spuckt unser Server aus: [31-Jul-2017 19:01:57 Europe/Zurich] PHP Warning: Division by zero in /var/www/webroot/ROOT/tools/tcpdf/tcpdf.php on line 22982 Und das sind noch ein paar Notic die uns auch sagen wollen, dass irgendwas noch nicht so toll ist: [31-Jul-2017 19:01:57 Europe/Zurich] PHP Notice: Undefined index: cols in /var/www/webroot/ROOT/tools/tcpdf/tcpdf.php on line 22984 [31-Jul-2017 19:03:31 Europe/Zurich] PHP Notice: Undefined offset: 0 in /var/www/webroot/ROOT/cache/smarty/compile/e5/bf/8b/e5bf8b195cad83638ec31699c7760c48ae82d9c3.file.order-carrier.tpl.php on line 327 Herzlicher Gruss und merci Link to comment Share on other sites More sharing options...
frezzo Posted July 31, 2017 Share Posted July 31, 2017 Das scheint korrekt, bei uns sowohl mit 1.6.1.13 als auch 1.6.1.15. @RIC Kannst Du mir mal die Dateiversion bei Dir benennen - cirka Zeile 15? ./tools/smarty/Smarty.class.php Wir haben da 3.1.19 drinn mit einer Dateigrösse von 48428 Bytes. Wir übrigens auch 3.1.19. Link to comment Share on other sites More sharing options...
Scully Posted July 31, 2017 Share Posted July 31, 2017 (edited) @frezzo Die Meldungen kannst Du in diesem Zusammenhang vergessen. tcpdf.php wirft noch so manche Warnmeldung aus. Ist leider immer so - bei jeder Installation. Das hängt aber nicht mit Deinem Problem zusammen. Diese Meldungen wie oben entstehen in Zusammenhang mit PDF-Erstellung. Mein ziemlich fester Eindruck bei Deinem Problem ist, dass es in der Datenbank heftigere Inkonsistenzen gibt. Oft passiert das, wenn man erst ein Test-Setup hat und nach einer Weile testen vermentlich die Testdaten löscht, aber nicht alle relevanten Tabellen dabei berücksichtigt werden. Fragen darum an Dich: - Habt Ihr den Shop kürzlich in Betrieb genommen oder einen grösseren Update gemacht - Hattet Ihr denn Testbestellungen gemacht vor Inbetriebnahme des Shops bzw. nach dem Update? - Wenn ja: Wie habt Ihr diese Daten gelöscht? Edited July 31, 2017 by Scully (see edit history) Link to comment Share on other sites More sharing options...
rictools Posted July 31, 2017 Share Posted July 31, 2017 Mein ziemlich fester Eindruck bei Deinem Problem ist, dass es in der Datenbank heftigere Inkonsistenzen gibt. ... einen grösseren Update gemacht Er hat doch geschrieben, daß er NUR die Datenbank von 1.6.1.1 auf 1.6.1.15 upgedatet hat (frage mich jetzt nicht wie ...) und dann einzelne Tabellen hineinkopiert hat. Egal wie, meiner Meinung nach ist das eine Bastelei, die nur im totalen Chaos enden kann, da sind evtl. Tabellen drin, die es in 1.6.1.15 gibt, in der aber immer noch laufenden alten Shopversion 1.6.1.1 jedoch nicht oder umgekehrt und das Einfügen einzelner Tabellen, wenn man nicht ganz, ganz, ganz genau die Abhängigkeiten kennt, führt auch fast zwangsläufig zu Fehlern und eben den "heftigen Inkonsistenzen". Wenn er jetzt noch lange dran rumbastelt, wird das wahrscheinlich immer schlimmer. Frage wäre, gibt es Sicherungen, aus denen man den Ursprungszustand vor den Änderungen wiederherstellen kann? Ansonsten kann man wohl nur den Shop auch auf 1.6.1.15 updaten und / oder die dritte Option des Prestashop Cleaners probieren. Link to comment Share on other sites More sharing options...
frezzo Posted July 31, 2017 Share Posted July 31, 2017 Hey Scully Wir sind immer noch am debuggen - haben aber Anhang der Produkte, die immer wieder Wild erscheinen festgestellt, dass sich diese nur ohne Bild clonen lassen - folgendes wird beim clonen ausgespuckt: Unkown column in the 'hover' in the 'field list' INSERT INTO `ps_image` (`id_product`, `position`, `cover`, `hover`) VALUES ('16817', '3', NULL, '0') Aber die Tabelle hover habe ich gar nicht in der tabelle image. Wir haben jetzt jetzt die PHP Version 5.6.3 redeployed -- statt vorher die 7.0.13. Zu deinen Fragen: - Habt Ihr den Shop kürzlich in Betrieb genommen oder einen grösseren Update gemacht wie du zu recht vermutest haben wir uns an ein gewagtes Projekt gemacht - und zwar 1.6.1.1 auf 1.6.1.15 zu upgraden - da aber so viele Individuelle Programmierungen an Shop stattgefunden haben - und es an allen enden und ecken gekracht hätte nach einem "normalen" Upgrade - haben wir eine Instanz aufgesetzt mit einem neuen Theme - dieses soweit vorbereitet und zu guter letzt mit den wichtigsten Db-Tables wieder bespiesen. - Hattet Ihr denn Testbestellungen gemacht vor Inbetriebnahme des Shops bzw. nach dem Update? Sogar ausgibig getestet - allerdings in der DEV Stage ohne Cache/MemChache - Wenn ja: Wie habt Ihr diese Daten gelöscht? Daten wurden mit dem Prestashop Manager eMagic Store "bereinigt" und ein DB Cleaner Database Optimization v1.3.1 - von MyPresta.eu eingesetzt, Ich halte euch auf dem Laufenden - vielleicht hilft das ja weiter falls jemand ebenfalls auf diesen Fehler stösst. Link to comment Share on other sites More sharing options...
frezzo Posted July 31, 2017 Share Posted July 31, 2017 Hey ric Wenn er jetzt noch lange dran rumbastelt, wird das wahrscheinlich immer schlimmer. Frage wäre, gibt es Sicherungen, aus denen man den Ursprungszustand vor den Änderungen wiederherstellen kann? Ansonsten kann man wohl nur den Shop auch auf 1.6.1.15 updaten und / oder die dritte Option des Prestashop Cleaners probieren. Natürlich gibt es Backups -> mit nur den Shop auf 1.6.1.15 haben wir uns vor einem halben Jahr schon die Zähne ausgebissen - da zu viele Indivs reinprogrammiert wurden und zu wenig auskommentiert bzw. dokumentiert wurde. Der Überblick ist damit dahin - daher war das nicht die Variante die ich gehen konnte. Auf jeden Fall ist die heisse Spur mit den Artikeln, die sich da einfach so in den Cart schleichen hoffentlich gefunden mit dem Datatable image. Jetzt ist nur noch die Frage was da schief ist. Ich hoffe wahrlich nicht das wir das ein Rollback machen müssen. Bis jetzt scheint sich kein Artikel mehr in den Warenkorb zu schleichen. Fragt sich nur wie lange. Grüsse und Danke für die Inputs. Link to comment Share on other sites More sharing options...
Scully Posted July 31, 2017 Share Posted July 31, 2017 (edited) Sorry, ich hab kurzzeitig den Überblick verloren, da wir hier ja zwei Patienten in Betreung haben. Meine Aussage gilt indes unverändert. Eurer Update ist schief gelaufen mit dem Tabellen hin- und herkopieren. Jetzt hängen in verschiedenen Tabellen Produkte aus früheren Bestellungen drin, die mit fröhlich mit neuen Bestellungen durch den Mixer gehen. Jenachdem wie gross diese Tabellen sind, kann der Spuk morgen vorbei sein oder aber auch erst in 3 Monaten oder 2 Jahren. @Frezzo Ich würde hier eher bald aufräumen als erst später - das Chaos wird potentiell nur noch grösser. PN an mich - wenn wir uns darum kümmern sollen. Und ja, das kostet dann etwas. Und zu diesem Fehler da: INSERT INTO `ps_image` (`id_product`, `position`, `cover`, `hover`) VALUES ('16817', '3', NULL, '0') Eine Spalte hover gibt es bei PrestaShop normal wirklich nicht. D.h. evtl. läuft hier irgendwo noch ein Override eines Modules mit, welches eine Spalte anspricht, die es bei Dir nicht mehr gibt. Man könnte "auf gut Glück" nun einfach eine Spalte anfügen. Aber wenn man nicht weiss wozu das Feld ist, ist es eben auch nicht so gut. Was man aber so gut wie sicher sagen kann: dieser Fehler hat kaum einen Zusammenhang mit dem Produkte-Mix im Cart. Abklären sollte man den aber schon auch. Edited July 31, 2017 by Scully (see edit history) Link to comment Share on other sites More sharing options...
Scully Posted July 31, 2017 Share Posted July 31, 2017 Vielleicht hier noch - weil passend - ein paar Tipps zum Unterhalt: - Änderungen immer im Header dokumentieren. Wann, Wer, Was - Änderungen an php files in override ablegen. Ja, das macht ein wenig mehr Arbeit zu Beginn, und spart am Ende trotzdem viel Arbeit. - Änderungen gesammelt in einem Change Management Tool dokumentieren. Wer keines hat nimmt dafür Excel. - Vor Updates die Seite Voreinstellung - > Konfiguration prüfen - Da bekommt man frei Haus eine Liste geänderter Datein. Und damit lässt sich auch noch passabel arbeiten, wenn man die Dokumentation vorher nicht gemacht hat. Link to comment Share on other sites More sharing options...
frezzo Posted August 1, 2017 Share Posted August 1, 2017 (edited) Vielen Dank @scully - ich melde mich per PN. Das Problem ist soeben nicht mehr existent - die Frage ist ob das Produkte löschen irgendetwas bewirkt hat. Aber es ist sinnvoll wenn noch jemand anderst in der DB nach Inkonsistenzen sucht. Edited August 1, 2017 by frezzo (see edit history) Link to comment Share on other sites More sharing options...
Scully Posted August 1, 2017 Share Posted August 1, 2017 (edited) Produkte löschen über das Backoffice - Katalog - Produkte hat keine "heilenden" Kräfte in Bezug auf historische Aufträge oder Inkonsistenzen in der Datenbank. Warum? Sobald Produkte in den Warenkorb geklickt werden, erzeugt das System in entsprechenden Tabellen des Warenkorbs eine Art "Kinder dieser Produkte". Sobald aus einem Warenkorb ein Auftrag erstellt wird, werden wiederum eine Art "Kinder" dieser Produkte in einer bestellbezogenen Tabelle gespeichert. Das muss zwingend darum so sein, damit ich nicht auf einmal Bestelldaten verliere, nur weil ich ein paar Produkte aus meinem Katalog lösche. Wenn ich das tue, dann möchte ich aus vielerlei Gründen auch noch später sehen, wer diese gelöschten Produkte einst einmal kaufte. Der Rest dann per PN. Viele Grüsse. Edited August 1, 2017 by Scully (see edit history) Link to comment Share on other sites More sharing options...
frezzo Posted August 2, 2017 Share Posted August 2, 2017 Falls jemand mit dem selben Problem konfrontiert ist - und auch Advanced Pack 5 Modul installiert hat - versucht mal dieses zu deaktiveren - dann zu deinstallieren. Wir glauben, dass dieses Pack Modul uns einen Streich gespielt hat. Werden aber, sobald wir mal wieder dazu kommen das Modul nochmals austesten und berichten, ob das Phänomen wieder auftaucht. Grüsse, Tonino Link to comment Share on other sites More sharing options...
rictools Posted August 2, 2017 Share Posted August 2, 2017 Kam denn der Fehler zwischenzeitlich wieder? Nachdem du wohl nicht sehr kenntnisreich in der Datenbank gewerkelt hast, halte ich es ohne weitere Erläuterungen, ob denn das Deaktivieren und / oder Deinstallieren des Moduls etwas bewirkt hat doch für etwas abenteuerlich ein Modul verantwortlich zu machen. Link to comment Share on other sites More sharing options...
Scully Posted August 2, 2017 Share Posted August 2, 2017 Spannendes Kino hier - ich habe aber auch noch Zeifel, ob das genannte Module so ein durcheinander zu machen in der Lage ist. @Frezzo: berichte weiter, was Deine/Eure Erkenntnisse sind. Link to comment Share on other sites More sharing options...
frezzo Posted August 2, 2017 Share Posted August 2, 2017 Hey Leute So - jetzt aber --> ihr habt beide Recht. Die Module waren nicht für das Chaos verantwortlich - sondern mit dem DB Cleaner haben wir vor Livegang die Datenbank "tunen" wollen - und dabei die unwanted Carts gelöscht. Was nun passierte ... Er hat neue id_carts angelegt in der DB ps_cart - also von 1 begonnen. Die Datenbank ps_cart_cart_rule und die DB cart_product hatten aber noch die "alten" Carts drinn. Jetzt habe ich den einen neuen Cart in den 3 erwänten Tabellen manuell angelegt und diesen Warenkorb dann über BO - Warenkörbe - entsprechender Warenkorb (natürlich mit einem Wert über den in den anderen Tabellen vorhandenen...) und die Bestellung abgeschlossen. Dadurch werden jetzt die Warenkörbe ab dem neu gesetzten Wert (auto_increment) angelegt. Nun sollte die Sache hoffentlich vom Tisch sein - denn die Carts werden fortan neu in die Tabelle geschrieben. Ohja - es ist wirklich abenteuerlich. Was mich am meisten stresst ist, dass wir (dadurch natürlich aus unserer alten Version schon ca. 200 Testbestellungen bereinigt wurden - dass der Fehler natürlich erst im Live Betrieb überhaupt vorgekommen ist, da ja die Testbestellungen schonmal bereinigt wurden. Jetzt habe ich noch eine Weile die Warenkörbe im Auge (bin aber zuversichtlich damit das Problem behoben zu haben). Merci für die Inputs und eure Mühe. Link to comment Share on other sites More sharing options...
Scully Posted August 2, 2017 Share Posted August 2, 2017 (edited) @Frezzo, Das was hier hier lese, hört sich erstmals recht plausibel und nachvollziehbar an - mit einer kleinen Ausnahme, die ich anmerken möchte. PS Cleaner löscht unserer langen Beobachtung und Nutzung gemäss alle Daten korrekt. Hier noch ein Auszug, wo PS Cleaner mit Cart-bezogenen Tabellen arbeitet: // 0 => DELETE FROM __table__, 1 => WHERE __id__ NOT IN, 2 => NOT IN __table__, 3 => __id__ used in the "NOT IN" table, 4 => module_name array('cart_cart_rule', 'id_cart', 'cart', 'id_cart'), array('cart_product', 'id_cart', 'cart', 'id_cart'), array('cart_rule_carrier', 'id_cart_rule', 'cart_rule', 'id_cart_rule'), array('cart_rule_carrier', 'id_carrier', 'carrier', 'id_carrier'), array('cart_rule_combination', 'id_cart_rule_1', 'cart_rule', 'id_cart_rule'), array('cart_rule_combination', 'id_cart_rule_2', 'cart_rule', 'id_cart_rule'), array('cart_rule_country', 'id_cart_rule', 'cart_rule', 'id_cart_rule'), array('cart_rule_country', 'id_country', 'country', 'id_country'), array('cart_rule_group', 'id_cart_rule', 'cart_rule', 'id_cart_rule'), array('cart_rule_group', 'id_group', 'group', 'id_group'), array('cart_rule_product_rule_group', 'id_cart_rule', 'cart_rule', 'id_cart_rule'), array('cart_rule_product_rule', 'id_product_rule_group', 'cart_rule_product_rule_group', 'id_product_rule_group'), array('cart_rule_product_rule_value', 'id_product_rule', 'cart_rule_product_rule', 'id_product_rule'), Auto Increment Werte werden unter Umständen wieder auf 1 gesetzt, ABER NUR DANN wenn es in der jeweiligen Tabelle keine Einträge mehr hat. Will heissen: Das Modul arbeitet unserer Erfahrung nach insofern absolut fehlerfrei, als dass es Datenleichen korrekt beseitigt. Duplikate irgendwelcher Einträge kann es jedoch nicht erfassen, ebenso wenig falsche Daten wiederherstellen. Edited August 2, 2017 by Scully (see edit history) Link to comment Share on other sites More sharing options...
Scully Posted August 2, 2017 Share Posted August 2, 2017 Bleibt noch das System für ein paar Tage aufmerksam beobachten. Wenn das Problem bei den nächsten 10 Bestellungen nicht mehr zu Tage tritt, dann ist das Problem wohl vom Tisch. Weisst Du, wieviele Aufträge von dem Problem bei Euch tatsächlich betroffen waren? Link to comment Share on other sites More sharing options...
frezzo Posted August 2, 2017 Share Posted August 2, 2017 (edited) Hey Scully Die Schuld wollte ich gar nicht auf den DB Cleaner schieben - es kann durchaus sein, dass wir beim Import von den Tabellen etwas übersehen haben und darum die Funktion gestört haben. Gerne werde ich Eure Dienste für ein DB Checkup in Anspruch nehmen - bezahlt versteht sich. Es wäre ja schon gut - wenn die Inkonsistenzen vom Profi ermittelt werden - und nicht ganz so "unerfahren", wie ich es "tun musste". Grüsse und gute Nacht. Edited August 2, 2017 by frezzo (see edit history) Link to comment Share on other sites More sharing options...
Scully Posted August 2, 2017 Share Posted August 2, 2017 Hab ich auch nicht so aufgefasst. Alles gut Wir schauen demnächst mal in Eure Datenbank und danach sind wir auch sicher, dass alles wieder gut ist. Gute Nacht. Link to comment Share on other sites More sharing options...
Scully Posted August 3, 2017 Share Posted August 3, 2017 Wir haben inzwischen ein erstes Auge auf die Datenbank von Frezzo geworfen. Er hat zuvor den Auto-Increment der Tabelle cart auf einen hohen Wert gesetzt. Das ist ein durchaus pragmatischer Ansatz, um Überschneidungen von Carts zu verhindern, nachdem es zuvor ein wenig "gerumpelt" hat. Dennoch gibt es weitere ausstehende Bereinigungen von Datenleichen. Derzeit sind wird bei ca. 5500 Datensätzen, haben aber noch nicht alle Tabellen geprüft. Link to comment Share on other sites More sharing options...
Scully Posted August 4, 2017 Share Posted August 4, 2017 (edited) Für diejenigen die hier mitgelesen haben ein vorläufiges Fazit bezüglich den Problemen von Frezzo. Hier noch ein Update dazu: 1. Wir haben eine komplette Test-Neuinstallation von PS 1.6.1.15 auf einer Testinstanz aufgesetzt und relevante Parameter so konfiguriert, wie sie den Ursprungssystem entsprechen. Aus Zeitgründen konnten wir indes nicht alle Module und Settings 1:1 übernehmen sondern haben uns darauf konzentriert, die für das vorliegende Problem relevanten Rahmenbedingungen so zu duplizieren, dass wir uns damit möglichst nahe an der Produktion befinden. 2. In das Testsystem haben wir alle Daten vom problembehafteten System importiert, den PS Cleaner sowie eigene Korrektur - und Check- Programme drüber laufen lassen. In einem ersten Schritt "read-only", in einem zweiten Schritt haben wir diese Testinstanz dann auch effektiv bereinigt und getestet. Es wurden insgesamt rund 60'000 Datensätze gelöscht oder korrigiert. 3. Die Probleme hatten ihren Ursprung in der Tabelle cart, genauer im Auto Increment dieser Tabelle, welcher auch nicht rekonstruierbaren Gründen zurückgesetzt wurde. Auf jeden Fall wurden neue Carts angelegt, welche mit unter Umständen bereits bestehenden Cart IDs korrelieren konnten. Dadruch wurden neue Bestellungen mit Artikeln vermischt, für welche es bereits existierende Warenkörbe gab. 4. Das produktie System werden wir erst morgen Abend bereinigen. Wir rechnen mit einer Stunde Offline - Time. 5. Sodann haben wir festgestellt, dass die Datenbanktabellen scheinbar zufällig sowohl unter MyISAM als auch InnoDB konfiguriert sind. Das ist wohl beim kopieren von Daten so entstanden, jedoch weniger optimal. Jede Engine reserviert für sich Speicherbereiche und ein optimales Query Caching kann dadurch nicht stattfinden. Auch sind Tabellen mit unterschiedlichen Zeichensätzen definiert. Wir haben frezzo empfohlen, auch diese Dinge zu bereinigen. Um das Risiko für die Produktion klein zu halten, werden wir das jedoch morgen nicht auch noch in Angriff nehmen. Dafür wäre auch das Zeitfenster zu knapp bemessen. Edited August 4, 2017 by Scully (see edit history) Link to comment Share on other sites More sharing options...
rictools Posted August 4, 2017 Share Posted August 4, 2017 (edited) Ich hatte jetzt auch so ein Problem, auf einmal tauchten Produkte im Warenkorb auf, die da nicht reingelegt worden waren. Kurz davor hatte ich mit dem Modul "Database Optimization" von MyPresta u. a. "unwanted carts" "gecleant", ob das jetzt die alleinige Ursache war (vielleicht durch ein TimeOut?) weiß ich nicht, jedenfalls habe ich die Reparaturfunktion des nativen Moduls "Prestashop Cleaner" laufen lassen und bis jetzt scheint wieder alles zu stimmen. Edited August 4, 2017 by rictools (see edit history) Link to comment Share on other sites More sharing options...
Scully Posted August 4, 2017 Share Posted August 4, 2017 (edited) Ich kenne das angesprochene Modul nicht. Generell kann man aber die gesamte ps_carts löschen, wenn es einem beliebt. Dann den PS Cleaner laufen lassen mit der dritten Option und alles ist ok. Man verliert dadurch natürlich auch von Kunden angelegete Warenkörbe. Was gar nicht gut ist, wäre nur ps_cart löschen. Dann bleiben die Produkte in ps_cart_product noch vorhanden und wenn der Auto Increment von ps_cart auf 1 steht, dann kommt es wieder zum "Mixer-Effekt". Edited August 4, 2017 by Scully (see edit history) Link to comment Share on other sites More sharing options...
frezzo Posted August 4, 2017 Share Posted August 4, 2017 Hi ihr zwei Genau das besagte Tool haben wir kurz vor Livegang noch gestartet und danach scheinbar zu wenig lange getestet. Denn die ersten Warenkörbe waren noch clean. Ich glaube wenn wir dass erneut reproduzieren dürfte darin der Ursprung liegen... Bei uns wäre das "Drama und die Mixerei, wie scully so schön sagt, noch eine ganze Weile so weiter gegangen. Jetzt hoffen wir mit dem restlichen bereinigen dann auch Ruhe zu haben. Scully versteht zum Glück sein Handwerk . Link to comment Share on other sites More sharing options...
Scully Posted August 4, 2017 Share Posted August 4, 2017 (edited) Das wäre nun mal ein Anhaltspunkt für ein neues "Forschungsprojekt" - ich habe da schon so eine Liste mit etwa 150 Dingen, die wir noch erkunden wollen. Das Optimization Module scheint hier in den Fokus zu kommen. Generell gilt für MySQL Tabellen in Zusammenhang mit Auto Increment folgendes: delete from table ... tangiert den Auto Increment NICHT. Nie, niemals, egal ob ich einen Datensatz oder alle lösche. truncate table ... setzt den Auto Increment zurück! Daraus folgt, dass es eigentlich kein Modul geben dürfte, welches den truncate Befehl nutzt, es sei denn, ausnahmslos alle verknüpften Tabellen werden ebenso mit truncate behandelt. Dann wären einfach alle Tabellen komplett leer und die ID beginnt wieder bei 1. truncate jedoch nur auf eine Tabelle anzuwenden, wäre deswegen fatal, weil die Haupttabelle dann fröhlich bei ID 1 beginnt, die Kinder-Tabellen aber durchaus noch Datensätze mit ID2, 3, 4, 5 haben können. @frezzo - wenn Ihr nun Database Optimization und NICHT PS Cleaner habt laufen lassen, erklärt das auch, weshalb der Cleaner noch immer viele Inkonsistenzen findet. Das war mir bislang so noch völlig unklar. Ein paar Datensätze hätten mich nun auch nicht gewundert, da dazwischen noch Zeit verstrichen ist, aber zehntausende dann schon. Damit wäre das nun auch schlüssig nachvollziehbar. Edited August 4, 2017 by Scully (see edit history) Link to comment Share on other sites More sharing options...
Scully Posted August 4, 2017 Share Posted August 4, 2017 (edited) Und es ist auch nachvollziehbar, weshalb die ersten Testbestellungen noch sauber durchgelaufen waren. Die cart_product tabelle hatte nämlich in den ersten IDs keine Datensätze drin. Diese sind wohl ganz zu Anfang bei der ersten Inbetriebnahme des Shops gelöscht worden - was häufig der Fall ist. Deshalb waren erste Testbestellungen noch sauber. Zum Konflikt ist es erst gekommen, als id_cart einen Bereich erreichte, bei welchem tatsächlich Datensätze mit alten Produkten wieder vorhanden waren. Edited August 4, 2017 by Scully (see edit history) Link to comment Share on other sites More sharing options...
Scully Posted August 5, 2017 Share Posted August 5, 2017 Wir haben heute ja bei Frezzo mit dem "grossen Besen" in der Datenbank aufgeräumt. Um 17h00 haben wir den Shop in Wartung gesetzt und um 17h50 wieder online genommen. Es sei auch nicht verschwiegen, dass im Rahmen der Bereinigung Zuordnungen von Warenlagern zu Versanddiensten verloren gegangen sind. Frezzo erstellt diese Zuweisungen nun manuell. Was genau die Ursache hierfür war, werde ich wohl am Montag mit einem Blick in die Logfiles noch zu klären versuchen. 1 Link to comment Share on other sites More sharing options...
frezzo Posted August 5, 2017 Share Posted August 5, 2017 Danke an dieser Stelle an alle Beteiligen - ja vorallem an Scully für die professionelle Arbeit und das Nachbessern. Mit meinem Eingreifen hatten ja nur das Problem ja quasi nur übersprungen - jetzt sollte der unnötige Balast seit heute ja auch noch gecleant worden sein. Zumindest habe ich nun ein besseres Gefühl. Die Versanddienste (Advanced Stock Management) wurden unter der Lagerorten (teils Lager hatten keine Versanddienste mehr nach der Bereinigung zugewiesen) wieder zugewiesen und somit konnten auch ein paar Testbestellungen abgewickelt werden. Danke und weiterhin schönes Wochenende 2 Link to comment Share on other sites More sharing options...
Scully Posted August 8, 2017 Share Posted August 8, 2017 (edited) Hier noch die Kurzanalyse, weshalb einige Warenlager - Versanddienste - Zordnungen weg waren. Wir haben erst mal diese Löschung an die Datenbank gegeben: DELETE FROM `ps_carrier` WHERE id_carrier not IN (select id_carrier from pstest_orders) AND deleted = 1 und meinten, da damit clever zu sein. Also nur die Versanddienste entfernen, die noch in keinem Auftrag jemals Anwendung gefunden haben und auch nur jene, welche das Gelöscht-Flag (deleted = 1) gesetzt hatten. Dann kam der PS Cleaner zum Einsatz und hat die eigentlichen Zordnungen gelöscht. Das aber auch nur, weil die Carriers nicht vorhanden waren: DELETE FROM `ps_warehouse_carrier` WHERE `id_carrier` NOT IN (SELECT `id_carrier` FROM `ps_carrier`) 25 line(s) Damit waren dann die Zordnungen weg. Die Analyse ergab, dass PrestaShop Carriers führt die sowohl deleted = 1 als auch active = 1 gesetzt hatten. Und ja, das kommt in Default PrestaShop so vor. Der Sinn muss sich einem nicht erschliessen, weshalb ein Versanddienst gleichzeitig die Flags aktiv und gelöscht gesetzt hat. Wir haben unsere Korrekturprogramme entsprechend angepasst und prüfen neu sowohl deleted als auch active. Was leider unbeantwortet bleibt ist die Frage, weshalb dieser Schutzmechanismus nicht gegriffen hat.... DELETE FROM .... WHERE id_carrier not IN (select id_carrier from ps_orders) Edited August 8, 2017 by Scully (see edit history) Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now