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?
Ich habe für einen Kunden ein Bezahl-Plugin für Santander-Ratenkauf programmiert.
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.
Wenn ich mir im Template das array $this->orderstatuses ausgebe, erhalte ich schon so eine zweisprachige Mischung:
Array
(
[P] => Pending
[U] => Vom Kunden bestätigt
[C] => Confirmed
[X] => Cancelled
[R] => Refunded
[S] => Shipped
[F] => Abgeschlossen
[D] => Abgelehnt
)
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.
...jetzt hatte ich mal in Joomla das Sprach-Debug eingeschalten. Schon werden alle Phrasen korrekt übersetzt!?!?! Wenn ich das Debugging wieder abschalte sind die Fehler wieder da. Ich verstehe es nicht! Was läuft da?
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.
Hallo,
bin vom Kunden beauftragt die PDF-Rechnungserstellungen wunschgemäß anzupassen. Dabei zeigt sich schon in der unmodifizierten Standardversion der invoice.php und invoice_*.php, dass viele aber nicht alle Sprachphrasen nicht ins Deutsche übersetzt werden. Die Sprachphrasen sind in der de-DE.com_virtuemart.ini und de-DE.com_virtuemart_orders.ini vorhanden und übersetzt, werden aber einfach nicht genutzt. Selbst wenn ich über die Joomla-Sprachoverrides die zickigenen Phrasen übersetze, werden diese nicht verwendet. Bin ziemlich verzweifelt und ratlos. Warum?
Habe gesehen, dass es eine de-DE.com_virtuemart_orders.ini und de-DE.com_virtuemart_shoppers.ini in language/de-DE/ gibt. Die liegen bissle anders als die engl. Varianten. Wie genau ist der aktuelle Standard in denen VM diese Sprachdateien sucht. Außerdem gibt es viel Sprachphrasen die in der shoppers-DE und orders-DE vorhanden sind, aber in den englischen Versionen in der en-GB.com_virtuemart.ini liegen?! Wo gehören die nun eigentlich korrekt rein? Das Durcheinander ist schwer zu durchschauen.
Hallo Gemeinde,
hallo Milbo,
Immer wieder habe ich in meinen VM-Kunden-Projekten massiv Probleme mit der FancyBox. Sowohl die AddToCart-Funktion, also auch die Fragen zum Produkt und die Bild-Popups werden nicht korrekt angezeigt. Die Lösung auf das veraltete FaceBox zurückzugreifen scheint mir nicht zeitgemäß und vermutlich nicht von langer Dauer, da ich damit rechne, dass es in einer der nächsten Versionen von VM eh nicht mehr supported wird. Vermutlich ist aber der einzige Grund, warum FaceBox überhaupt noch Core-Bestandteil ist, weil es diverse Projekte gibt, bei denen FancyBox nicht läuft und deshalb auf FaceBox zurückgegriffen wird.
(Ich nutze in meinen Projekten J!3.8.2 und VM 3.2.6)
In diversen VM-Forenbeiträgen konnte ich lesen, dass es einige Anwender gibt, die sich damit rumschlagen, aber keiner eine wirkliche Lösung hat (z.B.: https://forum.virtuemart.de/al…n-restricted-access-2569/ oder https://forum.virtuemart.net/index.php?topic=131598.0). Irgendwo konnte ich lesen, dass auch Milbo das Problem noch nicht lösen konnte.
Im FancyBox-Forum selbst konnte ich nun eine Lösung finden, die es offensichtlich macht, dass der Fehler selbst im FancyBox-Core-Script zu finden ist: https://github.com/nvidoni/fancybox/issues/2.
Fehlerhaft sind im Script components/com_virtuemart/assets/js/fancybox/jquery.fancybox-1.3.4.js diese beiden Zeilen:
'filter' ist demnach kein Attribut sondern eine CSS-Eigenschaft. Korrekt sollten diese Zeilen lauten:
Natürlich nützt es nicht so viel in VM dieses Script zu modifizieren. Statt dessen müsste die Min-Version dieses Scriptes angepasst werden.
hier müsste
ersetzt werden durch
Nachdem ich diese Änderungen vorgenommen hatte, waren sofort alle Fehlverhalten bzgl. der FancyBox behoben.
Leider ist lt. Github selbst in der ScriptVersion jquery.fancybox-1.3.6.js dieser Fehler noch enthalten - seit 5 Jahren.
Ich hätte jetzt folgende Bitten/Anfragen:
Über ein Feedback würde ich mich sehr freuen.
Problem für die KBA-Fahrzeugschlüsselnummer ist gelöst.
Es gibt jetzt ein Plugin, welches die Suche durchführt - über die Joomla-Search-Plugin-Schnittstelle und ein KBA-Nr-Suchmodul welches gezielt über 2 Eingabefelder nach zu 2 und zu 3 (oder zu 2.1 / 2.2 oder HSN / TSN) abfragt und die Suche dann autom. startet. Die zutreffende Kategorie wird dann angezeigt (Funktion siehe http://www.zweimassenschwungrad.com).
Hallo, kann mir jedmand den korrekten Einstieg zeigen für die Programmierung einer eigenen Suchfunktion:
Hier kurz die Aufgabenstellung, die ich lösen soll:
Ein Kunde bietet Fahrzeugteile an. Die Seitenbesucher sollen u.a. über die einheitliche KBA-Fahrzeugnummer (zu 2. auch 2.1 und zu 3. auch 2.2) zu den gesuchten Teilen gelangen können, die für ihr Fzg. zutreffend sind. Die Eingabe der KBA-Nr. soll über ein eigenes Modul wie bei KBA-Nr. üblich mit 2 Eingabefeldern mgl. sein. Die KBA-Nummer hat der Kunde in die letzte Kategorieebene u.a. in den Kategorienamen eingepflegt.
Stand meiner Tests/Arbeiten/Erkenntnisse:
Ich habe mal auf die Schnelle ein Joomla-Search-Plugin programmiert welches in den Kategorienamen nur nach den KBA sucht. Dazu dann das J!Suchmodul dubliziert und modifziert, so dass dieses die Suche nur nach KBA als Filter auslöst. Das klappt auch ganz hervorragende so weit. D.h. ich bekomme eine Trefferliste mit ausschließlich VM-Produkten bei denen in der Kategorie die KBA-Nr. enthalten ist.
Jetzt das Problem:
Die Trefferliste ist eben so, wie es Joomla ausliefert. Das Suchplugin liefert ja nur einfache Treffer mit Produktname und Link, Kategoriename, so wie es Joomla-Search erwartet, mehr eben nicht. Das ist uns zu wenig so. Ich möchte eine Anzeige wie bei der VM-Suche als Anzeige der view "category". Also eine Auflistung der Produkte gleich mit Detailinfos, Bild, addtocart-Formular etc.
Meine alternative Idee, die leider bisher scheitert:
Nun war ein neuer Ansatz von mir, den View-Ordner "category" einfach zu duplizieren als z.B. "kbanresults" und mir so meine eigenen VM-View zu bauen, welche gleich die Suche nach KBA in den Kategorienamen durchführt. Über ein modifiziertes VM-Suchmodul, welche gleich diese neue View als Parameter aufruft, würde die Suche gestartet und gesteuert. Leider funktioniert das so nicht. Ich fliege immer auf die VM-Startseite. Vermutlich ist VM diese View nicht bekannt? Einfaches Anlegen eines View-Ordner und Anpassen der dortigen Scripte genügt wohl nicht...? Oder habe ich dort nur eine Zeile vergessen anzupassen?
Ich weiß, es wird sicher der Hinweis kommen, das doch besser über die VM-Custom-Fields zu managen. Die KBANr. stehen nun aber in der Kategorie und nicht im Produkt. Und ich hätte das gern auch als generelle Lösung für andere Such-Konstellationen.
Optimal wäre natürlich eine Lösung die ohne Core-Script-Modifikationen auskämen. Also entweder als Plugin oder Override.
Danke
Schließe mich der Frage an. Neu bietet PayPal auch Ratenzahlung an. Auch das wäre super, wenn VM das unterstützen würde. Hier gelesen: https://www.onlinehaendler-new…aypal-payment-option.html.
Ja Stefan, das trifft's. Aber mal sehen ob mein Hinweis/Bitte sich auf die Zukunft auswirkt. Ich glaube, es wird eher so "entspannt" weitergehen.
Im übrigen mache ich ich eine Migration nicht am lebenden Patienten. Allerdings war ich bisher der Auffassung, dass ein kleines Joomla- oder VM-Update schon mal am lebenden Projekt riskiert werden darf. Dafür gibt's ja nen Backups.
Ein Crash war auch nicht der Grund meines Ärgers (hätte es aber sein können), sondern die 3 Tage Fehlersuche resultierend aus einer nachlässigen Programmierg., die dürftige Abstimmung zw. J! und Extensions(VM) und mangelnde Inform. in Rtg. Anwender/Entwickler.
Euch respektive faro noch mal Dank für Eure Posts
Richtig, per Definition kein Bug. Aber wenn sich im Core mal eben eine so zentrale Funktion ändert, dann sollte man damit behutsam verfahren, so dass Erweiterungsentwickler überhaupt 'ne Chance haben mit Updates darauf zu reagieren. So entspannt Wie Du kann ich das leider nicht sehen: "Diese gilt es nun zu aktualisieren".
Es wäre doch kein Problem gewesen, abzufragen ob die Parameter evtl. noch alt als string oder schon neu als Array übergeben werden. Das Mindeste wäre im "Alt-Fall" eine sinnvolle(!) Fehlerausgabe. Mit "Error: 0 - Invalid Address" kann man doch wirklich nichts anfangen.
Nach den vielen Sicherheitslücken / -patches von J! über den Jahreswechsel 15/16 ist man nun geneigt gewesen zeitnah zu updaten. Wie ich nun erleben durfte, ist auch das ein Risiko - vermutl. sogar größer als gehackt zu werden ;-). Damit macht sich J! keine Fans.
Ich arbeite nun seit 9 Jahren mit J!+VM tgl. und progr. auch. Für mich als Dienstleister ist es ein Horror, Tage über unerwarteten Problemen in Kundenprojekten zu hocken die ich nicht mal in Rg. stellen kann.
Ich weiß von Max, dass es zw. VM- und J!-Core-Team schon ein wenig knirscht. Sicher auch aus solchen Ereignissen begründet. Wir sollten dann wenigstens als VM-Gemeinde geeignet darauf reagieren - evtl. mit o. vorgeschlagenen Frühwarnsystem - z.B. als Mailingliste o. wie auch immer.
Danke Faro, Du bist mein Held. Danke auch für die schnelle Hilfe. Das hat mir vermutl. weitere Stunden erspart.
Interessant: Wenn man so dicht vor der Lösung steht, dann kann man auch die richtigen Fragen stellen. Hatte schon seit Tagen gesucht, aber vor meinem Post und dann mit meinen erkämpften Erkenntnissen nicht mehr.
Ich bin aber auch jetzt überrascht, dass so ein Bug, so tiefenentspannt bearbeitet wird. Wie lange ist 3.5.1? draußen? Problem schon bekannt und noch immer nicht gefixt ... Da lässt man noch weitere Shopbetreiber mit dem J!Update in diese Falle tappen. Das ist der noch gut dran, dem der Fehler gleich auffällt. Andere wundern sich nur über die ausbleibenden Umsätze, weil irgend eine Bezahlart still und heimlich bockt. Klar, dass das nicht VM-Core-Problem ist sondern im Joomla Core-Funktionen geändert wurden. Echt ärgerlich. Evtl. sollte man für solche Fälle ein Frühwarnsystem einführen.
