Das muss nicht unbedingt an PHP 8 liegen, dass kann auch einfach eine Einstellung beim Hoster sein. Normalerweise ist der Name "localhost" bei vielen Hostern vorkonfiguriert, ich würde einfach den Hoster noch einmal fragen warum der Name "localhost" nicht mehr funktioniert.
Die Angabe „localhost“ wird von MySQL-Clients auch traditionell so interpretiert, dass die Kommunikation mit den Server nicht per TCP erfolgen soll, sondern per UNIX-Socket. Denkbar, dass genau da irgendwo der Fehler liegt. Das kann aber auch nur der Hoster genau herausfinden.
Ich gehe davon aus, dass die allermeisten Shops, die PHP 8.1 und GX 4.7 bis 4.8 nutzen noch localhost da stehen haben und es geht. Es ist wohl eher die Ausnahme, dass es nicht geht. Mit ist diese Info jedenfalls neu.
Genau das wäre übrigens der gängige Workaround, wenn meine These aus #202 zutrifft. Damit erzwingt man die Verwendung einer TCP-Verbindung statt des Unix-Sockets.
Weiß nicht ob es schon gemeldet wurde: Im neuen Kundenbereich, werden unter "Warenkorb" die Artikel-Nummern unabhängig von der Einstellung "Artikelvarianten-Artikelnummer anhängen" in den Einstellungen, immer mit angehängter Artikelvarianten-Artikelnummer gezeigt. EDIT: Das betrifft auch den Bereich Bestellungen, in der Übersicht bei PayPal2Hub (API v2)/Details der Bestellung
Hallo zusammen, ich habe gerade die PHP Version auf die 8.1 raufgeschraubt seitdem erhalte ich im Frontend den Fehler: "Unexpected error occurred... syntax error, unexpected identifier "nicht" Backend geht bis auf das Leeren der Caches, da kommt der gleiche Fehler. Ist das nur bei mir so? Schöne Grüße Bene
Siehe Post #118 und #130 Hoffentlich gibt es hierfür eine Lösung. Wir sind doch alle schon so lange dabei und früher gab es nicht Anderes.
Ok sorry für Doppelpost. Vermutlich auch schon 3x hier gespostet, aber falls nicht: Die Modelnummer wird immer noch in der Mobildarstellung angezeigt, obwohl Schalter auf aus ist.
Hatte ich auch, "IonCube" fehlt da, die Fehlermeldung kommt z.B von xycons-Modulen. Bin wieder auf PHP 7.4 zurück und alles läuft wieder.
Habe es heute endlich geschafft, die Datenbank von Mysql 5.7 auf MariaDB10.6 umzustellen. Ich hatte bei den ersten Versuchen Abbrüche beim Upload wegen der Größe. Über phpmyadmin ungezipt exportiert und dann in neue DB importiert. Die Geschwindigkeit hat sich bei verschiedenen Messungen um ca. 0,5 sek. verbessert. Die größte Veränderung hat sich beim Öffnen vom Backend gezeigt. Das läuft jetzt flüssiger. Schön, dass diese Gambio-Version das ermöglicht.
Argh, ich kann mich nicht als Neukunde anmelden : Unexpected error occurred... Undefined class constant 'ANTI_SPAM_ELEMENT_NAME' Support Ticket ist eröffnet.
Seit dem Update von 4.0.x.x auf 4.7.x.x/4.8.x.x habe ich ein sehr nerviges Verhalten der Bestandsprüfung. Wenn bei uns ein Artikel das erste mal bestellt wird, schaltet sich die Bestandprüfung automatisch auf "Standard", egal was davor eingestellt wurde. Nun zieht es mir sowohl bei den Eigenschaften wie auch bei den Hauptartikeln den Bestand ab und setzt den Artikel direkt wieder auf "Ausverkauft" Wurde da was geändert? @Till (Gambio) @Marco (Gambio)
Das Standardverhalten ist und sollte immer von beiden abziehen, wenn du das nicht willst und nur vom Variantenbestand abgezogen haben willst, musst du "Variantenbestand" im jeweiligen Artikel einstellen. Die Einstellungen im Artikel wurden nicht verändert, das stellt sich nicht automatisch wieder zurück auf "Standard", das wurde im Update nicht verändert.
Hi Till, danke für Deine Rückmeldung. Bei mir stehen immer alle Artikel auf Warum auch immer, werden Artikel nach der ersten Bestellung, automatisch auf "Standard" zurückgesetzt. Wenn da nichts geändert wurde, dann muss ich mal weitersuchen woran das liegt.
@Till (Gambio) Ich habe was gefunden was neu ist. Evtl. liegt es daran. Ihr habt eine neue Funktion eingebaut, die die Bestandsprüfung automatisch auf Standard setzt, wenn man Kombinationen löscht und das Produkt dann keine mehr hat. Wenn man jetzt neue Kombinationen hinzufügt, bleibt der Wert dann auf Standard. ProductVariantsDeleter.php PHP: if ($combiCountForProduct === 0) { // if no variant remained the configuration "use_properties_combis_quantity" // of product table will be rolled back to default value (0) $this->connection->createQueryBuilder() ->update('products') ->set('use_properties_combis_quantity', 0) ->where('products_id = :product_id') ->setParameter('product_id', $productId) ->execute(); } Ich schalte das mal bei mir ab und prüfe das dann nochmal.
@BigRib Ja, das ist korrekt und gewollt, weil sonst wenn man keine neuen Varianten mehr hinzufügt und den Artikel dann ohne Varianten betreiben will, ja die Standardprüfung wieder erfolgen muss. Wenn wir das nicht zurücksetzen würden, wäre die Bestandsprüfung bei Artikeln ohne Varianten wieder fehlerhaft.