Hm, ich sehe da im Code zum Beispiel:
if ($field['name'] != 'title'
da würde ich einfach einmal
if ($field['name'] = 'email'....
im ersten Aufruf versuchen.
if (!empty($field['value']) && $field['name'] != 'email') {
So ungefähr könnte das funktionieren, falls "email" die richtige Variable ist. Dafür könntest Du einen var_dump machen, um zu sehen, was alles vorhanden ist.
Oder Du schaust Dir die Jooglies VM Rechnung/E-Mail Pro an. 
Grüße
Stefan
Servus,
JTL Wawi mit Connector für VM ist eine Wahl.
Ob eine Wawi sinnvoll ist, hängt vom Volumen und der Art der Produkte ab.
Je statischer die Produkte, desto weniger Wawi. Je mehr wechselnde Produkte, je mehr Wawi, um das sehr global auszudrücken.
Man kann eine Wawi natürlich auch zu einem späteren Zeitpunkt "nachrüsten", wenn es einen Vorteil verspricht.
Grüße
Stefan
Servus,
am besten eine neue Template-Version installieren, oder den Override der default.php in den productdetails an die aktuelle VM-Version anpassen.
Diese Änderung wurde schon vor ziemlich langer Zeit vorgenommen.
Das Array sind die Anzeigen der möglichen Versand- und Zahlungsarten, die man über deren Plugins aktivieren kann.
Grüße
Stefan
Hallo Faro,
ich hab das gerade einmal versucht. Du möchtest also das Captcha bei der Eingabe der Adresse nicht einblenden.
Dann sollte die obige Lösung funktionieren, da die Registrierung garnicht aufgerufen wird.
Ich bin mir nicht sicher, ob die Registrierung dann nicht über eine bekannte URL aufgerufen werden kann, das würde ich aber erst einmal "riskieren". Wenn dann Anmeldungen über VM kommen sollten, muss man da irgendwo in einem Override die "Leitung" zur Registrierung kappen.
Leider hab ich gerade nicht die Zeit, da im Code zu suchen.
Hast Du das Plugin "VM Framework Loader during Plugin Updates" eingeschaltet und im zweiten Reiter die Einstellung gesetzt, dass von com_user zur VM-Registrierung weitergeleitet wird?
In meinem Fall reicht das, um die Anmeldungen von Bots zu unterbinden, weil die immer nur über com_user (Joomla) kamen.
Auf die Schnelle
Stefan
Hi Faro,
Du benutzt das Captcha also nur für die Frage zum Produkt?
Du kannst es aus der normalen Benutzerregistrierung herausnehmen, indem Du einen Override für
components/com_virtuemart/views/user/tmpl/edit_address.php
unter
templates/DeinTemplate/html/com_virtuemart/user/edit_address.php
erstellst.
Dieses hier:
entweder komplett rauslöschen oder den captcha-Aufruf auskommentieren:
Wenn Du einen OPC verwendest - Du hattest meine Frage nicht beantwortet - ist der captcha-Aufruf in den Layouts vom OPC.
Wenn Du die Anfrage zum Produkt nicht verwendest, würde ich das Recaptcha deaktivieren. Eine deaktivierte Benutzerregistrierung sollte ausreichen.
Grüße
Stefan
Hallo Faro,
lass mich erst ein paar Fragen stellen.
Kannst Du aus den Server-Logs entnehmen, ob sich die ungebetenen Robots sich über com_user oder über die VirtueMart-Registrierung anmelden?
Benutzt Du einen One Page Checkout?
Wenn Du ausschließlich den Gastcheckout wählst, kannst Du auch die Benutzerregistrierung in den Optionen für Benutzer in Joomla ausschalten. Bzw. den Zugang zu com_user über die .htaccess sperren.
Ich habe bei mir das ECC von Kubik Rubik ausprobiert, und lasse es nur mit den versteckten Möglichkeiten laufen. Ohne Abfrage. Seitdem habe ich keine ungebetenen Robots mehr.
Grüße
Stefan
Servus,
die Custom Fields werden über das Sublayout customfield.php eingebunden, in diesem Sublayout ist es evtl. möglich, eine Abfrage dafür einzubauen,so dass der Wert nicht weitergegeben wird.
Für Sublayouts kann man Template-Overrides anlegen.
Leider hab ich das nicht genauer untersucht, vielleicht führt es in eine entsprechende Richtung.
Zweiter mir vorschwebender Ansatz wäre die Änderung des Aufrufs in der cart view. Evtl. ist auch hier eine Abfrage möglich, ob ein Wert vohanden ist. Klingt geschrieben jetzt einfacher als der erste Gedanke.
Hope it helps
Stefan
Leider ist das ohne genauere Informationen schwer nachzuvollziehen.
Vielleicht einfach noch einmal alles langsam durchgehen, und die einzelnen Schritte nachvollziehen.
Ich denke, es bedarf einer genaueren Untersuchung, das ist hier über das Forum kaum hinzubekommen. Evtl. mit Screenshots aller relevanten Bereiche, aber derer sind viele.
Grüße
Stefan
Es geht um die Inhaltssprache unter Joomla-Menü - Erweiterungen - Sprachen.
Dort muss die Spracheinrichtung auch richtig sein. Wenn das im Nachhinein umgestellt wurde, kann es sein, dass einige Begriffe in den falschen Datenbank-Tabellen gelandet sind.
Grüße
Stefan
Servus,
da würde ich evtl. einmal auf das Tempate Protostar schalten oder im aktuellen Template den Ordner
/templates/meinTemplate/html/com_virtuemart/ umbenennen.
Hört sich nach einem Template-Problem bzw. einem alten Override an.
Grüße
Stefan
Servus,
das kommt meistens vor, wenn die Inhaltssprache der Installation nicht DE ist, sondern auf EN steht. Insbesondere bei der Installation von Full oder Quick Installern passiert das immer wieder, weil die von internationalen Anbietern so ausgeliefert werden.
Da sollte die Inhaltssprache auf Deutsch gestellt werden, und evtl. müssen die Inhalte der en-gb Tabellen in der Datenbank in die de-de Tabellen übernommen werden, weil sonst keine Produktnamen und so weiter geladen werden können.
Grüße
Stefan
Hallo Stan,
meistens kommt das vor, wenn die Joomla-Installation nicht über alle nötigen Menüs verfügt.
Minimum bei mehrsprachiger Seite:
Allgemeines Home-Menü: 1 Verweis für alle Sprachen auf einen Beitrag, der für alle Sprachen freigegeben ist.
Home Menü DE: mindestens ein Verweis für DE auf einen Beitrag (oder VM) in deutscher Sprache.
Home Menü EN: mindestens ein Verweis für EN auf einen Beitrag (oder VM) in englischer Sprache.
Es gibt diverse Tutorials im Netz, die diesen Vorgang beschreiben.
Die Module der jeweiligen sprachspezifischen Menüs dann auch pro Sprache freigeben.
Einige Templates können das nicht, weil die Menüs über die Template-Einstellungen eingebunden werden. Dann muss man evtl. zwei Template-Stile anlegen, einen für EN, einen für DE.
Grüße
Stefan
Hallo,
es gibt "Steuer pro Produkt" und "Mehrwertsteuer pro Produkt". Bitte letzteres für die Mehrwertsteuer verwenden.
Wenn alle Artikel unter 19% laufen, einfach keine Kategorie in den Einstellungen eintragen, dann gilt es für alle Kategorien/Produkte.
Grüße
Stefan
Hallo Lisa,
lege doch bitte einen Menüeintrag für den Warenkorb an, dieser kann in einem versteckten Menü sein oder man kann ihn in einem sichtbaren Menü auch ausblenden.
Danach kann man bei der Menüzuweisung das Warenkorb-Modul in der Warenkorb-Ansicht ausschließen.
Warum verwendest Du alte Joomla und VM-Versionen?
Wenn das ein Starter-Paket eines Templates ist, würde ich das nur als zweite Installation nebenbei zum Anschauen verwenden und dann mit einer frischen Installation anfangen.
Grüße
Stefan
Hallo Mark-Peter,
das ist möglich. vielleicht hilft zur Überprüfung der Installation dies schon einmal weiter:
https://www.jooglies.com/tutor…mart-deutsch-installieren
Die weitere Konfiguration hängt von den Voraussetzungen ab, die der Shop erfüllen soll.
Natürlich stehen wir da gerne zur Verfügung.
Grüße
Stefan
Hallo Faro,
danke für den Link zum Podcast von Stephan Hansen-Oest, endlich einmal ein Anwalt, bei dem ich beim Zuhören ein Dauergrinsen drauf hab.
Ich behaupte dann mal fest auf Grund des Podcasts (und dem Studieren diverser Rechtstexte und Urteile über die Jahre): Wir machen es bereits seit Jahren richtig in den Shops unserer Kunden. 
Nichts Neues, zumal das Ding ja eh schon vor zwei Jahren in Kraft getreten ist, und ab dem 25.05.2018 nur das "MUSS" dazukommt.
So, nun mal wieder an die "echte" Arbeit.
Wünsche eine freudige Woche
Stefan
Servus,
man kann seit VM 3.2.14 einen Menüeintrag für die Orderdone anlegen.
Die Datei heißt jetzt orderdone.php, vorher order_done.php.
Damit kann man eine Menüzuordnung in Modulen vornehmen.
Grüße
Stefan
PS. Ein (versteckter) Menüeintrag für den Warenkorb sollte auch schon helfen.
Hallo Harald,
ich verändere den OPC meistens ein wenig mit CSS, damit er noch weniger anzeigt. Dieses könnte auch Dir helfen:
payment-row ist für die Zahlart. blank-row sind leere Zeilen für mehr Abstand, die ich zu groß finde.
col-discount ist der Preisnachlass.
Das Ganze als Media Query unterhalb von 767px, damit der Warenkorb auf dem Desktop nicht beeinflusst wird.
Den Preisnachlass kann man im OPC auch ganz ausschalten. Das mache ich meistens.
Grüße
Stefan
Wie handhabt ihr diese Problematik momentan?
Im Moment noch ziemlich stiefmütterlich.
Ich hab von einem Kunden gehört: "So, ich hab das für die DSGVO jetzt soweit fertig."
Dann hab ich mir gedacht: "Super, muss ich mich nicht um den Sch...önen Kram kümmern."
Übermorgen kommt dann wieder eine andere Verschärfung und man muss dem Shop eine Seite vorschalten, auf der steht:
"Shoppen schadet Ihrer Gesundheit."
Dann wahrscheinlich noch nen Bild von schwarzen Lungen oder viereckigen Augen.
Puh, Montag Morgen und schon DSGVO, das ist wirklich gesundheitsgefährdend.
Lieben Gruß
Stefan
PS. Das war entgegen meiner sonstigen Natur einmal eine sehr unqualifizierte Antwort. :-O
Servus,
man kann für die selbsterstellten Felder Positionen in den Template-Dateien der Kategorie oder Produktansicht anlegen.
Es gibt verschiedene voreingestellte Positionen. addtocart, normal, top, wenn ich mich recht erinnere.
Diese Aufrufe in der PHP-Datei finden, dann einen Aufruf mit einem anderen Positionsnamen einfügen. Zum Beispiel:
feldinkategorie, feldinprodukt.
So kann man unterschiedliche Felder unterschiedlichen Ansichten zuweisen. Wie dann die endgültige Zuweisung aussieht, ist dann von den eigenen Wünschen abhängig. Man könnte die Felder für die Produktattribute, die nicht in den Warenkorb sollen, z. Bsp. unter oder über die Produktbeschreibung setzen, oder in einen seitlichen Kasten.
Da sind dem Designer kaum Grenzen gesetzt.
Grüße
Stefan
