Kleinere Probleme nach Update in Admin- und Shopbereich forum

Zitat von: Bernny_H_ am Heute um 12:36:28 [...] [...] aber es sind für jedes Feld der Datenbank Eigene *.GZ Dateien. Also über 100... [...] [...] Du meinst sicher für jede Tabelle eine Datei, für jedes Feld in einer Tabelle kann nicht sein. Wobei über 100 Tabellen auch seltsam ist. Um dir zu helfen fehlen Informationen. Was genau heißt "SQL Database ... abgeschossen" ? Was vermutest du und was genau ist "abgeschossen" ? Da einer deiner Sätze nahelegt, daß du dich nicht in den Shop einloggen kannst, müsste man den Grund kennen. Blind eine Empfehlung zu geben welche DB-Tabellen du aus dem Backup wiederherstellen solltest wäre zu vage und kann zu weiteren Problemen führen. Gruß, noRiddle

Ich hatte mal angesprochen, daß, wenn die mod ified -API nicht erreichbar ist, es zu ERRORs und WARNINGs in den Logs kommt. Ich weiß leider nicht mehr was es genau betraf. Soweit ich weiß hat GTB das für die 3.3.1 gefixt. Nun habe ich dies in den Logs für eine selbst erstellte Scheduled Task /api/scheduled_tasks/modules/tax_eu_maintenance.php (Shop-Vs: 3.3.0): Code: [Auswählen] WARNING Could not reach external host: modified/tax/. Exit with Status: 0 in File: /includes/classes/modified_api.php on Line: 159 und als Folge Code: [Auswählen] ERROR Call to a member function add_session() on null in File: /admin/includes/modules/system/tax_eu.php on Line: 182 Wird das generell gelöst sein oder muß man das bei jedem Request an die mod ified -API abfangen ? Gruß, noRiddle

Hallo, Ich habe ein grösseres Problem. Ich habe die SQL Database in meinem Online-Shop abgeschossen. Das erstellte Backup war im Adminbereich Datensicherung. Da komm ich aber nun nicht ran. Die Datenbanksicherung kann ich zwar downloaden, aber es sind für jedes Feld der Datenbank Eigene *.GZ Dateien. Also über 100... Kann mir jemand sagen, welche den relevant sind, dass ich mich wieder mit meinem Account in das Backend einloggen kann? Wäre sehr dankbar. Grüsse Benno

Stimmt, An den Warenbestand hatte ich gar nicht gedacht. Bei mir ist es übrigens noch das alte modul paypalclasic und payment_rth_stripe deshalb vermute ich immer noch, dass es etwas mit langsamer Rückmeldung der server zu tun hat.

Vielen Dank, das hat nun soweit funktioniert, dass nur noch ein Eintrag angezeigt wird.

Hallo zusammen, wir haben seit einem Server-Neustart (nach starker Last / vermutetem DDoS) ein Problem mit PayPal Rechnung / Ratepay (paypalpui) und wollte fragen, ob das bekannt ist bzw. ob am Modul nachgebessert werden müsste. System / Versionen Shop: modified eCommerce Shopsoftware v3.3.0 rev 16825 (dated 2026-01-29, DB_VERSION MOD_3.3.0) Zahlungsmodul: paypalpui (PayPal Rechnung / Ratepay) PayPal-Modulstand (Dateien): paypalpui.php → $Id: … 16616 2025-11-04 … GTB PayPalPaymentV2.php → $Id: … 16679 2025-12-08 … GTB PayPalPaymentBase.php → $Id: … 16807 2026-01-26 … Tomcraft / Modulversion im Code 1.113 callback/paypal/webhook.php → $Id: … 16668 2025-12-04 … GTB Webhooks im Admin installiert, URL …/callback/paypal/webhook.php, u. a. Event PAYMENT.CAPTURE.COMPLETED PayPal-Update / Modulaktualisierung ca. 11.09.2026 – danach lief es erst noch normal Problem seit Server-Neustart / starker Last ca. 21.09.2026 Was passiert Bestellungen mit paypalpui kommen normal rein. In paypal_payment steht die payment_id (Order-ID), aber die transaction_id (Capture-ID) bleibt leer. send_order bleibt oft auf 1. Im Admin unter PayPal-Details sehe ich die Capture trotzdem als COMPLETED – die Daten holt das Modul offenbar live von PayPal. In der Datenbank fehlt die Capture-ID aber. Für uns ist das ärgerlich, weil wir die Capture-ID aus paypal_payment.transaction_id weiterverarbeiten. Ohne die Nummer greift unsere Nachverarbeitung nicht. Beispiel orders_id / Bestellnr. vorhanden paypal_payment.paym

Moin Naja es stört schon, wenn kein automatischer restock geschieht. Dann muss man die Bestände per Hand anpassen. Und je größer der Shop, desto öfter solch ein Fall. Aber es wurde ja heute bei Github dran gearbeitet und wird mit Paypal Modulversion 1.114 hoffentlich gefixed sein. Gruß Timm

Ich hab das auch manchmal beim neueren Stripes Modul. Ich dachte immer, das liegt an einer langsamen Rückmeldung der Server der Zahlungsdienstleister. Ist aber nur einige Male pro Woche, Mal bei PayPal Mal bei Stripe. Stört mich kaum.

Hallo liebes Forum, ich konnte mein Problem von gestern selbst lösen bzw. korrigieren. Code: PHP [Auswählen] ich habe ein Problem bei der Installation der "EU-Gewährleistung........" . Beim Installieren und anschließendem "Einbau prüfen" kommt eine Konflikt - Fehlermeldung mit der Datei - inc / xtc_remove_order . inc . php -. Problemlösung wie folgt: Ich habe eine ältere Shop-Sicherung mit dem Widerrufsformular V1.02 neu übertragen, so wie es von Elf-K11 auch schon beschrieben wurde. Dann konnte ich das Modul ohne Fehler problemlos im Shop V3.3.0 installieren. Nun meine Frage: Kann ich jetzt das aktuelle Widerrufsformular V1.03 wieder installieren oder gibt es dann Probleme mit dem MODUL: EU-Gewährleistung und GARAN-Label freundliche Grüße, Günther

Du musst in der "box_content.html" den zusätzlichen Link entfernen.

Hallo, bei mir wurde zum Update Consent Tool Oil auch Revocation Form angezeigt. Ich habe beide Updates installiert. Nun hab ich im Shop im Footer 2x "Cookie Einstellungen" stehen. Template ist tpl_modified_responsive_8. Hat wer eine Idee, wie ich den zweiten Eintrag "Cookie Einstellungen" löschen kann? Grüße Roland

Vielleicht könnte das mit dem nächsten Update von dem Modul automatisch mit einbauen. Da ich das jetzt nur gemacht hatte, weil schon mehrere Kunden doppelt bezahlt hatten und mich heute eine Kundin direkt darauf angesprochen hatte. Gruß Chris