Beiträge von jooomlaa

    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:

    Code
    1. content.get(0).style.removeAttribute('filter');
    2. wrap.get(0).style.removeAttribute('filter');


    'filter' ist demnach kein Attribut sondern eine CSS-Eigenschaft. Korrekt sollten diese Zeilen lauten:

    Code
    1. content.css('filter', 0);
    2. wrap.css('filter', 0);


    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

    Code
    1. {j.get(0).style.removeAttribute("filter");f.get(0).style.removeAttribute("filter")}


    ersetzt werden durch

    Code
    1. {j.css('filter', 0);f.css('filter', 0);}


    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:

    • Kann jemand vom VM-CoreTeam (z.B. Milbo) meine obigen Ausführungen prüfen. Ist das eine zuverlässige Lösung, die nicht nur bei meinen Projekten funktioniert?
    • Wenn mit ja beantwortet: Gibt es eine Möglichkeit die FancyBox-Core-Scripte an der Originalquelle anzupassen (Github)?
    • ... oder wenigstens in den VM-Core in dieser korrigierten Version einzubinden, damit Updates unsere Änderungen nicht wieder zunichte machen?


    Ü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

    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.

    Habe ein Projekt migriert, von J!2.5.28 auf J!3.5.1 und VM 2.6.22 auf VM3.0.14. Migration war an sich erfolgreich. Allerdings funktioniert die Bezahlung per Bank-Transerer / Nachnahme (also plugin payment standard) nicht - PayPal geht demgegenüber. Erhalte beim abschließenden Absenden der Bestellung eine Meldung "Error: 0 - Invalid address: Max Mustermann".


    Nun habe ich mal nachgeforscht, wann dieser Fehler auftritt - leider erhält man weder über die Error-Log noch über das VM- oder J!-Debug dazu eine Fehlermeldung: Dieser Fehler tritt scheinbar nur und erst auf unter J!3.5.1, solange ich im Projekt noch J!3.4.8 verwende geht es (also bis zum vorm Update und auch nach einem Restore wieder, einziger Unterschied J!Version).


    Habe mal in den Quelltexten herumgestochert. Der Abbruch bzw. die Fehlerseite wird vermutl. erzeugt, weil das Absenden der Vendor-Mail über shopfunctionsf::sendVmMail() fehlert. Warum genau, die Kenntnis fehlt mir noch? Evtl. weil zw. den Joomla-Versionen $recipient unterschiedlich als array bzw. als string erwartet wird?


    Bin jedenfalls total entnervt, weil bis zu diesen spärlichen Erkenntnissen schon 3 Tage Fehlersuche vergangen sind, die mir keiner bezahlt. Brauche also dringend eine Lösung.


    Mal anders gefragt: Hat jemand eine Installation mit J3.5.1 und VM3.0.14 bei der der Checkout mit Standard-Bezahlg. funktioniert? Evtl. liegt es ja zusätzl. an irgend einer meiner Konfig.?

    Habe einen kleine VM-Shop mit nur 5 Produkten. Projekt sollte nun migriert werden von J2.5.28 und VM 3.0.2 auf Joomla 3.3.6. Ansicht läuft danach alles. Wenn ich jedoch den Warenkorb aufrufen will, erhalte ich eine SQL-Fehler:


    Error: 1064 - You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'FROM JOIN xxx_virtuemart_categories using (`virtuemart_category_id`) WHERE = "' at line 1 SQL=SELECT FROM JOIN xxx_virtuemart_categories using (`virtuemart_category_id`) WHERE = "7"


    Irgendwie scheint der SQL-QUery nicht komplett zu sein, hinter dem SELECT und FROM fehlt einiges und es geht erst mit dem JOIN weiter.


    Kann jemand helfen? Kann es mit der Zweisprachigkeit des Shops zu tun haben?

    Hallo,
    Habe nun erste Test mit der Migration eines Projektes von 2.6.10 zu 2.9.9e vorgenommen. Leider funktioniert nicht alles auf Anhieb. Ein Problem liefert die Übernahme der Versandkosten. Habe das mal analysiert und es stellt sich wie folgt da:


    In 2.6.10 hatte ich ca. 116 internat. Versandarten. Nach der Migration zeigt der Warenkorb bei den Versandkosten falsch "(free)" an (nutze rupostel OPC). Schau ich in die BE-Konfig. der Versandarten steht in "Versandtarif Betrag" nicht mehr der Preis wie unter 2.6.10 sondern 0(!).
    Schaue ich mir den DS im Feld #__virtuemart_shipmentmethods.shipment_params an, steht dort der korrekte Preis.
    Der Parametersatz sieht in 2.6.10 und nach Migration zu 2.9.9e zunächst identisch aus: nämlich z.B. so:
    shipment_logos=""|countries=['81']|zip_start=""|zip_stop=""|weight_start="5.001"|weight_stop="10"|weight_unit="KG"|nbproducts_start=0|nbproducts_stop=0|orderamount_start=""|orderamount_stop=""|cost="6.64"|package_fee=""|tax_id="2"|free_shipment=""|


    Nun gehe ich in die Konfig. für die Versandart und speichere diese in dem ich 0 wieder durch meinen Preis ersetze. Das wird übernommen. Nun schaue ich mir den DS wieder an und stelle fest, dass dieser nun einen anderen Aufbau hat(!):


    1. Es ist ein neuer Parameter hinzugekommen show_on_pdetails="1", was vermutl. bedeutungslos für unseren Fall ist.
    2. Der Parameter cost="6.64" heißt nun shipment_cost="6.64". Und das wird das Problem sein.


    Evtl. so:
    UPDATE `#__virtuemart_shipmentmethods`
    SET `shipment_params` = replace(`shipment_params`, '|countries=', '|show_on_pdetails="1"|countries=')
    WHERE `shipment_params` NOT LIKE '%|show_on_pdetails%'


    und so:
    UPDATE `#__virtuemart_shipmentmethods_res`
    SET `shipment_params` = replace(`shipment_params`, '|cost=', '|shipment_cost=')
    WHERE `shipment_params` NOT LIKE '%|shipment_cost%'




    Frage:
    Wird das UpdateScript noch dahingehend angepasst, dass dieser Parameter sauber ersetzt wird durch seinen neuen Bezeichner?


    Seltsam konfigurierter Server.
    Das ist dein Server.


    Na, da muss ich mal forschen. Eigentl. kenne ich HostEurope als immer "nah" am Standard ...



    PS: Eventuell magst du dich umbenennen, weil ich vergesse immer wer jooomlaa eigentlich ist ;-) (z.B. Vm supporter)


    Das liegt doch sicher außerhalb meiner Macht hier im Forum, oder. Außerdem erkenne ich mich so selbst wieder, weil immer gleich ;-)
    Hilft Dir mein neue Signatur?

    Sobald ich in einem existierenden Projekt ein VM-Update einspiele, ist danach der VM-Backend-Menü-Eintrag verschwunden. Ich habe mal nach der Ursache geforscht und vermute folgenden Grund:


    Installiert habe ich das VirtueMart-Plugin für die SiteMap-Komponente xMap. Diese verwendet in der '#__extensions.element' ebenfalls den String com_virtuemart. Beim Update scheint VM zu prüfen, ob es für dieses element mit der extension_id schon einen Eintrag in der '#__menu' gibt. Wenn nicht, werden die Menüeinträge dazu neu eingetragen, erhalten aber natürlich die erst gefundene xMap-VM-Plugin-extension_id. In Folge können diese Menüeinträge nicht mehr sauber zugeordnet werden und sind folgich fort.


    Vermutl. ist der eigentliche Übeltäter das xMap-VM-Plugin weil es sich unsauber als "com_virtuemart" meldet. Aber bekommen wir nicht evtl. die Abfrage zuverlässiger hin, so dass es nicht zu Verwechslung damit kommt?

    Habe einen Kunden, der in seinen Produktbezeichnungen gerne Punkte verwendet, z.B. bei " ... 2.0 Liter ...". Wird jedoch ein Punkt verwendet, wird dieser bei der automatischen Erzeugung des Produkt-Alias nicht ersetzt durch z.B: "-". Der Punkt im Alias (slug) erzeugt jedoch beim Aufruf der Seite, z.B. aus der Such-Trefferliste eine Crash, weil die so erzeugte SEF-Uri nicht aufgelöst werden kann.


    Wäre es evtl. mögl. dass auch Punkte sauber automatisch ersetzt werden?
    Das Betrifft soweit ich gesehen habe nicht nur Produkte, sondern auch Kategorien, Hersteller, etc.