Jump to content

Produkt Edit endet mit Fehler 500


Recommended Posts

Liebe Community

wir haben ein Problem und suchen eine Lösung.

Wir haben den Storemanager und spielen hierrüber unsere CSV Bestände ein alles klappt auch.
Server ist mit Debian 9, NGNIX und Galera MYSQL Cluster

wenn wir nun ein Produkt erstellen möchten erhalten wir einen Fehlermeldung 500 Server Broken
alles andere Funktioniert Die Tabellen sind auch ok kein defekt.

Ich muss sagen das die Meldung erst passierte nachdem ich einen weitere CSV mit 10000 Artikel eingespielt habe.
Memory Limit liegt bei 2G

in de Logs steht das , der SQl Server ist aber Online und Redundant

Quote

PHP message: PHP Warning: PDOStatement::execute(): MySQL server has gone away

 

Link to comment
Share on other sites

Tut mir leid, aber da solltet ihr euch doch lieber direkt an den Service des Storemanagers wenden. Das ist nun mal ein separates Unternehmen, das mit PrestaShop nichts zu tun hat. Übrigens, falls ihr PrestaShop 1.7 einsetzt, da gibt es wohl Probleme mit dem Storemanager.

Näheres zum Troubleshooting bei dieser Fehlermeldung hier: https://matomo.org/faq/troubleshooting/faq_183/

Link to comment
Share on other sites

Ok vielen Dank ich kann die Edit Funktion nun wieder nutzen aber die brauch ewig zum aufmachen gibt es hier vielleicht noch ein paar Einstellungstipps
wir haben fast 85000 Artikel mit Bilder PDF Anhänge ist der shop über 30 GB groß

 

Link to comment
Share on other sites

Ich blicke hier überhaupt nicht durch, erst sprichst du von "Product Edit", dann von "Produkt erstellen" (das sind ja zwei verschiedene Sachen, bei einem Editieren existiert das Produkt ja bereits), dann wiederum über einen Import, mal vom Storemanager, dann von Prestashop direkt ...

Link to comment
Share on other sites

Es ist egal ob ich einen neuen Artikel über Prestashop anlegen will, oder einen bereits angelegten Artikel bearbeiten will ich erhalte dann die 500 Meldung.
und ich weis aktuelle nicht warum die Werte sind angepasst

 

Wenn ich den Debug Modus einschalte und er mal die Seite aufgemacht hat steht unten
An error occurred while loading the web debug toolbar.    wenn ich das anklicke kommt das Token "1a5cfc" was not found in the database.

Edited by tenga (see edit history)
Link to comment
Share on other sites

vor 3 Stunden schrieb tenga:

Version 1.7.4.3

der Edit dauert bis zu 2 Minuten pro Artikel im Frontend geht alles flott, kann es an den vielen Kategorien liegen sind ja über 5200

Das hättest du am besten gleich erwähnen sollen. Solche Fehler sind bei 1.7.4.3 bekannt. Problematisch an der Sache ist nur, dass man sich ja bei einer Entwicklerversion wie 1.7 im Grunde von Bugfix zu Bugfix schleppt. Im Falle 1.7.4.3 wären das Bugs beim Änderrn oder Anlegen von Artikeln (Mehrsprachigkeit, Eigenschaften), beim Smarty-Cache, beim Modul-Upload etc.

Es gibt vermutlich wenig Vergleichswerte, da größere Shops derzeit wohl auch kaum 1.7 nutzen würden wegen der Fehleranfälligkeit. 1.7 dürfte wegen der zahllosen Dateien und Abhängigkeiten bei größerem Datenvolumen im Backend noch schwerfälliger als 1.6 sein. Deswegen läuft es mit annehmbarer Geschwindigkeit wohl auch nur in der Minimalausstattung einigermaßen flott, jedes neue Modul kann eines zuviel sein.

Ich hoffe, ihr habt als erstes das Modul Handelserfolg deinstalliert. Manchmal hilft es sogar schon, die Option Benutzerfreundliche URLs einmal anzuschalten, zu speichern und wieder abzuschalten. Es kann aber auch daran liegen, dass die

app/config/parameters.yml

nicht aktuell ist. Die aktuelle ist immer im Sourcecode bei Github zu finden.

Der langen Rede kurzer Sinn: Das ganze Forum ist mittlerweile voller Problemschilderungen zu den verschiedenen Versionen von 1.7 - da aber leider auch nach über 2 Jahren Entwicklungszeit zu wenig praktische Erfahrungen vorliegen und der überwiegende Teil der User 1.6 oder ältere Versionen einsetzt, gibt es längst nicht immer eine brauchbare Lösung.

vor einer Stunde schrieb tenga:

Token "1a5cfc" was not found in the database.

Dieser Fehler dürfte in den oben genannten Bereich Mehrsprachigkeit fallen. Hier speichert PrestaShop 1.7.4.3 nicht korrekt. Wie ist denn der aktuelle Wert der max_execution_time  in der php.ini?

Link to comment
Share on other sites

Ja, die wird wegen der Probleme bei 1.7 noch bis mindestens Mitte nächsten Jahres weiter gepflegt und upgedated. Ein Downgrade ist allerdings nur was für Spezialisten, denn das ist wegen der großen Unterschiede eigentlich nicht möglich. Man sollte besser mit einer sauberen Neuinstallation anfangen.

Link to comment
Share on other sites

Lustig ist es nur Identische Installation auf dem Testserver  einfach alles ist gleich, Import ist auf die selbe weise erfolgt.
Hier läuft auch alles super, und geht auch alles recht flott auf . Ich suche mal weiter

Link to comment
Share on other sites

Evtl. kann nachfolgende Info weiterhelfen, da hier im Forum meist von 1.7x abgeraten wird, als Lösung aller Probleme.

Auf alte PHP Versionen zu setzen ist auch keine Lösung.

Nachdem unser im Sommer neu aufgesetzer 1.733 Shop mit PHP 7.1, im Backend aus unerklärlichen Gründen teilweise nicht mehr zu erreichen war, samt Fehler 500, und was alles noch schräg laufen konnte, musste ich nach diversen Testläufen feststellen, dass die Probleme scheinbar bei den Modulen und im Cachebereich liegen .

Mann sucht sich einen Wolf, wenn der Shop ohne Änderung plötzlich einbricht und fragt sich ob das wirklich das richtige Produkt ist.

Was wirklich unter 1.733 geholfen hat

per ftp /app/cache zu löschen

alle Module die eine aktualisierung benötigten zu aktualisieren

1 modul zu deaktiveren was man nicht für notwendig findet (es ging nur darum den Prozess zu starten)

Plötzlich liefen alle Installationen auf den unterschiedlichsten Servern oder Hosting Packeten auf denen getestest wurde wieder wie am ersten Tag,

obwohl der Fehler 500 eigentlich was anderes  andeutete.

Nachdem dies gelungen war, gleich den Shop auf 1.744 angehoben und die php anschliessend auf 7.2 gesetzt

 

Link to comment
Share on other sites

der Fehler bedeutet eigentlich das sich der MYSQL Server verabschiedet weil zuviele Queries geladen werden beim editiern von Produkten oder beim erstellen.
Es kann aber daran liegen da wir eine lange Liste an Anhängen haben die man Downloaden kann .pdf liestet er alle Anhänge mit auf und wir haben 50000 drin.
Obwohl pro Produkt nur 1 max 2 Anhänge verknüft sind.

Manchmal klappt das Editieren mal nicht je nachdem wieviel Last drauf ist. Es dauert aber mind. 60 Sek.

Link to comment
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...