Beiträge von jooomlaa

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?

Nachdem ich in einem J!2.5.27 Projekt zunächst VM-Core auf 2.9.9e geupdatet habe und dann das AIO-Paket, kann ich im Backend-Menü Erweiterungen den Menüeintrage virtuemart-aio nicht mehr aufrufen, erhalte vollst. weiße Seite.

Macht dieser Menüeintrag noch Sinn, oder ist der einfach nur fehlerhaft? Wozu ist der gedacht?

Die Erweiterung AIO läßt sich über die Extension-Verwaltung in einem Projekt 2.5.27 nicht mehr deinstallieren. Statt dessen erhält man auf einem weißen Screen die Meldg. "Install the virtuemart Core first".

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?

Na guck, habe gerade meine erste Migration von 2.6.10 zu 2.9.9e am Laufen, und darf erfreut festellen, dass VM3 nun bei den Slugs die Punkte ersetzt durch '-'.
Na super!
Geht doch!
Fein gemacht!
Danke!!!

Mag sein, was Du sagst, hab ich ja keinen Dunst von, aber:

Wenn ich einen neuen Joomla-Beitrag mit folgenden Titel anlege:
"Test-SEF-Slug 2.0 von...bis",
dann wird daraus automatisch ein sauberer Alias ohne Punkte:
"test-sef-slug-2-0-von-bis"

Also VM macht's anders als der Joomla-Core.

Zitat von Milbo

Seltsam konfigurierter Server.
Das ist dein Server.

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

Zitat von Milbo

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?

Ne, schon ein(!) Punkt im Slug/Alias genügt damit es crasht ("Objekt nicht gefunden - Error 404). Ersetze ich den manuell durch "-" oder ",", geht's sofort.

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.

Hallo Milbo,

muss mich noch mal zu dem thema der Limit-Listboxen melden. In meinem Projekt mit 2.0.22c, wo ich o.g. Mod hatte, funktionierte die LimitListbox (siehe).

Nun in meinem neuen Projekt mit 2.0.24 wo mit ,false gearbeitet wird, spinnt das Teil wieder (s.: siehe). Die Liste enthält immer nur die Option 10. Es wird weder mit den default-Werten befüllt noch mit denen die ich für den Seitenumbruch konfiguriere.

Einstellungen in der Kategorie f. Listenlimit und Startanzahl zeigen bewirken zumindest das die Listen korrekt gefüllt sind, aber auch damit wirkt sich die Startanzahl nicht aus und der selektierte Wert auch nicht ... Es ist auch hier wieder so, der erste Wert der in der Liste steht wird unveränderlich gesetzt.

Funktioniert das in 2.0.24 immer noch nicht sauber?
Nehme doch eher an, ich mache was falsch?

Nachtrag:
Durch viel Rumprobieren habe ich nun einen Zustand erzielt, der wohl funktioniert:

In den Shop-Stilvorlagen:
- Anzahl der Artikel pro Listenansicht im Frontend: 25
- Für Ansichten mit 1 Artikel pro Zeile: 10,25,50,100,200

In der Kategorie:
- Standard Anzahl der Produkte pro Reihe: 1
- Kategorie Formular Listenlimit Schrittgrösse: 10,25,50,100,200 (Feld, kann leer gelessen werden, wenn die Werte aus den Stilvorlagen verwendet werden sollen)
- Startzahl anzuzeigender Artikel: 0 (würde also aus der glob. Shop-Einst. genutzt werden, aber sobald man hier irgendein Wert ungl. 0 eingibt, funktioniert das Teil schon nicht mehr! Es wird dann immer mit diesem Wert gelistet, egal was man als User auswählt - also ich denke schon dass das ein Fehler ist.)

Okay, JRoute mit false, so weit war ich noch nicht vorgedrungen und die .24 konnte ich noch nicht inst. Wenn's gefixed ist, bin ich schon glücklich.

Ihr macht gute Arbeit!!!
Man kann VM wieder mit guten Gewissen den Kunden empfehlen.

Hallo Milbo,
Hatte mich auch mit dem Problem beschäftigt. Grund war, dass auch in meinen Projekten die Konfiguraiton der Limit-SelectBoxen nicht zuverlässig funktionierte. 2 Probleme:
1. wie im Thema beschrieben, die Konfig.-Parameter für die Anzahl der Prod. greift nicht. Wenn ich im Reiter Stilvorlagen "Seitenumbuch festlegen" eine Liste eingebe, wird wenigstens der 1. Wert als Standard gesetzt. Das ist aber unbefriedigend, weil man ja nicht immer den ersten auch als Standardwert haben will.
2. Wenn ich dann im Frontend einen Wert auswähle, wird zwar mit diesem gelistet, aber der Wert wird in der Liste nicht als selectiert markiert. Grund, das Attribut selected="selected" wird nicht gesetzt. Deshalb kommt man dann z.B. auch nie wieder auf den ersten Wert zurück, weil dieser markiert wird aber nicht selected ist, weil keiner selected ist (s. HTML-Src)

Der ganzen Sache bin ich mal nachgegegangen. Grund für dieses Fehlverhalten ist ein Bug im VM-Script vmmodel.php und mündet in der Methode options() in der libraries/joomla/html/html/select.php. Hier soll ja das selected-Attribut für die jeweils akt. Option gesetzt werden, so wie im letzten Parameter von

im Script vmmodel.php übergeben.

Erwartet wird in der Methode options() für $options['list.select'] entweder ein array oder ein string. Hier übergeben wird die URI als string für den Vergleich bezüglich des limit-Wertes. Nun der konkrete Fehler:
In der Zeile 615 in select.php wird wie folgt verglichen:

.

In der vmmodel.php Zeile 713 erzeugen wir den URi-String mit

Das Problem ist dass dieser String html-specialchar-encodet ist also "&" umgewandelt wird in &. Damit schläg o.g. Stringvergleich in der select.php zwangsläufig fehl.

Vorschlag: Wir sollten in der vmmodel.php die Zeile 713 ändern zu:

Damit hätten die Strings eine Chance gleich zu sein.

Bei mir funktioniert dieser Mod. Vielleicht sollte es in den Core?