Beiträge von StefanSTS

Servus Helmut,

ich hatte vor einiger Zeit in einem Shop einen Core-Hack dazu gemacht. Der UVP wurde dazu als neues Feld in der Produktbearbeitung angelegt.
Somit kann man den normalen VM-Endpreis verwenden und den UVP als Zeichenkette darstellen.
Updates sind dann allerdings immer mit mehr Arbeit verbunden, weil die Dateien vom Update überschrieben werden.

Man könnte auch ein Custom Field dafür erstellen, ohne Core Hack, allerdings ist das Anlegen der UVPs im Produkt dann umständlicher (im letzten Reiter).

Eine weitere Möglichkeit wäre, die Sortieren-Funktion zu suchen, und dort nachzuschauen, wie die Werte da verarbeitet werden, aber auch das wäre wohl ein Core-Hack.

Der Möglichkeiten gibt es viele, aber es geht nicht per Knopfdruck.

Vielleicht baut iStraxx für eine VirtueMart Mitgliedschaft ja auch einen zusätzlichen UVP in den Core ein. Einfach mal fragen.

Grüße
Stefan

Servus,

ich hab den Link zum Shop mal rausgenommen.
Wenn Du Versionen postest, die gravierende Sicherheitslücken aufweisen, empfiehlt es sich, den Link nicht zu posten, da sich sonst freundliche Hacker daran machen, den Shop zu verschönern.

Ich schlage vor, Du aktualisierst die Seite erst einmal, und danach gehst Du das Problem mit dem Grundpreis an.

Der Grundpreis wird normalerweise in VirtueMart auch in der Kategorieansicht angezeigt. Das legt den Schluss nahe, dass das Template einen Override verwendet, der diesen ausblendet. Da müsste man in den Template-Code schauen.

Grüße
Stefan

Servus,

ich nehme an, das ist in Deinem Template als Override hinterlegt.

Popup:
Im Template-Ordner, dann /html/com_virtuemart/cart/padded.php. Ansonsten aus der cart view nehmen und einen Override erstellen.

Es könnte natürlich auch der OPC von CMS sein, den benutze ich nicht, weil der immer sehr buggy war. Dann kann wiederum alles anders sein. Da muss man dann genauer in den Code schauen.

Grüße
Stefan

PS. Der Link im Warenkorb scheint vom OPC zu kommen, einfach einmal den Quellcode des OPC unterhalb der Zeichenkette "header-OPC" durchsuchen.

Servus,

es würde sicher einfacher nachzuvollziehen sein, wenn es eine Testinstallation dazu gibt, in der man sich das anschauen kann.

Grüße
Stefan

Servus Thomas,

ein Joomla- oder VM-Update wird da nicht helfen.
Die Template-Overrides müssen geändert werden. Entweder hilft der Template-Hersteller, oder man muss es selbst machen, bzw. machen lassen.

Grüße
Stefan

Servus,

das kommt aus dem Sublayout customfield.php.
In VM 3.2.15.xx ist es in Zeile 744:
$otag = ' <span class="product-field-type-' . $productCustom->field_type . '">';

Da steckt das Leerzeichen vor dem <span ...
Wenn man es entfernt, passt es. Am besten einen Override im Template anlegen. Wenn es keine Nebenwirkungen gibt, kann ich es für den Core vorschlagen.

Die Erklärung ist einfach, im ersten Custom Field ist es in ein allumschließendes DIV eingeschlossen, das Leerzeichen ist nicht der Zeilenanfang und wird angezeigt.
In den folgenden Feldern folgt das Leerzeichen einem <br>, damit ist es Zeilenanfang und wird nicht angezeigt, weil bereits das "Leerzeichen" Zeilenumbruch angezeigt wird. Mehrere Leerzeichen hintereinander werden zu einem einzigen reduziert.

Grüße
Stefan

PS: Möglicherweise wäre ein &nbsp; am Anfang besser, damit die Einrückung für alle angezeigt wird, müsste man testen.
$otag = '&nbsp;<span class="product-field-type-' . $productCustom->field_type . '">';

PPS: Einfach rausnehmen sieht besser aus.

Servus,

ich weiß von einer 3.2.15, die noch etwas vor dieser .15 entstanden ist, die läuft auf einem ziemlich großen Shop erfolgreich.

Ob das auch für die veröffentlichte Version gilt? Ich würde sagen, die kritischen Dinge durchtesten und selbst entscheiden. Viele Bugs aus der .12 und .14 wurden dort behoben.
Ich würde fast vermuten, dass dort alles läuft.

Beim PHP bleibe ich immer noch auf 7.0.x für Live-Shops, da es noch einige Probleme mit 7.1 und 7.2 gibt/geben könnte. Auf den Testinstallationen ist 7.1 und 7.2 natürlich eine gute Wahl. Wenn dort etwas nicht mit rechten Dingen zugeht, freut sich das englische Forum über Bug-Reports, oder auch dieses Forum hier, wenn es lieber auf Deutsch sein soll. Wir leiten das dann weiter.

Grüße
Stefan

Servus,

wenn es mit einem anderen Template auch so ist, würde ich als erstes einmal ein Update auf 3.2.14 oder 3.2.15 in einer Spiegelung versuchen.
Wenn es dann nicht klappt, müsste man tiefer in die Installation schauen.

Es gab einige Veränderungen in der Rechnungserzeugung, bedingt durch die französiche Rechtsprechung, wenn ich mich recht erinnere.
Evtl. ist es ein Rechteproblem der ACL, das in der neuen Version zu tragen kommt.

Grüße
Stefan

Servus Franz,

aktuelle Versionen gibt es nicht. Schau mal hier:
Wie bekomme ich schnellstens hilfreichen Antworten

Hast Du PHP 7.2?
Schalte einmal auf 7.0.

Grüße
Stefan

Servus,

das war schon einmal im Gespräch, allerdings lagen die Prioritäten zu dem Zeitpunkt anders, wenn ich das richtig in Erinnerung habe.
Evtl. könntest du das bei iStraxx über eine VirtueMart Supporter Mitgliedschaft durchsetzen.

Einfach über virtuemart.net mit Max Kontakt aufnehmen und fragen.

Grüße
Stefan

Hallo Joe,

diese Konfigurationseinstellung hab ich vorgeschlagen, das Echo war allerdings nicht überwältigend positiv. Schau mer mal, wie der Australier sagt.
Die oben vorgeschlagenen zwei Zeilen im Override für die default.php der productdetails einzufügen ist ein "Fünf-Minuten-Ding", würde ich in Erwägung ziehen.

Von Olympianthemes kommt übrigens ziemlich bald ein Plugin heraus, dass genau diese Thematik anspricht. Evtl. lohnt es sich, ein wenig zu warten, bevor Du alle Produkte einzeln hierfür bearbeitest. Kommt auf die Anzahl der Produkte an. Falls ich Neuigkeiten zu dem Plugin höre, melde ich mich (und wenn nicht, bitte unregelmäßig noch einmal nachfragen, manchmal verschwinden Dinge aus der mentalen ToDo-Liste).

Grüße
Stefan

Servus Joe,

das ist leider fest im Core eingebunden.
In der components/com_virtuemart/views/productdetails/view.html.php in Zeile 257 findet sich dieses:

$document->setTitle(strip_tags(html_entity_decode($catName . $product->product_name,ENT_QUOTES)));

Ein Core Hack ist nicht schön, wäre aber folgender:

$document->setTitle(strip_tags(html_entity_decode($product->product_name,ENT_QUOTES)));

Man kann das title-Tag sicher auch in der default.php der productdetails-view neu setzen, dann könnte man einen Override setzen, dann braucht es sicher andere Variablen.

Auf die Schnelle
Stefan

PS. In der default.php der productdetails würde dies gehen, damit geht es auch per Override im Template, was definitiv zu bevorzugen ist.
$document = JFactory::getDocument();
$document->setTitle(strip_tags(html_entity_decode($this->product->product_name,ENT_QUOTES)));

Servus,

man kann beim Erzeugen der selbsterstellten Felder die Farbnamen verwenden, um Klassen für jede Option anzulegen.
Dann über CSS die Farben angeben.

Dazu muss man aber mit etwas mehr Zeit tiefer in den Code gehen. Das geht dann eher über das Unterforum "Kommerziell Jobs" oder über PM.

Grüße
Stefan

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