Jump to content
KM-Agentur

Shop fügt selbständig und willkürlich Produkte dem Warenkorb zu

Recommended Posts

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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 by KM-Agentur (see edit history)

Share this post


Link to post
Share on other sites

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. ;)

Share this post


Link to post
Share on other sites

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 ?!?

Share this post


Link to post
Share on other sites

Welche PS-Version?

 

Welche Module verwendet?

 

Welche Caches verwendet?

 

Werden sonst noch Fehler angezeigt beim aktivieren von "error-reporting"?

 

Ev url posten!

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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 by rictools (see edit history)

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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 ?

Share this post


Link to post
Share on other sites

Eventuell mal die Sache so angehen, dass im Debug-Mode mal die Overrides und Module weggeschaltet werden.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

 

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.

Share this post


Link to post
Share on other sites

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 ?!??

Share this post


Link to post
Share on other sites

Bei manchen Kunden eben schon, daß ist ja das verwunderliche....

Vielleicht hat es auch etwas mit den Kundengruppen zu tun ?!?

Edited by KM-Agentur (see edit history)

Share this post


Link to post
Share on other sites

Ahhh.. das ist doch schon einmal etwas ! Aber wie kann er im Cache suchen, wenn alle ausgeschaltet sind ?

Share this post


Link to post
Share on other sites

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 by Claudiocool (see edit history)
  • Like 1

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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 ...).

Share this post


Link to post
Share on other sites

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 by Scully (see edit history)

Share this post


Link to post
Share on other sites

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.

 

post-741527-0-91814600-1501509708_thumb.pngpost-741527-0-08003500-1501509719_thumb.png

 

PS 1.6.1.15

  • Like 1

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

 

attachicon.gifcache.pngattachicon.gifcompile.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.

Share this post


Link to post
Share on other sites

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.

  • Like 1

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

@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 by Scully (see edit history)

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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 by Scully (see edit history)

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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 by frezzo (see edit history)

Share this post


Link to post
Share on other sites

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 by Scully (see edit history)

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

@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 by Scully (see edit history)

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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 by frezzo (see edit history)

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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 by Scully (see edit history)

Share this post


Link to post
Share on other sites

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 by rictools (see edit history)

Share this post


Link to post
Share on other sites

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 by Scully (see edit history)

Share this post


Link to post
Share on other sites

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 :).

Share this post


Link to post
Share on other sites

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 by Scully (see edit history)

Share this post


Link to post
Share on other sites

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 by Scully (see edit history)

Share this post


Link to post
Share on other sites

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.

  • Like 1

Share this post


Link to post
Share on other sites

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

  • Like 2

Share this post


Link to post
Share on other sites

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 by Scully (see edit history)

Share this post


Link to post
Share on other sites

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 account

Sign in

Already have an account? Sign in here.

Sign In Now

×
×
  • Create New...

Important Information

Cookies ensure the smooth running of our services. Using these, you accept the use of cookies. Learn More