VirtueMart - Know How und Bugfixes

Details

Zuletzt aktualisiert: 11. April 2018

Wissenswertes zum Thema

Virtuemart nutzt zwei unterschiedliche Wege für die Anzeige des Pathways.

• für die Browsepages nutzt es den regulären Weg, so wie er vom Joomla-Framework vorgesehen ist. Über das Objekt $mainframe mit seiner Methode appendPathWay() lassen sich dem Mainframe Pfad-Element übergeben/anhängen. Alle diese Elemente werden in einem Array gesammelt. Das Modul mod_breadcrumbs verwendet dieses Pfad-Array um daraus dann den Pathway zu erzeugen und an Modulposition auszugeben. Die Konfiguration der Anzeige dieses Pathway erfolgt folglich auch über das Modul / J!-Main-Template-Modulposition und dann projektweit. Will man also die Anzeige für diesen pathway ändern, muss man ins Modultemplate-Script modules/mod_breadcrumbs/tmpl/default.php.
• Aus unerklärlichen, vermutl. rudimentären Gründen, wird das auf den Produktdetailseiten (flypages) nicht so gehandhabt. Zusätzlich zum Modul-Breadcrumbs kann man hier eine weitere Pfadanzeige veranlassen. Für die Flypage-Templates unter /product_details/ gibt es im Templateverzeichnis /common/ eine pathway.tpl.php, welche auf diesen Seiten die Pathway-Ausgabe formatiert. Die Konfiguration der Anzeige erfolgt hier über die VM-Backend-Konfiguration auf den Flypage-Einstellungen. Hier ist das An- und Abschalten möglich. Das Aussehen wird über das Template pathway.tpl.php gesteuert. Sinn macht das allerdings nicht, weil man dann mitunter die Pfadanzeige doppelt hat, einma über das Modul an Modulposition und zusätzlich innerhalb des Flypage-Inhaltes für das Produkt.

Weiterlesen: Pathway / Breadcrumbs in VirtueMart 1.1.x

Details

Zuletzt aktualisiert: 11. April 2018

Problembeschreibung

Leider ist es in der Version bis zur 2.0.18 so, dass nicht alle Elemente von VirtueMart konsequent multilanguage-fähig sind. So z.B. die Custom-Fields (selbsterstelle Felder). Während für die Bezeichnung der Felder die Übersetzungen noch funktionieren, sind die Benennung der Selektions-Options nicht über das Joomla-Language-Overriding beschreibbar. Statt dessen wird hier ausschließlich mit den eingegebenen Values der Felder gearbeitet. Ganz sicher wird das in einer der nächsten Versione von VM erfolgen, doch derweil muss man sich im Notfall selbst behelfen.

Dieser Workaround soll beschreiben mit welchen Maßnahmen das zu erreichen ist. Es ist aber zu beachten, dass dieser Workaround Eingriffe in den Core von VM bedeuten. Man soll sich also zum einen mit php einwenig auskennen und sich bewusst sein, was Core-Eingriffe für Nachteile mit sich bringen können. Wer sich unsicher ist, Finger davon lassen, Profi machen lassen oder warten bis es mal Core-Bestandteil ist.

Weiterlesen: Mehrsprachigkeit von VM 2 Custom-Fields

Details

Zuletzt aktualisiert: 11. April 2018

Einiges Grundwissen zum Thema Rechenregeln

Virtuemart nutzt für seine eingebundenen Plugins auch die Schnittstelle von Joomla, folglich sind Plugins auch im Joomla-Pluginverzeichnis zu finden.
Für die Kalkulation von MwSt., andere Rechenregeln und die Währungsumrechnungen wurde u.a. das Avalara-SDK/API eingebunden, welches eine PHP-Script-Class/Bibliothek ist.
Die Rechenart für Discount/Rabatte ist Preismodifikator vor Steuern (intern DBTax).

Wann eine Rechenregel überhaupt angewendet werden soll, lässt sich standardmäßig durch vier Kriterien definieren welche sind:

• Produktkategorien (category)
• Shoppergruppen (shoppergroup)
• Land (country)
• Bundesland/Staat (state)

Diese vier werden nachfolgend nur noch als Kriterien bezeichnet. Für diese ist immer eine Mehrfachauswahl mgl.

Leider gibt es kein Kriterium um Produktpreise herstellerabhängig zu machen. Das ist schade, denn eigentlich nicht gerade unüblich in der kaufmännischen Praxis, denn gibt z.B. ein Hersteller zeitweilig Rabatte, möchte man diese Verkaufsförderung evtl. an Kunden weitergeben. Das Thema kann auch interessant sein, wenn man von herstellerbezogenen Listenpreisen abweichen will.

Weiterlesen: Internas zu Rabatt-Rechenregeln in VirtueMart 2 - Erweiterung herstellerabhängiger Rabatt

Details

Zuletzt aktualisiert: 11. April 2018

Korrekte Initialisierung von VM im Shop-Frontend

Es ist ganz wichtig, dass VirtueMart 2 korrekt initialisiert und somit in das Joomla-Framework eingebunden wird. Leider ist das mit einer einfachen Installation von VirtueMart nicht gleich gegeben. VirtueMart ansich funktioniert dann zwar grundsäztlich, aber es gibt diverse Feature, speziell von anderen Joomla-Erweiterungen (z.B. Sitemaps, div. Module, Suchfunktionen usw.), die erst dann korrekt funktionieren. Bei der Initialisierung geht es im Kern darum, dass Joomla-Erweiterungen in der Lage sind VirtueMart zu finden, so dass deren Produkte und Kategorien gelesen werden können. Das geht zum einen nur dadurch, dass Virtuemart im Hauptmenü eingebunden ist und zum anderen dieser Menüeintrag vom richtigen Typ ist.

Konkret sieht es so aus, dass wir im Mainmenu eine Virtuemart-Komponenten-Eintrag einbinden der auf den Type Kategorie-Layout verweist. Ich möchte nicht beschwören, dass der Menüeintrag auch in ein anderes Menü erfolgen kann, aber ich bin mir sicher, dass es exakt dieser Menütyp sein muss. In der Typ-Auswahlliste steht er bezeichnet als Kategorie Layout. In der Liste der Menüeinträge eines Menü steht in der Spalte Menütyp dann VirtueMart » Kategorie Layout. Es sollte die unterste Shop-Kategorieebenen gewählt werden.

Bedeutung diverser VirtueMart 2 Template-Scripte

Nachfolgend eine Aufstellung der Views-Scripte von VirtueMart 2. Diese Scripte befinden sind alle in Unterverzeichnissen von components/com_virtuemart/views/. In den dortigen Unterverzeichnissen gibt es dann immer ein Verzeichnis /tmpl/ und den darin befindlichen üblicherweise default.php und/oder default_teiltemplate.php heißenden Scripten. Jedes dieser Scripte ist verantwortlich für die Darstellung eines Shopbereiches oder einer einzelnen Shopfunktion. Gegliedert sind diese zusätzlich für die Shopbereiche in Unterverzeichnisse.

Entspr. des MVC-Models, welches in Joomla! und VM 2 umgesetzt ist, sind das die Viewbestandteile der Komponente und unterstützen damit auch konsequent das Template-Overriding von J!. D.h., jedes hier vorhandenen Scripte kann zusammen mit seinem Unterpfad in das Verzeichnis templates/Ihr-Template/html/com_virtuemarte/ kopiert werden. Dort kann es nach eigenen Wünschen und Bedürfnissen modifiziert werden, ohne Angst haben zu müssen, dass ein späteres VM-Update diese Templatescritpe überschreibt. Nebenbei: Man könnte das Oberriding von Joomla auch ignorieren und statt dessen kann man für einige default.php-Scripte auch anders benannte Scripte im gleichen Verzeichnis ablegen. In der Shop-Konfiguration könnte man dann statt der default-Style diese anderes benannten Style-Scripte zuweisen. Das ist jedoch nicht ganz konsequent und die Struktur des Template-Overridings ist transparenter.

Weiterlesen: Die Views-Scripte von VirtueMart 2

Details

Zuletzt aktualisiert: 11. April 2018

Zielstellung

In diesem Artikel geht es darum, den modalen Meldungdialog von VirtueMart 2, der den Erfolg oder Mißerfolgt des Hinzufügens von Produkten zum Warenkorb anzeigt, zu modifizieren. Die Modifikationen betreffen hauptsächlich das Erscheinungsbild, um diese dem Template-Design anzupassen und die Reihenfolge der Dialogbestandteilinhalte umzustellen. Hiervon betroffen sind jedoch auch Core-Scripte. Das sollten also nur versierte Scripter machen und immer in dem Bewußtsein, dass jedes Upgade von VM diese Änderungen wieder überschreiben könnte. Das widerum ist für die avisierten Ziele unvermeidlich, weil die jeweiligen Scripte nicht über das Template formatiert werden können, so wie für viele anderen Scripte von VM typisch.

Grundlagenwissen

Die drei wichtigen Scripte um die FaceBox zu ermöglichen, sind zum einen das jQuery-Script components/com_virtuemart/assets/js/facebox.js und das Server-Gegenstück, welches dieses Script mit Meldungen versorgt und die Cart-Aktion ausführt components/com_virtumart/controllers/cart.php - konkret mit seiner Methode addJS(). Weiterhin gibt es das VirtueMart-Price-JavaScript components/com_virtemart/assets/js/vmprices.js, welches die FaceBox aufruft und dabei den per json gelieferten Content mit den Buttons (datas.msg) und die Produktbezeichnung aus dem Formular-Hiddenfeld pname als Meldungsinhalt zusammenbaut.

Weiterlesen: VirtueMart 2: Kleine Modifikation in der FancyBox-AddToCart-Meldung

Details

Zuletzt aktualisiert: 11. April 2018

Die Einstellungsparameter für das VirtueMart-Projekt werden unter VM 2.x nicht mehr in einem Configurations-Php-Script gespeichert sondern in einer Datenbank-Tabelle. Das hat einige Vorteile und ist sehr zu begrüßen. Verantwortlich ist die Tabelle #_virtuemart_configs. Hierin gibt es das entscheidende Feld config in dem die Parameter serialisiert abgelegt sind.

In der nachfolgenden Aufstellung solle die Parameter und Ihre Bedeutung zusammengetragen werden. Die Liste ist nicht vollständig, wird aber Stück für Stück wachsen. 

Als Trennzeichen zw. den Daten wird der Pipe "|" (in der Aufstellung entfernt) verwendet. Abgeschlossen wird jeder Parameter mit ";" (wie in der Aufstellung zu sehen).

Weiterlesen: Die Konfigurationsparameter in der VirtueMart-Configs-Tabelle

Details

Zuletzt aktualisiert: 11. April 2018

Zielsetzung und Problembeschreibung

Zunächst einmal die Beschreibung, was passiert soll: Wenn der Nutzer auf den Link „Warenkorb löschen" im Mini-Cart-Modul klickt, dann wird die aktuelle Seite auf der sich der User gerade befindet verlassen um die Warenkorb-Löschen-Seiten anzuzeigen. Nach Bestätigung der Löschabsicht erfolgt das Leeren des Warenkorbes und der User soll dann wieder zurück auf seine ursprüngliche Seite geleitet werden, von wo aus der im Modul den Warenkorb-Löschen-Link betätigt hatte.

Prinzipiell könnte man die Löschaktion auch über eine Ajax-Funktion ausführen und die Bestätigungsabfrage und ggf. Erfolgsmeldung in einem modalen Dialog anzeigen, dann könnte man sich die Rücksprungaktivitäten sparen. In unserem Fall soll dies abe über eine separate Seiten erfolgen. Das wiederum ist dann aber nicht so einfach, weil der Server die Information verarbeiten muss, von wo der User ursprünglich kam.

Hierbei gibt es weiterhin eine Besonderheit zu berücksichtigen. Solange wir komplette Seiten aufrufen, ist dem Server auch immer über die REQUEST_URI die Ursprungsadresse bekannt, so dass auch bei Anzeige des Warenkorb-Moduls die Rücklinkinfos abgefragt und weitergegeben werden können. Anders wenn der Warenkorb per Ajax aktualisiert wird, z.B. wenn ein Produkt zum Warenkorb per Ajax-Request hinzugefügt wird.

Weiterlesen: Rücksprung zur Ausgangsseite nach Warenkorb-Löschen in VirtueMart 1.1.x

Details

Zuletzt aktualisiert: 11. April 2018

Anwendungsmöglichkeit / Beschreibung

Bei diesen Produkten geht es um die Typische Beziehung von Produkte und Artikeln, oder, wem diese Benennung aus VM 1.x noch bekannt ist, um Parent-Produkte und Child-Produkte.

Auch hier ein Beispiel anhand dessen erkennbar ist, mit welcher Absicht man diese Produktattributisierung einsetzen sollte:

Sie wollen Schrauben verkaufen. Typische Merkmale der Schrauben sind die Verwendungsart (Holz, Metall, Kunststoff), die Kopfform (Senk-, Halbrund-, Linsen-), die Bit- oder Stecköffnung (Schlitz-, Kreuz-, Torx-, Innensechskant-), evtl. der Güte (Normal, Niro ...) oder der Gewindeart (Normal, fein, ...). Darüber definieren wir i.d.R. das Produkt "Schraube", auch weil wohl üblich ein Bild und eine gemeinsame Beschreibung genügt, um eine so klassifizierte Schraube optimal zu charakterisieren. Anders ist es aber mit der Länge und der Gewindegröße einer Schraube. Auch hierin unterscheiden sich Schrauben, aber es bleibt für uns ein Produkt. Im Baumarkt liegen quasi alle Schrauben mit o.g. Merkmalen in einem Regalbereich, aber getrennt in Schachteln nach iher jeweiligen Größe.  Wir untergliedern also das Produkt Schraube noch einmal, weil wir für jede dieser Schraubengrößen nicht nur separate Preise haben, sondern ggf. separate Bestände, Gewichte, Verpackungseinheiten etc. Die sich so ergebenden Artikel sind in der Regel so auch in unserem Warenmanagementsystem geführt - eben mit eigenen Beständen für den Ein-/Verkauf etc. In unserem Shop ist die Schraubenart dann unser Parentprodukt (Regalbereich) und die Schachtel getrennt nach Größe unsere Artikel.

Weiterlesen: Virtuemart 2: Nutzerfelder mit Bestandskontrolle

Details

Zuletzt aktualisiert: 11. April 2018

Dieser Artikel wurde verschoben.

Bitte besuchen Sie statt dessen die neue Zielseite:

Virtuemart 2: Nutzerfelder ohne Warenkorb-Attribut / Produktvarianten / mit Warenkorb-Attribut / Child-Produkte

{jcomments off}

Details

Zuletzt aktualisiert: 11. April 2018

Anwendungsmöglichkeit / Beschreibung

Angenommen Sie haben Produktgruppen, die typischerweise immer den gleichen Strukturaufbau haben sollen. Zu jedem dieser Strukturdaten sollen Informationen erfasst und angezeigt werden. Beispielsweise haben Sie verkaufen Audio-CD's. Diese haben ja i.d.R. ihren festen, nicht "konfigurierbaren" Preis. Aber die Informationen die zu jeder CD bereitgestellt werden sind immer die gleiche: Album, Interpret/Gruppe, Erscheinungsjahr, Label, Genre etc. Bei diesen beschreibenden Attributen wird dem Seitenbesucher im Produkt kein Auswahl angeboten. Jedoch wäre es denkbar, dass er alle Alben eines bestimmten Interpreten suchen will, oder eines bestimmten Genres. Dafür wäre strukturierte Daten noch obigen Schema notwenig.

Wer schon mit VM 1.x gearbeitet hat, wird dies bekannt vorkommen von den dortigen Produkttypen.

Erstellen und Anwenden von Produktvarianten ohne Warenkorb-Attribute

Prinzipiell gibt es zwei sich wiederholende Schritte. Sie müssen so viele Attribute anlegen wie Sie brauchen. Dann weisen Sie den Produkten dies Attribute zu und befüllen diese mit den konkreten Inhalten.

Weiterlesen: Virtuemart 2: Nutzerfelder ohne Warenkorb-Attribut / Produktvarianten / mit Warenkorb-Attribut /...