Beiträge von jooomlaa

    Hallo Stefan, besten Dank für Dein Feedback.

    Ja, Joomla 4 lässt echt auf sich warten. Schon in 2019 hatte ich Kundenaufträge für J!-Neuprojekte, die ich vertröstet hatte auf die neue Hauptversion - damit nicht kurz nach Launch eines 3er-Projektes gleich wieder Kosten für 'ne Migration anfallen würden. 2 Kunden habe ich verloren, weil die nicht mehr länger warten wollten. Wenn ich nur gewusst hätte, dass die 4er noch so lange brauchen würde von Beta in produktiv... Grrh!


    Ja, Deine o.g. Fehler hatte ich auch gesehen und dann abgebrochen. Ist wohl doch nicht mit ein paar kleinen Anpassungen zu stemmen.


    Ich habe noch keine Erfahrungen bzgl. einer API-Programmierung. Wird jetzt das erste mal sein. Bin mir nicht mal sicher ob es überhaupt Sinn macht, sich da auf die Joomla-API stützen zu wollen, oder ob ich die nicht komplett autark nur für VM mache. Wenn J!4 noch so lange brauchen wird und dann erst noch VM adaptiert werden muss, ist vermutlich auch meine Zielzeit überschritten. Langsam reift der Verdacht, dass es doch sinnvoll ist, unter J!3 zu beginnen.


    Bei der API werde ich mich weitgehend daran halten wie es Xentral und Shopware handhaben. Xentral-seitig werde ich die Class vermutlich zu 100% übernehmen und VM-seitig die API entsprechend passend stricken. In meinem Projektfall bringt das Vorteile für die Updatefähigkeit.

    Bin mir nicht sicher, wo ich diese Frage thematisch abkippen soll. Hoffe hier passt es und wird auch gefunden/beachtet. Evtl. wäre es auch an der Zeit eine neue Kategorie für "VM unter Joomla 4" zu kreieren.


    Nun zu meinen Fragen:


    Ich soll für das ERP "Xentral" eine Shop-Anbindung realisieren. Als Joomla-Fan und VM-Krieger, möchte ich gern auf dieser HomeBase bleiben. Xentral hat schon einige Importer als Module an Board, um damit die Shopanbindung zu realisieren (Shopware, WooCommerce etc.) - leider nicht für Joomla / VM. Diese Importer-Module nutzen dabei die API's von z.B. Shopware oder WooCommerce. In ähnlicher Weise möchte ich verfahren, um nah am Xentral-Konzept bleiben zu können. Allerdings bietet weder Joomla noch VM eine solche API. Nun habe ich gelesen, dass Joomla4 zumindest eine API an Board haben wird. Ich bin nun geneigt, diese Joomla-API auf VM zu erweitern. Dazu wollte ich gern mal VM unter Joomla4 installieren, um eine entsprechende Spielwiese aufzubauen. Max hatte mir bestätigt, dass es solche laufenden "Installationen/Projekte" schon gibt. Nun, meine Tests ein solches Projekt aufzusetzen scheitern ("Interface 'JObservableInterface' not found on vmtable.php on line 35").


    Frage: Hat jemand schon Erfahrungen diesbezüglich oder ein solches Projekt evtl. als Package?

    Frage: Wie genau ist der Stand VM mit/unter Joomla!4 ? Ich kenne dazu die generellen Aussagen der Core-Entwickler, dass man es da langsam angeht. Ist für mich auch nachvollziehbar.

    Ich rechne bei meinem Projekt eh mit ca. 6 Monaten bis zum Live-Gang. Bis dahin sollte Joomla 4 produktiv eingesetzt werden können und auch VM andocken. Aber irgendwann muss auch VM anfangen.


    Gern suche ich Projektpartner, falls auch für andere das leistungsfähige OS Xentral als ERP-Lösung interressant ist und dafür eine VM-Shopanbindung möchte.

    Dieser Shop der Goldschmiede Schenk unter https://www.goldschmiede-schenk.de wurde schon 2019 realisiert. Aber im Dezember 2020 erhielt der Shop endlich ein neues Feature. Ab sofort werden für die Schmuckstücke mit Edelmetallen tagesaktuelle Edelmetall-Preise von einem Webdienst (per API / JSON) geladen und somit für die verwendeten Legierungenanteile exakt preislich auf den Basispreis gerechnet.

    Realisiert wurde dieses Feature über zwei Plugins:

    1. Ein Joomla-Systemplugin lädt täglich per API von einem Webdiest die aktuellen Preise pro Unze für z.B. Gold, Platin, Palladium, Silber (kann erweitert werden) und cached diese auf dem Webserver. Es erfolgt wenn gewünscht eine autom. Umrechnung in Gramm statt Unze.
    2. Ein VM-Preiskalkulations-Plugin übernimmt die Funktion die Grundpreise für die Legierungen z.B. für Weissgold, Gelbgold, Gold unterschiedlicher Reinheit etc. zu berechnen. Abhängig von den verwendeten Mengen der jeweiligen Legierungen im Schmuckstück wird der Preis auf den Produktgrundpreis aufgeschlagen. Zusätzlich können Legierungsherstellungskosten und sonstige Spannen aufgeschlagen werden. In den betroffenen Produkten ist über Benutzerdefinierte-Felder exakt einstellbar, welche Legierungsanteile im Schmuckstück verarbeitet sind.

    Damit kann man also seinen Schmuckstückshop mit realen Preisen statt mit Preisen auf Anfrage ausstatten ohne täglich manuell die Preise anpassen zu müssen oder Gefahr zu laufen durch plötzliche Edelmetall-Preissteigungen nicht mehr mit ausreichend Marge zu verkaufen.


    (Anmerkung: Im Shop wird jetzt gerade begonnen für die Produkte die Legierungsanteile zu konfigurieren. Deshalb sind noch nicht für alle Produkte die vorherige Preisangabe "Preise auf Anfrage" erstetzt. Aber hier ist schon ein Beispiel sichtbar: https://www.goldschmiede-schenk.de/galerie-shop/ginkgo-motivschmuck/1410/ohrhänger-ginkgoblatt-gold-2-detail.html)

    Hallo Stefan,

    sicher ist das kein Fehlverhalt. Diese HTML-Zeichenumwandlung ist sicher gewollt. Wobei ich nicht einsehe warum das hier gewollt sein könnte. Möglich ist, dass ein Standard-Joomla- oder -VM-Feld verwendet wird, welches dieses Verhalten generell mitbringt, weil es woanders ggf. Sinn machen würde.


    Ob es jetzt wirklich sinnvoll ist, für eine kleine Sache die ansich über das Feld Zahlungsbeschreibung möglich wäre, dies nun aufwendiger über eine Override zu machen, darüber lässt sich streiten. Für mich keine Problem, weil ich mich mit Overrides auskenne. Für viele Admins, die evtl. auch nur ein Ratenzahlungfeature integrieren wollen eher nicht. Außerdem geht der Pflegeaufwand bei VM-Updates für Overrides ja nicht unbedingt gegen Null.


    Aber natürlich lässt sich das Script auch anderswo reinbauen. Hauptsache das Ziel-DIV lässt sich im Feld Zahlungsbeschreibung platzieren.

    In das Feld Zahlungsbeschreibung eines Payment-Plugins trage ich z.B. diesen Sequenz ein:

    <script src="https://www.paypal.com/sdk/js?client-id=AUyM********b5qOH8QaDBk&currency=EUR&components=messages"></script>

    Nach dem Speichern ersetzt VM diesen hier grün gekennzeichnenten GET-Parametername durch diesen hier in rot gekennzeichneten Käse:

    <script src="https://www.paypal.com/sdk/js?client-id=AUyM********b5qOH8QaDBk¤cy=EUR&components=messages">

    macht also offensichtlichen eine Zeichenumwandlung.

    Es wird zwar beim Eintagen noch korrekt gespeichert, aber nach dem erneuten Öffnen ist es dann falsch geändert und wird dann auch so falsch gespeichert und funktioniert dann im FE nicht mehr.

    Das sollte man korrigieren. Wer ist schuld an diesem Fehlverhalten? Das Plugin, VM, oder Joomla?

    ...tut mir leid, finde nicht den Einstieg, wie dieses Payment-Plugin den Trigger nutzen kann. Gibt es den Trigger wirklich schon?

    Ich habe da auch noch nen gedanklichen Knoten: Werden beim Mail-Versand im Checkout mehrere Payment-Plugins verarbeitet, also das vom Kunden ausgewählte und meines mit dem ich den zusätzlichen Anhang beifügen will?

    Hallo,

    ich beabsichtige auf Kundenwunsch etwas zu programmieren, mit dem beim Bestell-Checkout an die Shopbetreiber-Bestell-Mail die Kontaktdaten des Bestellers zusätzlich als VCard an die Mail angehängt werden. Was wäre dafür der beste Weg zur Einbindung? Ist dazu ein Plugin sinnvoll, oder besser als Template-Override.

    Würde eine neue Methode in einem passenden Core-Script Berücksichtigung im Core finden? Besteht daran Interesse?

    Nun habe ich den Grund gefunden:
    Im Datei-Vergleich mit dem Fullpackage-Projekt zeigte sich, dass es nur in meinem Live-Projekt im Verzeichnis language/en-GB/ eine en-GB.com_virtuemart.ini sowie zwei weitere en-GB.com_virtuemart.sef.ini und en-GB.com_virtuemart.sys.ini gab. Diese habe ich nun in meinem Live-Projekt gelöscht. Das hat die fehlerhaften Übersetzungen behoben.


    Vermutlich stammen diese alten Übersetzungsdateien in diesem Pfad noch aus einer früheren VM-Installation und wurden rudimentär mitgeschleppt.


    Hinweis Nachtrag für alle die bei sich das Problem auch zu lösen haben:
    Auch das Verzeichnis administrator/language/en-GB/ sollte überprüft von von Altlasten-Sprachscripten befreit werden.

    Ich denke ich bin der Ursache auf der Spur:
    Am Beispiel des Orderstatus-Arrays wie von mir oben gepostet, bei dem 3 korrekt übersetzt werden und die anderen nicht.
    Ich konnte festestellen, dass all die Phrasen übersetzt werden für die es eine deutsche und englische Übersetzung in den "orders"-Sprachscripten:
    components/com_virtuemart/language/en-GB/en-GB.com_virtuemart_orders.ini
    und
    language/de-DE/de-DE.com_virtuemart_orders.ini
    gibt.
    Für die anderen 5 Bestellstati gibt es gleichlautenden Constantenbezeichner auch im allg. Virtuemart-Sprachscript:
    language/en-GB/en-GB.com_virtuemart.ini
    Genau diese 5 stören.


    Ich vermute mal, dass die Orders-Sprachscripte zuerst und sprachlich korrekt geladen werden. Die Sprachkonstanten aus allg. virtuemart gibts nicht für deutsch sondern nur english, werden überschrieben und nicht erneut übersetzt.

    Die Sprachtabellen hatte ich mir schon gründlich angeschaut. Wie gesagt: für die orderstatuses gibt es keine Sprachtabellen, auch nicht in der Full-Package-Installtion. J! und VM haben beide als Standardversion deutsch. Diese Konfig.daten hatte ich zw. meinem Live-Projekt und dem Full-Package-Projekt extra noch mal abgeglichen.
    Bist Du in dem Core-Scripten fit genug, um zu wissen, was im Debugmodus anders laufen könnte als im Life-Modus?

    Den Shop gibt es schon recht lange und war von Anfang an nur auf den deutschen Markt orientiert. Nun weiss ich nicht mehr sicher wie genau das damals abgelaufen war. I.d.R. installiere ich immer ein "reines" Joomla zunächst in englisch und konfiguriere dann auf deutsch um inkl. der Nachinstallation der dt. Sprache. VM wird i.d.R. erst danach als Komponente installiert. Seit dem sind natürlich schon ein paar Updates von Joomla und VM gelaufen. Meine Projekte befinden sich i.d.R. aus Sicherheitsgründen immer auf dem aktuellsten Updatestand. So auch dieses mit J!3.8.11 und VM3.2.14.


    Angenommen es liegt an den Sprachtabellen. Welche beträfe das? Kann man zur Not ja manuell nachjustieren.
    Für der Orderstates gibt es soweit ich weiss ja gar keine Sprachtabelle, sondern Sprachphrasen in der language/de-DE/de-DE.com_virtuemart_orders.ini.


    Aber gegen diese Annahme streubte sich mein inneres Logikgefühl. Offensichtlich sind die Sprachtabellen doch alle da, sonst könnten die Sprachphrasen doch nicht im Sprach-Debug-Modus korrekt angezeigt werden (s. vergleich meiner beiden Uplaods). Der Debugmodus soll doch genau solche Fehler analysierbar zeigen.
    Auch im Adminbereich für die Bestellstatus-Konfigurationen werden die Übersetzungen komplett korrekt angezeigt.

    Ja, selbstverständlich hatte ich die Sprachdateien aktuell installiert, frisch geladen vom VM-Server am 13.8.
    Aber mein Post mit dem eingeschalteten Sprach-Debug-Modus deutet schon darauf hin, dass es keine Ursache in unaktuellen Sprachphasen hat, denn im Debug-Modus sind alle Übersetzungen erwartungsgemäß da. Nur wenn ich den Debug-Modus wieder abschalte kommen wieder großteils unübersetzte Phrasen. Bitte vergleiche mal meine beiden Scrennhots.


    Kann es sein, dass Joomla da irgendwas hartnäckig cached? Mag ich nicht glauben, zumal der J!Cache abgeschalten ist.

    Eigentlich hatte ich bei keiner Installation überhaupt die Absicht eine Sprache auszuwählen. Wollte einfach nur schnell eine Testinstallation machen. Es sprang aber schon beim 1. Versuch unbemerkt de_AT als Installationssprache rein. Dann hatte ich nichts weiter gewählt, lediglich Installation mit VM-Beispieldaten aktiviert - war aber eigentlich auch schon vorausgewählt. Außer die allg. notw. J!Projekt-Einst. hatte ich alles auf easy-Standard gelassen. Beim 2. Versuch, meine ich mich zu erinnern, dass ich Deutsch dann auch als "weitere" Sprache installiert hatte. Bin mir aber nicht mehr sicher. Werde es kurzfristig noch mal durchspielen.

    Danke Stefan für die Antwort,
    Habe mir mal eine Fullpackage-Installation gemacht. Dort sieht es wirklich besser aus mit den Sprachphrasen.
    Folgendes habe ich dann in meinem Projekt versucht:
    1. Virtuemart und Erweiterungen deinstalliert und Virtuemart komplette neue installiert (außer DB-Tabellen natürlich, weil dort sind ja Live-Daten drin). Das hat nichts geändert.
    2. Vom intakten Fullpackage-Projekt mal alle Virtuemart-Verzeichnisse (site+admin com_virtuemart) auf mein Live-Projekt kopiert - hart überschrieben. Auch das hat nichts an den Fehlern geändert.
    3. Alle Virtuemart-Sprachdateien im Joomla-Language-Order und den VM-site und -admin-Komponeten-Ordner gelöscht und VM und AIO neu drüberinstalliert. Wieder ohne erhofften erfolgt.


    Bin verzweifelt und ratlos. Nach wie vor sind in meinem invoice-PDFs nur manche Sprachphrasen übersetzt. Es ist auch nicht nachvollziehbar nach welchem Prinzip manche übersetzt werden und andere nicht.
    Hier mal ein Bild von der PDF (Blau ist korrekt übersetzt, grün noch in englisch).

    Hallo,


    habe gerade wg. einer Fehlersuche mal wie im Forum empfohlen eine Full-Package-Installation (Joomla inkl. VM vom VM-Downloadbereich) zu installieren versucht. Der Joomla-Installationspart lief erfolgreich durch. Dann wollte ich VM mit Beispieldaten installieren und erhielt sofort diesen Fehler:
    1146 Table 'dbxxx-neu.#__virtuemart_vendors_de_at' doesn't exist


    War dann verwundert, warum der überhaupt AT-Sprachdaten installieren wollte. Habe also die Instation wiederholt und darauf geachtet, dass sich beim 1. Installationsdialog gleich de-DE ausgewählt habe, statt der wieder voreingestellten AT-Sprachversion. Leider führte auch das bei der Installation der VM-Beispieldaten wieder zu einem Fehler:
    1146 Table 'dbxxx-neu.#__virtuemart_vendors_de_de' doesn't exist


    Es dämmerte mir, dass es vermutlich überhaupt keine Beispieldaten in diesen Sprachen gibt, sondern nur in englisch, die Routine aber versucht eben diese Sprachtabellen anzulegen. Also habe ich die Installation ein 3. Mal durchgeführt und dabei darauf geachtet, diese zunächst konsequent mit englischer Einstellung auszuführen. Nun lief dann auch die Installation der VM-Bsp.daten sauber durch.


    Ich denke, dass sollte man besser lösen!
    Bei mir konnte ich diesen Fehler durch etwas Denken ausschalten, auch weil ich seit 10 Jahren mit VM arbeite. Aber viele VM-Neulinge wärden hier an dieser Stelle scheitern, verstehen den Fehler nicht, sind gleich am Anfang frustriert und packen VM deswegen beiseite.