aktuelles Update 2.0.7.0 - Fragen dazu

[Scubi]

Ja, seit dem 18.5.2022 (Tag der Installation) gibt es 40 log Dateien. mod_warning und mod_warning_admin teilen sich ca. gleich auf.
Werde ich mich dann heute Abend mal an die Auswertung begeben.

[Timm]

Einfacher ist es du löschst die von heute, versuchst nochmal zu speichern im Backend und schaust dann, was neu an Fehlermeldungen hinzugekommen ist. Sonst suchst du doch die Nadel im Heuhaufen.

Gruß Timm

[Scubi]

Habe gerade alle Logs gelöscht und  unter Zusatzmodule die beiden Dinge verändert:
Aber es wird keine log Datei geschrieben.

[bit4ber]

Habe vor paar Tagen eine Neuinstallation gemacht. Alles neu auch Datenbank.
Allerdings versthe ich nicht was und wo PAYMENT.CAPTURE.COMPLETED sowie PAYMENT.CAPTURE.DENIED setzen?
Status Kauf auf Rechnung Sandbox: steht auf grün, geht aber nicht.

Da bin ich doch zu sehr Anfänger.

Gruß Bernd

[karsta.de]

Du musst in den Einstellungen des PayPal Moduls auf den letzten Reiter > PayPal Webhooks gehen, auf > Einfügen, dann die im Beitrag 1 angegebenen Status vergeben und speichern.

BG Karsta

[bit4ber]

Danke, ich denke so ist es richtig?!
Gruß Bernd

[karsta.de]

[...]Ich habe mal im Liveshop versucht Attribute zu speichern. Dort geht es auch nicht. Also liegt das Problem nicht am Update, sondern existiert schön länger. [...]

Da du in einem anderen Forumsbeitrag schriebst, dass du mindestens 40.000 Attribute verwendest (und deine IDs sicher schon mehr als 6 Stellen haben), musst du in der DB-Tabelle: products_attributes für die Spalte products_attributes_id den TYP von INT auf BIGINT setzen, dann sollte es auch wieder mit dem Speichern von Attributen im Backend deines Shops funktionieren.

BG Karsta

[noRiddle (revilonetz)]

INT geht bis 2147483647 (unsigned sogar bis 4294967295). Ich denke nicht, daß er BIGINT benötigt.
Ich denke, daß es eher ein Problem mit max_input_vars ist.
Zwar hat der Shop eine in Zusammenarbeit mit DJ-Ready, webn0null, web28 (R.I.P.) und meiner Wenigkeit vor längerer Zeit entwickelte Lösung eingebaut die beim Speichern im Backend die Zahl der zu speichernden Werte begrenzt auf die die aufgeklappt sind, wenn man jedoch beim Speichern zu viele aufgekplappt hat hat man dasselbe Problem wie vorher.

Ich würde mal den Wert für max_input_vars  erhöhen (erst mal bei Hilfsprogramme => Server Info  schauen wie er eingestellt ist) der wahrscheinlich auf irgendeinem Standard steht, 1000 oder so.
Hängt von der Server-Umgebung ab ob das via .htaccess geht, z.B.

Code: [Auswählen]

php_value max_input_vars 8000
oder über ein php.ini-File, z.B.

Code: [Auswählen]

max_input_vars = 8000
Wenn Suhosin läuft muß das evtl. dafür auch noch angepasst werden.
Ich würde also mal den Hoster kontaktieren was das Thema max_input_vars  betrifft.

Gruß,
noRiddle

[lullifatz]

musst du in der DB-Tabelle: products_attributes für die Spalte products_attributes_id den TYP von INT auf BIGINT setzen,

Damit funktioniert es wieder! Super Job! Vielen Dank!

Gruß Matthias

[noRiddle (revilonetz)]

Das kann eigentlich nicht sein.
Wie hoch ist denn die höchste products_attributes_id ?

Gruß,
noRiddle

[lullifatz]

Hallo,

dieser Satz:

Das kann eigentlich nicht sein.

lässt darauf schließen, dass Du es nicht weißt.   Ich kann Dir sagen: Es ist so.

Gruß Matthias

[noRiddle (revilonetz)]

Dann müsste deine höchste products_attributes_id  über 2.147.483.647 (in Worten über 2 Millarden...) sein. Das bezweifele ich.
Aber wer weiß, hab schon allen mögliche Unsinn in Datenbanken gesehen...

Gruß,
noRiddle

[Timm]

Moin

Geh mal in phpmyadmin in die DB-Tabelle products_attributes und sortiere für die Spalte products_attributes_id nach Größe und schreib hier mal die größte Zahl. (wie @noRiddle vorgeschlagen hat)

Da Karsta Zugriff auf deine DB hat wird sie schon wissen, warum sie dir das empfohlen hat. Aber bei 40.000 Attributen sollte int ausreichen, wenn die products_attributes_id aufsteigend ohne Lücken vergeben worden ist.  Vielleicht werden die Nummern unnötig länger durch den Wawi-Import. Das kann ein Außenstehender aber nicht wissen.

Gruß Timm

[GTB]

Wenn die Werte laufend neu gemacht werden ohne dass sich was ändert gehen die IDs nach oben, da die Werte gelöscht und neu eingetragen werden.

Gruß Gerhard

[noRiddle (revilonetz)]

Jau, aber um auf über 2 Millarden zu kommen mußt du schon was tun...
Außerdem sprach Karsta  von mehr als 6-stellig, was jedenfalls nicht BIGINT notwendig macht. (* korrigiert zu "mehr als..." *)

Gruß,
noRiddle