Sehr schön,
der neue Schalter war mir auch entgangen. Da hab ich mich aufs Glatteis führen lassen.
Falls jemand Selbsterstellte Felder mit Preisänderung oder weitere Regeln für Produkte verwendet, und der Endpreis dadurch verändert werden soll, ist der Override-Preis allerdings nicht zu gebrauchen.
Dazu habe ich vorhin ein kurzes Tutorial geschrieben.
https://www.jooglies.com/tutor…-rechenregeln-fuer-rabatt
Hope it helps
Stefan
Servus,
ich bin auch nicht unbedingt glücklich mit der Entscheidung, dass dieses Feld nicht mehr angezeigt wird.
Es wird zumindest ein Feld "UVP" oder "alter Preis" benötigt, der festgelegt werden kann. Hier sollte auch die Berechnung des Preisnachlasses mit einfließen, damit man nicht durch die Schmerzen eines verschwundenen Features muss.
In der Vergangenheit haben meine Kunden öfter das Feld EAN oder MPN zweckentfremdet, um den UVP anzuzeigen.
Die Funktionalität des "durchgestrichenen Preises" steht übrigens weiterhin zur Verfügung. Die Templates müssen dazu nicht geändert werden.
Wer das mit Regeln ausprobieren möchte, kann das gerne am Beispiel von Flix versuchen.
1. "Nicht veröffentlichte" Kategorie "Rabatt 10 Euro" erstellen.
2. Rechenregel "Regel Rabatt 10 Euro" (Preismodifikator nach Steuern, - , 10 ) erstellen und der Kategorie aus 1. zuweisen.
3. Kategorie aus 1. im Produkt zuweisen.
Das ist im Grunde alles, um die Funktionen des Override-Preises zu ersetzen. In jedem gewünschten Produkt kann nun eine Rabatt-Kategorie hinzugefügt werden.
Der Vorteil dieser Methode ist, dass nun auch Selbsterstellte Felder mit Preisanpassungen funktionieren. Das ging mit dem Override-Preis nicht, ein Grund, warum er ganz verschwinden soll.
Hat man jetzt
- ein Produkt Pizza Hawaii 7 Euro reduziert auf 5 Euro,
mit einer Option "Extra Käse + 1,00 Euro",
kostet die Pizza mit extra Käse 6 Euro.
Mit dem Override-Preis hätte sie 5 Euro gekostet, weil der Override-Preis "alles" überschrieben hat.
Grüße
Stefan
PS. Ich mache da einmal ein Tutorial zu.
Hallo Martin,
da liegen leider die Stärken und die Schwächen von Joomla. Nur wenn man Menüeinträge erstellt, können Module eindeutig zugeteilt werden.
Deshalb habe ich für die Hauptkategorien von VM immer Menüeinträge, Alle darunter liegenden Submenüs müssen dann nicht unbedingt einen Menüpunkt haben.
Ohne Menüeinträge bleibt wohl wirklich als einfachste Selbstbau-Lösung dann nur, Module direkt in der Startseite mit loadposition zu laden.
Nur begrenzt sich das dann halt auf den Bereich, der für die Komponente vorgesehen ist.
Oder man muss mit einem externen Plugin wie Modules Anywhere von Regular Labs arbeiten.
Grüße
Stefan
Servus,
evtl. werden jquery un jquery-ui nicht in der richtigen Reihenfolge geladen.
Möglicherweise gibt es eine externe Erweiterung, die jQuery noch einmal lädt oder dergleichen.
Vielleicht einmal in der Liste der Erweiterungen schauen, was dort installiert ist, und externe Plugins, Module usw. deaktivieren.
Im Quelltext im HEAD-Bereich der Seite einmal nach jquery und jquery-ui schauen.
Welche VM-Version wird genutzt?
Die 4.0.12 gibt es hier: https://dev.virtuemart.net/projects/virtuemart/files
Grüße
Stefan
Servus,
ich habe das gerade unter Joomla 3.10.11 und 4.2.6 versucht. Bei mir klappt das in beiden Fällen mit Chrome unter Linux.
Vielleicht einmal mit F12 in die Browserkonsole schauen und überprüfen, ob irgendwo das JavaScript nicht richtig geladen wird.
Grüße
Stefan
Auf der VM-Startseite kann ich keine Module platzieren, die nur dort und sonst nirgends im Shop ausgegeben werden.
Wenn man einen Menüeintrag für die Startseite als VM-Kategorie der höchsten Ebene angelegt hat, kann man diesem Menüeintrag Module zuweisen.
Darunter gelegene VM-Kategorien benötigen dann ebenfalls einen Menüeintrag. Dort werden die Module nicht veröffentlicht.
<?php echo JHtml::_('content.prepare', '{loadposition test}'); ?>
Dieser Test scheint zu funktionieren. Muss das aber noch mit der Mehrsprachigkeit austesten...
Dies ist eine Lösung, wenn man innerhalb einer Komponente Positionen anlegen möchte. In den Produktdetails habe ich das schon einmal verwendet. Das wird aber sehr selten verwendet, weil man dazu PHP-Dateien bearbeiten muss. Mit allen Vor- und Nachteilen.
Grüße
Stefan
Hallo Martin,
Module werden in deren Einstellungen im Reiter Menüzuordnung entsprechenden Menüeinträgen zugewiesen. Das ist eine ganz normale Joomla-Technik. Da findet Google sicher etwas Schlaues zu. Da muss man kein PHP schreiben.
Grüße
Stefan
Servus,
vielleicht fehlt in der neuen Version im Aufruf irgendwo die Klasse, auf die das Skript zur Berechnung zugreift.
So etwas ist schwer ohne Blick in den Code zu beurteilen.
Grüße
Stefan
Servus,
wenn es ohne Rechenregeln sein soll, würde ich einfach ein Selbsterstelltes Feld anlegen, das den alten Preis angibt, und den neuen reduzierten Preis als "normalen" Preis angeben.
So mache ich das in einigen Fällen seit Jahren. Das ist einmal eingerichtet auch nicht schwieriger als der Override-Preis.
Leider gibt es noch keine Möglichkeit, ein Selbsterstelltes Feld (alter Preis/UVP usw.) im ersten Reiter anzuzeigen, da muss man leider auf den letzten Reiter umschalten, in dem der "durchgestrichene alte" Preis angegeben werden kann.
Natürlich kann man sich da auch selbst etwas umbauen, wenn es komfortabler sein soll. Oder ein Crowdfunding anstoßen, damit es da eine schöne Lösung geben kann.
Wie ich Max verstanden hatte, wird der Override-Preis nicht mehr in die Grundeinstellung kommen. Kann ich auch verstehen, der Override-Preis sollte nicht in den Feldern stehen, in denen wirklich etwas berechnet wird. Da sind Selbsterstellte Felder sinnvoller, die nicht an die Rechenregeln gekoppelt sind. Der Override-Preis hat in der Vergangenheit bei komplizierten Preisberechnungen sehr oft Ärger gemacht.
Ich würde in diesem Zusammenhang auch einen Blick auf die gesetzliche Regelung werfen, die vor kurzem in Kraft getreten ist. Dort gibt es Vorgaben, welchen "alten Preis" man überhaupt angeben darf.
Kurz noch einmal, eine vielseits genutzte Lösung:
1. Selbsterstelltes Feld "UVP/alter Preis" als Zeichenkette anlegen.
2. Neuen Preis an der Stelle des alten Preises angeben.
Für den UVP kann man evtl. eine neue Position im Template anlegen, falls "addtocart" oder "normal" nicht passt.
Fertig.
Wer es komplizierter möchte, kann es wie weiter oben beschrieben mit Regeln und (unveröffentlichen) Steuerungs-Kategorien machen.
Grüße
Stefan
[Update] Siehe unten Milbos Kommentar. Es gibt eine neue Einstellung in der VM-Konfiguration im Reiter Preise. Expertenpreise anzeigen. Dort kann man den Override-Preis wieder einschalten.[/Update]
Servus,
Das Überschreiben-Feld hat viele ungewollte Nebenwirkungen und ist eine Altlast aus, ich glaube, VirtueMart 1.
Zum Beispiel wurde bei Selbsterstellten Feldern ein verändernder Wert nicht berücksichtigt.
Das System wurde schon zu VM 2 auf Rechenregeln erweitert. Das Überschreiben-Feld wurde aus Gründen der Rückwärtskompatibilität behalten.
[Update]
Zu VM 4 wurde dieses Feld in der Grundeinstellung nun aus dem neuen Admin-Template entfernt. Man kann es weiterhin über die VirtueMart-Konfiguration im Reiter Preise über Expertenpreise einschalten.
[/Update]
Ich empfehle in vielen Fällen, die entsprechenden Rechenregeln anzulegen, mit einer versteckten Kategorie zu verknüpfen, und diese versteckte Kategorie dann im Produkt zuzuweisen.
Dann werden auch alle Berechnungen richtig durchgeführt.
Das mag am Anfang sehr viel komplizierter aussehen. Wenn man sich erst einmal daran gewöhnt hat, hat diese System jedoch viele Vorteile.
Grüße
Stefan
Den J4/VM4-Shop habe ich inzwischen in eine Testumgebung gelegt, ich war so sicher dass das problemlos funktioniert, dass ich am Live-Shop gearbeitet habe.
Das VirtueMart Team und meine Wenigkeit empfehlen weiterhin, noch mit Joomla 3 zu arbeiten.
Ich hatte an einigen Stellen im Forum berichtet, wie die neuen Joomla-Versionen VM-Funktionen plötzlich abgeschaltet haben.
Diese Rückwärtskompatibilitätsbrüche finden am Anfang der Entwicklung von neuen Joomla-Versionen immer statt.
Die Lehre aus der Vergangenheit ist, warten, bis der Neuerungsdrang in Joomla aufhört. Dann erst aktualisieren.
Die Shops meiner Kunden laufen weiterhin auf Joomla 3. Die ersten Shops werden im ersten bis zweiten Quartal 2023 auf Joomla 4 umgestellt, wenn die Entwickler sich auf Joomla 5 konzentrieren und Joomla 4 für über 2 Jahre Sicherheitssupport erhält.
Bisher ist Joomla 3 ein stabiles und sicheres System, weil keine Entwicklung mehr stattfindet.
Der offizielle Support läuft erst im August 2023 aus. Vorbereiten sollte man sich natürlich darauf, allerdings wurden auch damals für Joomla 2 vom VM Team noch Sicherheitsupdates für Joomla 2.5.28 zur Verfügung gestellt, obwohl der offizielle Support schon lange ausgelaufen war.
Damals hatte sich bewährt, lange auf Joomla 2.5 zu bleiben. Man erinnere sich an den kritischen Fehler in Joomla 3.6. Die Shops unter Joomla 2.5.28 blieben sicher.
So wird sicher auch niemand im Regen stehen gelassen, der länger auf Joomla 3 fährt. Irgendwann ist natürlich Schluss mit Sicherheitsupdates, aber nicht am Tag nach Ende des offiziellen Supports durch die Joomla Entwickler.
Deshalb, vor Ende des offiziellen Supports das Update auf Joomla 4 planen und schon jetzt ausgiebig testen, aber wenn es etwas länger dauert, ist man nicht gleich in einer kritischen Sicherheitslage.
Es gibt öfter Rufe, dass Joomla 4 schon lange stabil ist, die gab es schon ziemlich bald nach dem ersten Release. Bitte nicht auf diese Rufe hören, das mag für eine Visitenkarte einer Zahnarztpraxis gut genug sein, dafür würde ich auch Joomla 4 nehmen, VirtueMart braucht aber eine stabile sichere Grundlage, und die ist im Moment noch Joomla 3, vielmehr als Joomla 4, das sich noch zu stark weiterentwickelt.
Grüße
Stefan
Ps. Klappt es, wenn das modale Popup-Fenster in der VM-Konfig eingeschaltet wird?
Und einseitiges Auschecken aktiviert -> Ja.
STS
Das Geheimnis zu den News ist einfach erklärt. Eigentlich war die News zu VM 4.0.8 geplant, der Newsbeitrag war wohl schon angelegt.
Dann gab es noch einige Dinge, die geändert werden mussten, so dass die News wohl erst zu VM 4.0.12 herauskamen.
Man sieht es am Link "4-0-8", Überschrift ist aber 4.0.12.
Das Datum der Veröffentlichungen von VM 4.0.12 stimmt mit dem von https://dev.virtuemart.net/projects/virtuemart/files überein.
Demnach kam VM 4.0.12 am 20.12.2022 heraus.
Falls nach einer erneuten Installation aller einzelnen Paket dieser JRequest-Fehler immer noch auftaucht, sollte in der Joomla-Konfiguration Joomla Debug eingeschaltet werden, so dass es einen Stack Trace gibt.
Diesen hier als Text posten, dann findet sich der Fehler sicher.
Grüße
Stefan
Die "virtuemart_manufacturercategories" Tabelle (oder wie das heißt) ist in der Datenbank da, heißt aber anders (siehe Screenshot bitte)
Außerdem habe ich keine vm-Einträge in der datenbank entdeckt (siehe auch Screenshot bitte).
Die Sache ist die, dass die Kundin die Bilder immer synchronisiert und die Hinweis-Fehlermeldung irritiert/stört. Außerdem denkt sie es stimmt was mit dem System nicht.
Die Tabellen scheinen alle in Ordnung zu sein.
Wenn dieser Fehler
1146 Table 'd03ba0e7.mkp0i_vm_manufacturer_category' doesn't exist
nur kam, als Du auf Migration geklickt hast, ist das ok, das sollte in einem laufenden Shop nicht angeklickt werden.
Max wird das zur nächsten Version hin wohl rausnehmen, weil das sowieso nur für die Migration von VM1 zu VM2/3 gedacht war.
Wie man an der Meldung erkennen kann, ist da ein (i) Zeichen, eine Information, kein Fehler.
Die Fehlermeldung müsste halt geändert werden.
Kauf dem Max mal eine Support-Mitgliedschaft ab, dann kümmert er sich um solche Kleinigkeiten schneller. Im Moment stehen noch andere wichtige Änderungen zu PHP 8.2 und Joomla 4 an, deshalb arbeitet er nach Prioritätenliste. Probleme von Support-Mitgliedern wandern auf der Liste nach oben.
https://extensions.virtuemart.…pporter-membership-detail
Grüße
Stefan
Hallo Flix,
hier gibt es die VM-Dateien.
https://dev.virtuemart.net/projects/virtuemart/files
Es gibt immer eine ..._package_or_extract.zip.
Dort sind einzelne Pakete enthalten, die man über den Joomla Erweiterungsmanager wie andere Erweiterungen installieren kann.
Grüße
Stefan
/administrator/index.php?option=com_virtuemart&view=updatesmigration
Servus,
die "Fehler"meldung verwendet einen verwirrenden Text.
Die Information/Meldung zeigt, wieviel Ausführungszeit und Speicher zur Verfügung steht.
Das müsste aussagekräftiger gelöst werden.
Start with a new migration process and setup log maxScriptTime 54 maxMemoryLimit 507
->
"Start with a new migration process and setup"
-> Der Synchvorgang wurde abgebrochen, starte den Vorgang erneut!
log maxScriptTime 54 maxMemoryLimit 507
"log" deutet darauf hin, dass die Werte über den Server ermittelt wurden.
-> Du hattest ein max. Ausführungszeit von 54 sek und 507 MB Speicher. Da der Vorgang abgebrochen wurde, könnte es an zu geringen Werten liegen. Diese Werte kann man am Server einstellen.
Im Grunde fehlt hier auch eine Unterscheidung, ob es ein Fehler war, oder ob das immer zur Information eingeblendet wird.
Die Information kann helfen, wenn die Mediensynchronisation zwischendurch aufhört, wenn zuviele Medien vorhanden sind und der Serverspeicher oder die Ausführungszeit nicht ausreichen.
Im Grunde ist diese Fehlermeldung/Information für diese Art Abbruch.
"Dein" Fehler ist im Grunde nur, dass eine Datenbanktabelle nicht gefunden werden kann.
Die Fehlermeldung/Information zum Speicher scheint bei jedem Abbruch/Durchlauf zu kommen, ist in Deinem Fall aber irrelevant.
Diese Fehlermeldung sehe ich in meiner Testinstallation nicht, es gibt auch keine Tabelle xyz_vm_xyz. Die heißen original alle _virtuemart_ nicht _vm_.
Hast Du evtl. eine Erweiterung, die auf die Mediendateien zugreift?
Grüße
Stefan
Servus,
ich kann das Problem in meiner Installation mit Cassiopeia nicht reproduzieren.
Vielleicht ist es nur eine Einstellung in der VM-Konfiguration.
Ein Screenshot des Reiters Checkout könnte helfen.
Gibt es Overrides für VirtueMart in dem Template?
VirtueMart 4.0.12.10777 ist die "aktuelle" Version, die auch unter dev.virtuemart.net zu finden ist. Diese Versionen sollten gleich sein. Wo kommt denn die andere 4.0.12.10777 her?
Grüße
Stefan
Es gibt zwei Sprach-Ordner für Site und zwei für Admin in Joomla.
Site:
/language/
/components/com_virtuemart/language/
Ich vergesse immer, welche Reihenfolge Joomla wählt.
Gibt es evtl. den Ordner
/components/com_virtuemart/language/de-DE?
Den Ordner de-DE dort einmal löschen oder umbenennen. Vielleicht werden da alte Dateien aus dem Komponenten-Ordner geladen.
Den Sprach-Debug in der Joomla-Konfiguration einschalten kann auch helfen.
Grüße
Stefan
Servus,
das ist eine bekannte Änderung in PHP 8. Bis PHP 7.4 wurden Zeichenketten wie "12" in Berechnungen als Zahl behandelt, bei PHP 8 muss die 12 aber vom Typ Integer sein. Für unser Auge mag das eins sein, für PHP 8 nicht.
VirtueMart verwendet z. Bsp. inzwischen die Funktion VmConfig::getInt() für Werte, die über die VirtueMart-Konfiguration kommen.
Das ist in den VMuikit-Overrides evtl. noch nicht geändert und könnte so angepasst werden. Vielleicht hilft auch ein Update von VMuikit.
Grüße
Stefan
