Soweit einverstanden, der Punkt war jedoch, daß ich die Schloß-Symbole in der Spalte „Bestellung bearbeiten“ für bare Münze hielt und das Schloß haben alle außer U und P. Wie Du weiter oben geschrieben hast, läßt sich eine Bestellung im Status X aber bearbeiten, hatte ich dann ja getestet.
Ich werde das mit den Verkäufern besprechen und dann wohl ändern …
Besten Gruß
Steffen
Hallo,
das hängt wie beschrieben an „ACL & Optionen konfigurieren“. Ich habe der Gruppe Verkäufer erst sämtliche VM-Optionen auf „Erlaubt“ gesetzt und wollte dann wo nicht nötig nach und nach wieder auf „Nicht erlaubt“ umstellen. Rechnung entsperren war schon nicht mehr möglich, nachdem gleich die erste Option „ACL & Optionen konfigurieren“ wieder auf „Nicht erlaubt“ gesetzt war.
In dem Fall hatte der Kunde nach Rechnungszugang (Vorkasse) noch den Wunsch einen der Artikel abzubestellen. Das bekommt man ja hin, indem die Menge auf 0 gesetzt wird, nur muß dann eine passende Rechnung erzeugt werden und das geht so nicht. Ich werde den Verkäufern aber nicht „ACL & Optionen konfigurieren“ einschalten.
Besten Gruß
Steffen
Hab ich, gestern gemacht:
Besten Gruß
Steffen
Moin!
Dazu habe ich eben im VM → Berechtigungen den Verkäufern sämtliche Optionen auf „Erlaubt“ gesetzt. Dann kann ein Verkäufer eine Rechnung entsperren. Als nächstes habe ich „ACL & Optionen konfigurieren“ auf „Nicht erlaubt (Vererbt)“ gesetzt und kann dann als Verkäufer keine Rechnung mehr entsperren. Das halte ich für einen Fehler, Rechnung entsperren müßte an „Bestellungen editieren“ gekoppelt sein.
Besten Gruß
Steffen
VM 4.0.12 10777, J 4.4.1, PHP 8.1.27
Hmm, im 4.0.12 auch, gerade mal entsprechend konfiguriert und eine Testbestellung aufgegeben. Weshalb wird in der Übersicht der Bestellstatus in der Spalte „Bestellung bearbeiten“ in allen Zeilen außer U und P ein Schloßsymbol angezeigt?
Besten Gruß
Steffen
Hallo,
der Gedanke ist, auch bei Paypalabbruch, dessen Grund man nicht kennt, den Käufer zu halten. Der Verkäufer soll dann eine Rückfrage starten. Dafür wäre es nicht zweckmäßig, die Bestellung abzubrechen, denn dann müßte der Käufer eine neue auslösen.
Bei X, der ebenfalls gesperrt ist, läßt sich nicht einstellen, daß die Bestellung noch bearbeitet werden kann, hab gerade nochmal reingesehen. Es geht auch bei den übrigen Status nicht, wenn ich nichts übersehen habe. Auch selbst angelegte Status lassen keine Bearbeitung der Bestellung zu.
Besten Gruß
Steffen
Hallo,
habe gerade erst Deine Antwort gesehen.
In den letzten Jahren konnte ich öfter beobachten, dass Status P anders verwendet wurde als für diesen vorgesehen ist.
Was genau soll da passieren?
[…]
Ein Status P nach einer Bestellung sollte eigentlich nur nach einem Fehler möglich sein, ansonsten ist es die Aufgabe des Zahlungsplugins, einen anderen Status zurück zu geben.
Ich habe die Mailskripte so angepaßt, daß je nach Status ein jeweils passender Mailtext an Käufer und an Verkäufer verschickt wird. Wir machen außer Paypal nur noch Vorkasse und verwenden Status U nach dem Eingang einer Bestellung, auch bei abgeschlossener Paypalzahlung. Wurde der Zahlvorgang bei Paypal abgebrochen, wird Status P verwendet und auch bei dem soll eine (passende) Mail als Eingangsbestätigung rausgehen. Da nur diese beiden Status die Bearbeitung der Bestellung zulassen, bleibt keine andere Wahl.
Du kannst diesen Wert in die Hidden Config eintragen, wenn ich mich recht erinnere.
Schau einmal in die virtuemart.cfg im Admin-VM-Ordner.Im Repository findest Du die Datei als virtuemart_defaults.cfg-dist.
Die beiden Dateien hatte ich sogar gefunden, aber es wirkt nicht, wenn ich dort das P ergänze. Daraus habe ich geschlußfolgert, daß das wohl noch anderswo stehen muß.
Besten Gruß
Hallo,
weil wir auch beim Status P eine Mail an den Käufer verschicken wollen, der Status P aber nicht frei bearbeitet werden kann, blieb mir nichts weiter übrig als in der Tabelle virtuemart_configs den Eintrag email_os_s=["U","Y","Z","S"] mit einem "P" zu ergänzen. Ärgerlich ist nun, daß das "P" bei einigen Konfigurationsänderungen ungewollt wieder entfernt wird, es genügt schon, den Shop in den Katalog-Modus zu setzen. Damit man nicht jedesmal manuell in der Tabelle nachhelfen muß, habe ich eine SQL-Datei gebaut, die man im myPhpAdmin laden kann und die das wieder korrigiert. Meine Suche wo der email_os_s-Inhalt evtl. als Default hinterlegt ist blieb ergebnislos. Wo ist das zu finden?
Schönen Restsonntag
Steffen
J 4.4.1, VM 4.0.12 10777, PHP 8.1.27
Nabend!
Wir hatten gerade das Problem, daß ein Kunde einen von mehreren Artikeln stornieren wollte. Man kann ja in der Einzelansicht der Bestellung die Menge des Artikels auf 0 setzen und dann, um eine dazu passende Rechnung zu erzeugen, oben auf das rote Schloß „Rechnung entsperrt setzen“ klicken. Das klappt auch, aber nur als Admin. Wir haben eine Gruppe Verkäufer, da ich das nicht selbst mache. Bei Verkäufern ist der Klick auf das Schloßsymbol aber wirkungslos. In den Berechtigungen der Komponente finde ich nichts, was den Verkäufern erlauben würde eine Rechnung zu entsperren. Wo ist der Fehler oder ist das nicht möglich?
Hier läuft VM 4.0.12 10777 mit J 4.3.4 und PHP 8.1.24.
Besten Gruß
Steffen
Nabend!
Die Ursache war in meiner de-DE.override.ini in COM_VIRTUEMART_CART_MAX_ORDER zu finden, worin statt %1$d nur %$d enthalten war. Kann ich mir nicht mehr erklären, ist zu lange her.
Besten Dank und Gruß
Steffen
Sprachdateien, da war doch was, damit hatte ich ohnehin Schwierigkeiten, suche ich mal raus. Mit den Dateien von VM ist der Fehler immernoch da, er ist aber weg, wenn ich die de-DE.override.ini unwirksam mache (umbenenne).
Besten Gruß
Steffen
Hallo,
die dynupdate.js habe ich gefunden, wollte die aber nicht bearbeiten, da ich das ja vermutlich nach jedem Update wieder machen müßte.
Die F12 für Inspektor, Console usw. war mir auch noch nicht geläufig, hab das immer über „Element inspizieren“ geöffnet. Wenn man mit der 3 aktualisiert und die Fehlerbox kommt, wird zweimal die Meldung „Einige Cookies verwenden das empfohlene "SameSite"-Attribut inkorrekt. Das Cookie "…" verfügt über keinen gültigen Wert für das "SameSite"-Attribut. […]“ ausgegeben. Der Bezug zum Problem erschließt sich mir nicht, denn lt. Beschreibung bei mozilla.org dient das SameSite-Attribut der Abwehr manipulierter URL-Parameter. Auf Cassiopeia umgestellt kommt derselbe Fehler.
Mit eingeschaltetem Debug wird ausgegeben:
Argument number specifier must be greater than zero and less than 2147483647
…/administrator/components/com_virtuemart/helpers/vmtext.php:150
Call stack
# Function Location
1 () JROOT/administrator/components/com_virtuemart/helpers/vmtext.php:150
2 sprintf() JROOT/administrator/components/com_virtuemart/helpers/vmtext.php:150
3 vmText::sprintf() JROOT/components/com_virtuemart/helpers/cart.php:2536
4 VirtueMartCart->checkForQuantities() JROOT/components/com_virtuemart/helpers/cart.php:2344
5 VirtueMartCart->prepareCartData() JROOT/components/com_virtuemart/controllers/cart.php:86
6 VirtueMartControllerCart->display() JROOT/libraries/src/MVC/Controller/BaseController.php:678
7 Joomla\CMS\MVC\Controller\BaseController->execute() JROOT/components/com_virtuemart/virtuemart.php:128
8 require_once() JROOT/libraries/src/Dispatcher/LegacyComponentDispatcher.php:71
9 Joomla\CMS\Dispatcher\LegacyComponentDispatcher::Joomla\CMS\Dispatcher\{closure}() JROOT/libraries/src/Dispatcher/LegacyComponentDispatcher.php:73
10 Joomla\CMS\Dispatcher\LegacyComponentDispatcher->dispatch() JROOT/libraries/src/Component/ComponentHelper.php:361
11 Joomla\CMS\Component\ComponentHelper::renderComponent() JROOT/libraries/src/Application/SiteApplication.php:208
12 Joomla\CMS\Application\SiteApplication->dispatch() JROOT/libraries/src/Application/SiteApplication.php:249
13 Joomla\CMS\Application\SiteApplication->doExecute() JROOT/libraries/src/Application/CMSApplication.php:293
14 Joomla\CMS\Application\CMSApplication->execute() JROOT/includes/app.php:61
15 require_once() JROOT/index.php:32
Da wird wohl in vmtext, Zeile 150 ein unzulässiger Parameter übergeben.
Besten Gruß
Steffen
Hallo,
in unserem Shop ist bei einigen Artikeln die Höchstkaufmenge gesetzt, ansehen kann man sich das im Testshop unter https://shopt.hisb.de/ beim Wandkalender 2023. Mit dem Plus-Button kann man die Höchstkaufmenge nicht überschreiten, aber indem man etwas höheres, z.B. eine 3 in das Feld einträgt. Klickt man dann auf „In den Warenkorb“ kommt nur die Sanduhr, sonst tut sich nichts, solange man auch wartet. Man kann aber rechts oben auf den Link „Warenkorb“ klicken, dann wird der auch angezeigt und ist leer. Das wäre noch kein ernstes Problem, wenn man nicht dasselbe im Warenkorb selbst macht. Trägt man dort 3 ein und klickt dann rechts daneben auf Mengenangabe aktualisieren, dann kommt eine Fehlerbox „Error updating cart“, die sich bestätigen läßt. Danach ist weiter der Warenkorb zu sehen und es steht die 3 als Menge da. Geht man weiter einkaufen o.ä. dann führt jeder weitere Versuch, den Warenkorb erneut zu öffnen, zur Fehlermeldung „0 - Argument number specifier must be greater than zero and less than 2147483647“.
Anscheinend wird da was in einem Cookie gespeichert, denn das bleibt solange so, bis ich den Browser (egal welchen) schließe, denn dabei werden die gelöscht. Lasse ich die Cookies nicht löschen, dann ist das Verhalten auch nach dem nächsten Start des Browsers so wie beschrieben. D.h., daß Kunden, die Cookies nicht löschen lassen, nie wieder den Warenkorb öffnen können.
Um das zu vermeiden, scheint es mir sinnvoll, daß der Shop nach der Fehlermeldung „Error updating cart“ die eingetragene Menge auf den Höchstwert setzt und nochmal aktualisiert.
Die Fehlermeldung selbst (Error updating cart) habe ich auch in keiner INI-Datei gefunden, sonst würde ich das mal eindeutschen.
Hier läuft VM 4.0.12 10777 mit J 4.3.4 und PHP 8.1.24, Shop-Template ist Standard/Default.
Besten Gruß
Hallo Stefan,
meine Aversion kommt daher, daß ich mich damals mit dem Zustandekommen der Rechtschreibreform beschäftigt habe und seitdem darauf achte. Es gab dazu mal eine gute Webseite, heute nur noch bei http://web.archive.org/web/200…ortfolio/ma/ma_motti.html Gibt es auch als Buch https://www.buchhandel.de/buch…und-Politik-9783837012217
Nachtrag: Der Punkt auf’s I war dann noch die Aussage der damaligen Vorsitzenden der Kultusministerkonferenz Wanka: „Die Kultusminister wissen längst, dass die Rechtschreibreform falsch war. Aus Gründen der Staatsräson ist sie nicht zurückgenommen worden.“ https://de.wikipedia.org/wiki/…Wanka#Politische_Laufbahn
Mit dem sonst wohl über das mir nicht vertraute Transifex laufenden Prozeß der Sprachanpassung kenne ich mich nicht aus. Bei solchen Versionsänderungen sehe ich mir die alte und neue INI mit einem Diff-Programm an, wenn ich das nur gelegentlich machen muß. Dann kann man die geänderten Zeilen in der bisherigen Zielsprach-INI leicht anpassen. Müßte ich das häufiger machen, würde ich neue Zeilen (Variablen) aus der en-GB per Shellskript in die de-DE schreiben. Mir ist aber klar, daß das bei mehreren Beteiligten und für de-DE, de-AT usw. so nicht funktioniert.
Besten Gruß
Steffen
Hallo Stefan,
ZitatDeshalb ist es ratsam, sämtliche Sprach-Overrides für "Administrator" und "Site" zu erstellen. Das ist ein "Joomla-Ding".
Ahh danke, darauf wäre ich so schnell nicht gekommen. Spart mir Arbeit, denn ich saß gerade daran, das in die originalen INIs einzuarbeiten, wie ich es unter 3.10 auch schon gemacht hatte. Bisher habe ich die Overrides für Admin u. Site getrennt gemacht, muß ich dann für die www-Seite auch noch zusammenfassen.
Zum Sprachthema habe ich gleich noch ein paar Punkte. In den VM-INIs habe ich generell „Produkt“ durch „Artikel“ und „auschecken“ durch „bezahlen“ ersetzt, weil mir das im Deutschen passender erscheint. Außerdem habe ich die meisten „erfolgreich“ rausgeworfen, beispielsweise „Addresse wurde erfolgreich gelöscht.“ → „Addresse wurde gelöscht.“, denn sie kann nicht nicht erfolgreich gelöscht worden sein. Noch ein Beispiel, um das zu verdeutlichen:
Beispiel Ausbildung, Studium
abgeschlossen → mit einem Abschluß, d.h. Zeugnis, Urkunde, Zerifikat o.ä., deshalb ist erfolgreich abgeschlossen ein Pleonasmus (weißer Schimmel)
beendet → keine Aussage zum Ergebnis der Ausbildung
erfolgreich beendet → mit Abschluß, d.h. hier paßt es mal
abgebrochen → kein Abschluß
kein VM-Beispiel, gerade in meiner Overrides gefunden
Installation von Paket: %s → Installation des Pakets: %s
Genitiv statt Vonitiv (Dativ) Kontrollfrage: Wessen …?
Wenn ich mit den Anpassungen fertig bin, wird das unter https://shop.hisb.de/language/overrides/de-DE.override.ini zu finden sein.
Besten Dank und Gruß
Steffen
Hallo,
um die Mailbetreffs anzupassen, habe ich alle COM_VIRTUEMART_MAIL_SUBJ_SHOPPER_* und …VENDOR_* in die de-DE.override übernommen, doch die wirken nicht wie sie sollen. Das trifft auch auf die übrigen geänderten Einträge zu, die ich in de-DE.com_virtuemart_orders.ini überschreiben will. Weil bei einigen der deutschen Dateien, die in /language/de-DE/ liegen, die englischen Pendants unter /components/com_virtuemart/language/en-GB/ zu finden sind, habe ich die entsprechenden deutschen nach /components/com_virtuemart/language/de-DE/ verschoben, ändert aber nichts. Es betrifft nur Einträge, die die in de-DE.com_virtuemart_orders.ini überschreiben sollen, alles andere funktioniert.
Dann fiel mir noch auf, daß in den deutschen Sprachdateien COM_VIRTUEMART_USER_FORM_EDIT_SHIPTO_LBL fehlt, weshalb auf dem Button „Edit current shipping address“ steht. Habe ich mit „Lieferadresse eingeben“ in der Override ergänzt.
Nachtrag: Gerade sehe ich, daß auch COM_VIRTUEMART_MAIL_SUBTOTAL_DISCOUNT_AMOUNT="Preisnachlaß" in de-DE.com_virtuemart.ini fehlt und auch dann von der override.ini nicht überschrieben wird, wenn ich es in de-DE.com_virtuemart.ini ergänze.
Joomla 4.2.8, VM 4.0.12.10777, Sprachpaket 4.0.8.0
Besten Gruß
Steffen
Hallo,
per Suche habe ich diesen Faden gefunden, denn ich hatte dasselbe Problem auf shop.hisb.de, nachdem ich Joomla von 3.10.11 auf 4.2.8 und dabei VM von 4.0.6 auf 4.0.12 aktualisiert habe.
Daß Kunden wegen der Mail-Verifizierung abspringen könnten, mag wohl vorkommen. Man kann bei uns aber auch ohne Registrierung als Gast kaufen. Einige werden es aber praktisch finden, nicht jedesmal alles neu eingeben zu müssen. Weil oft genug Rückfragen nötig werden, und sei es nur, weil die Hausnummer fehlt, will ich das auch so beibehalten.
Nach einigem suchen habe ich die Ursache der falschen Mailinhalte gefunden. Im Joomla 3.10 wurden die Mails in /components/com_users/models/registration.php erzeugt und in den Sprachvariablen wird noch %s als Platzhalter verwendet. In Joomla 4.2 finde ich nichtmal mehr die Variablen in den PHP-Skripten. VM hat für einen Teil der Mails eine eigene PHP-Datei /administrator/components/com_virtuemart/models/user.php, in der wie in Joomla 3.10 sprintf verwendet wird, das als Platzhalter für Strings %s erwartet und nicht etwas wie {NAME}. Man muß sich deshalb für die Variablen COM_USERS_EMAIL_* ausgenommen COM_USERS_EMAIL_PASSWORD_RESET_* und COM_USERS_EMAIL_USERNAME_REMINDER_* Einträge in der override.ini anlegen und darin alle {NAME}, {SITENAME} usw. durch %s ersetzen. Die Passwort-Reset- und die Benutzername-Vergessen-Mail werden nicht über VM erzeugt und sind deshalb nicht betroffen.
Vermutlich würde die Anpassung der Mail-Templates im Backend nicht helfen, denn ich hatte vorher mal getestet, ob Änderungen überhaupt wirken. Die Änderungen werden zwar in die Tabelle präfix_mail_templates geschrieben, wirkten aber nicht. Allerdings war da noch {NAME} usw. enthalten.
Besten Gruß
Steffen
Ahh, das hatte ich nicht gefunden.
Besten Dank!
Hallo!
In einem neu installierten Shop 3.8.8 mit Joomla 3.10.2 sollen mehrere Benutzer, die der neuen Gruppe Verkäufer zugeordnet sind, die Bestellungen bearbeiten. In der sonst soweit angepaßten Rechnung soll deshalb der Name des angemeldeten Benutzers ausgegeben werden. Auf der Suche nach einem Beispiel habe ich die verschiedenen PHP-Dateien durchgesehen, in denen der Name ausgegeben wird, und auch im www gesucht, aber nichts passendes gefunden, das sich so in die invoice_order und …order2, die ich unterhalb der …items ergänzt habe, übernehmen ließe. Wie komme ich dort an den Benutzernamen?
Besten Gruß
