Beiträge von HaeFB

Hallo Faro,
ich kann es mir nicht verkneifen:
Du rettest mein Selbstbewußtsein.
Ich dachte schon, ich sei einfach zu blöd.
Lass bitte einfach hören, wenn Du, mit wessen Hilfe auch immer,
eine Lösung gefunden hast.
Frohes Schaffen!

Zitat von StefanSTS

Servus,

Du meinst sicher Paypal Checkout. Paypal Plus ist ja schon vor einiger Zeit abgesetzt worden.

Das VM eigene sollte laufen. Hast Du das probiert?

STS

Alles anzeigen

Tach,
habe ich probiert, auf Testserver.
Da wird mir erstmal was mit IStraxx aufs Auge gedrückt,
die Einrichtung ist einigermaßen wirr und am Schluss schmeisst es mir
meinen mühsam brauchbar gestalteten Checkout durcheinander.
Ich glaube, ich lass es, wie es ist. Never change a running system.
Trotzdem danke!

Moin allerseits.
PayPal nervt, man soll von Standard auf Plus umsteigen.
Wir bauen gerade auf Joomla 5.2.5, VirtueMart 4.4.4 11101, PHP 8.2 um.
Hat jemand schon PayPal+ in diesem Umfeld erfolgreich laufen?
Danke und frohes Schaffen.
VirtueMart 4.4.4 11101VirtueMart 4.4.4 11101VirtueMart 4.4.4 11101VirtueMart 4.4.4 11101

Ich habs mal versucht mit Notepad++ und Plugin Compare.
Die Versionen scheinen nur entfernt verwandt zu sein.
Ist aussichtslos, da was anzupassen.
Solange es weiter funktioniert wäre es ja auch kein Problem.
Aber Hauptsache noch eine Baustelle.

Zitat von Milbo

Ich würde mal gucken, warum da so viel Text drin steht. Irgendeine Category beschreibung ist wohl sehr lang. Aber wie Stefan sagt, es sollte sowieso text sein.

Alles ausprobiert. Sogar lange Texte gelöscht. Der Fehler bleibt:
"1074 Column length too big for column 'category_description' (max = 16383); use BLOB or TEXT instead"

Letzte Idee, wenn auch seltsam. Ich habe teilweise Bilder drin: "<p><img src="images/ticker-sauce.png" alt=""></p>"

Zitat von StefanSTS

Du könntest manuell (PhpMyAdmin o.ä.) in der Datenbank in der Tabelle #__virtuemart_categories_de_de den Typ für category_description auf TEXT setzen.

So wäre das in einer aktuellen Installation.

Geht nicht. Eingestellt ist "mediumtext", TEXT oder varchar oder BLOB werden nicht angeboten zur Auswahl.
Außerdem müsste jeder Datensatz einzeln bearbeitet werden.

Zitat von StefanSTS

PS. Vielleicht macht's auch das "Installiere Tabellen oder falls notwendig aktualisiere diese" in den VM-Tools.

STS

Ganz sicher nicht. Mein Bedarf an Versuchen ist gedeckt und die Lösung des ursprünglichen Problems ist nicht in Sicht.
Dann doch lieber Handarbeit.

Zitat von Milbo

Du hast das ziemlich gut erklärt. Also ja, mein Tool gibt auch wirklich den Befehl alles umzuwandeln. Es gab noch nie eine negative Rückmeldung über das Tool. Es ist sogar nicht extra geschützt, wie andere Tools.

Ergebnis:

Es ist ein Fehler aufgetreten.

1074 Column length too big for column 'category_description' (max = 16383); use BLOB or TEXT instead

Falls die anderen Tabellen trotzdem geändert worden sein sollten:
Am eigentlichen Smiley-Problem hat sich nichts geändert.

Zitat von StefanSTS

Das ist nicht das Gleiche.

In den VM-Werkzeugen gibt es das von Milbo angesprochene Tool.

Bitte benutzen und testen.

STS

Alles anzeigen

Wenn ich den Button "Virtuemart-Tabellen auf UTF8MB$ aktualisieren" drücke kommt ein Popupfenster mit der Meldung:
"Aktualisiert die Kollation in VirtueMart-Tabellen von der alten utf8_general_ci auf utf8mb4_unicode_ci".
Warum soll ich meine richtigen Tabellen nochmals bearbeiten?

Zitat von Milbo

Haste deine Tabellen mit dem Tool auf utf8mb4 gezogen? Denn das soll eigentlich genau solche Fehler verhinden, dacht ich. Denn die Antwort kommt ja von dere Datenbank selber.

Habe extra nochmals beim Hoster in der Datenbank nachgesehen:
Alle Tabellen stehen auf utf8mb4_unicode_ci.

Als Paranoiker mache ich täglich 2 Backups.
Ich habe den Shop Stand 5 Std. davor neu aufgesetzt.
Funktioniert einwandfrei.
Dann im Smartphone eine Bestellung mit Smiley in der
Mitteilung aufgegeben und siehe da:
"er ist wieder da, er ist wiiieder da!"
Die abgemurkste Bestellung habe ich gelöscht und
hoffe schwer dass nicht so schnell wieder Einer auf die dumme Idee kommt.

Wenn ich an den Eröffnungspost denke finde ich schon lustig,
auf welchen Umwegen man an einen Witz-Bug kommt.
Weil eigentlich kein Mensch in der Bestellung eines Kunden einen Smiley braucht,
auch wenn man gerne freundlich behandelt werden möchte.

Hallo Faro,
getestet. Bei Desktop und Laptop kann man kein Emoji eingeben, aber im Smartphone !

Hallo Faro,
Log sagt eindeutig, dass "Incorrect string value: '\xF0\x9F\x8C\xB6' " den Fehler verursacht.
ChatGPT sagt nur:
"Der String-Wert '\xF0\x9F\x98\x8A' repräsentiert ein Unicode-Zeichen in seiner UTF-8-codierten Form.
Es handelt sich dabei um die Kodierung für das Emoji 😊 (ein lächelndes Gesicht)."

Das glaub ich einfach mal.
Also muss man entweder verhindern, dass jemand irgend ein oder gerade dieses Emoji in den Mitteilungstext eingibt
oder Virtuemart sagen, dass es Emojis akzeptieren soll.
Oder ich muss dem Kunden im Checkout sagen, dass er kein Emoji eingeben darf, weil ich das nicht in den Griff kriege.
Danke und frohes Schaffen

Zu der Antwort während ich dies schrub:
Ich kann keine Mehl an jemand schicken dessen Adresse und Email zu speichern durch den Fehler verhindert wurde.

Ich müsste sie jedes mal aus dem ErrorLog popeln.

Ich habe wie vorgeschlagen Errorlog ausgelesen.
Erkenntnisse:
Beide Fehler wurden von einem Besteller ausgelöst.
Im Log steht die Adresse, also kann ich Kontakt aufnehmen.
Kann der Fehler von einer Fehlbedienung kommen, die nicht abgefangen wird?
----------------------------------

2025-01-20 21:30:23 ERROR vmError: vmTable store insertObject #__virtuemart_order_userinfos Incorrect string value: '\xF0\x9F\x8C\xB6' for column `dbs1xxx2008`.`alles_virtuemart_order_userinfos`.`customer_note` at row 1 INSERT INTO `alles_virtuemart_order_userinfos`

(`virtuemart_order_id`,`virtuemart_user_id`,`address_type`,`last_name`,`first_name`,`phone_2`,`address_1`,`city`,`virtuemart_state_id`,`virtuemart_country_id`,`zip`,`email`,`agreed`,`tos`,`customer_note`,`locked_by`,`AGB`,`created_on`,`created_by`) VALUES

('2267','0','BT','Ngxxzi','Gexxxose','017000063264','Kxrwxxxelstraße x4','Eortrg','0','81','8xxx60','gnxxxzi@xmail.com','0','0','🌶','0','1','2025-01-20 21:30:23','0')<pre>#0 xxx/htdocs/t4/administrator/components/com_virtuemart/helpers/vmtable.php(1349): vmError()

#1 xxx/htdocs/t4/administrator/components/com_virtuemart/helpers/vmtable.php(2034): VmTable->store()

#2 xxx/htdocs/t4/administrator/components/com_virtuemart/helpers/vmtable.php(1969): VmTable->bindChecknStoreNoLang()

#3 xxx/htdocs/t4/administrator/components/com_virtuemart/models/orders.php(1989): VmTable->bindChecknStore()

#4 xxx/htdocs/t4/administrator/components/com_virtuemart/models/orders.php(1715): VirtueMartModelOrders->_writeUserInfo()

#5 xxx/htdocs/t4/components/com_virtuemart/helpers/cart.php(1934): VirtueMartModelOrders->createOrderFromCart()

#6 xxx/htdocs/t4/components/com_virtuemart/helpers/cart.php(1627): VirtueMartCart->confirmedOrder()

-------------------------------
ChatGPT hilft.
string value: '\xF0\x9F\x98\x8A'
ist ein Emoji.
Muss man das jetzt ausfiltern?
Ideen haben die Leute.
Bei dem Fehler vor Wochen war es der gleiche Grund.

Hallo STS,
danke für die Bemühungen.
Da seit dem letzten Auftreten des Fehlers und jetzt einige zig Bestellungen
problemlos funktioniert haben sollte es nicht an einer falschen Einstellung liegen.
Könnte PayPal der Verursacher sein?
Wir verwenden noch "PayPal Starter", weil die erweiterte Ausführung Probleme gemacht hatte.
Gruß
HaeF

PS.
Die Email - Benachrichtigung über geringen Lagerbestand ist trotzdem eingegangen.

Hallo Faro,
richtig, die Bestellung wird bei "in Bearbeitung" abgebrochen.
Aber nicht vom Kunden.
Wie könnte er sonst per PayPal bezahlen?
Gruß
HaeF

Hallo,
ich werkle mit VirtueMart 4.4.4 11101 und Joomla 4.4.10.
Der Fehler ist letzte Woche auch schon einmal aufgetreten und nach dem Update auf VirtueMart 4.4.4 11101 wieder verschwunden.

In der Bestellung gibt es normal eine Bestellnummer und eine Rechnungsnummer.
Bei diesen Bestellungen fehlt die Rechnungsnummer, Status ist "in Bearbeitung",
Name und Email des Bestellers wird nicht angezeigt.

Wenn ich die Bestellung durch Klick auf die Bestellnummer öffnen will, erhalte ich die Fehlermeldung
Attempt to assign property "invoiceNumbers" on null und einen Link zum Dashboard.
Versuche ich "Drucken", kommt Attempt to assign property "order_total" on null.
Seltsamerweise hat bei einer Bestellung die Bezahlung per PayPal trotzdem geklappt, so dass ich den Kunden per Email kontaktieren kann.
Der Andere ist wohl weg.
In der Datenbank sind unter _virtuemart_order alle Einträge vorhanden.
In _virtuemart_order_items sind die bestellten Artikel.
In _virtuemart_order_userinfos und _virtuemart_invoices gibt es KEINE Datensätze zu der Order.

In Automatic Numbers steht:

This product is not registered. Please provide your registration number to validate your license.

The installation of this extension is only licensed when properly registered at extensions.virtuemart.net.

Registration of the product is necessary for getting support and removes also this message

The registration number is provided within your order a line below the download link
(Die Nummer ist eingetragen)

View my orders at extensions.virtuemart.net

Klicke ich darauf, komme ich zu meiner ursprünglichen Mitgliedschaft,
die ich aber da immer noch nicht verlängern kann.
Langsam nervt das echt.

Frohes Schaffen
HaeF

Zitat von semi

Ich habe im Code keine direkte Möglichkeit gefunden den Customfield Value auszulesen und habe es dann letztlich mit einer SQL Query gelöst. Funktioniert wie gewünscht und der Shop hat damit nun auch gemischte Versandkosten mit String Customfields Produktvarianten.

Wenn man um Hilfe fragt und dann die Lösung selbst findet wäre es außerordentlich liebensgewürzig wenn man die Allgemeinheit an seinem Wissen teilhaben lassen würde.

Vielleicht nochmals:
In der Zahlungsart "Standard" wird "Bestellstatus für noch ausstehende Zahlungen" eingestellt.
Der muss dann auch bei "Standard-Bestellstatus, bei welchem eine E-Mail an den Verkäufer versendet wird" eingestellt sein.

So richtig?

Also zumindest bei mir ist zusätzlich "Bestellt" eingestellt, weil das der Status ist, wenn nicht per PayPal sondern per Vorauszahlung bezahlt wird.
In der Zahlungsart ist bei Konfiguration für Bestellstatus für ausstehende Zahlungen "Bestellt" eingestellt.
Das müsste irgendwie übereinstimmen.