Hallo nach ein wenig Korrespondenz mit Max, konnte Max die Ursache für das Problem in router.php finden und lösen.
Ich denke er wird kurzfristig eine neue Package-Release größer/gleich 10800 bereitstellen und vermutlich auch verlinken.
Wer es nicht abwarten kann hier gespoilert:
In ca. Zeile 494 folgende Einfügung:
Danke Max
Hi,
ich habe den Verdacht, dass Problem scheint in Release 10796 nicht behoben.
Habe mir die neue router.php hochgeladen aber der Fehler bleibt, sowohl im Backend in den Menüeintragseinstellungen als dann auch im Frontend in dem Menü-Links.
Leider ist das ein sehr ärgerlicher Fehler, weil der Shopbetreiber so kein Menülinks mehr einpflegen kann, weil immer diese Parameter hinten dran hängen.
Es nicht nur ein Parameter der hinten dran hängt sondern z.T: zwei (wie oben schon beschrieben):
https://www.zfn.de/heilpraktik…g/results,1-0?clearCart=0
Wäre Euch super wenn das schnell behoben wird.
Vermutlich konnte ich die Ursache für dieses sonderbare Fehlverhalten finden. Wenn in der Shop-Konfiguration unter Shopfront > Produktauflistung > "Produkte aus Unterkategorien anzeigen" aktiviert ist, tritt es auf. Wenn ich es deaktiviere scheint alles super zu funktionen. Ich denke, das sieht eher nach eine Bug als nach einem Feature aus...
Nun habe ich doch in einem ersten Projekt Probleme mit VM4 (J!3.10.09). Also ich nehme zumindest an, dass es durch das Update auf VM ausgelöst wurde. Der Fehler äußert sich aktuell nur im Backend in der Produktliste wie folgt:
Wenn ich mich frisch in das Projekt einlogge und auf die Produktliste gehe, sehe ich 1-100 von 11592 Produkten. Gebe ich nun in das Volltextsuchfeld z.B. "Sweatshirt" ein und starte die Suche, wird mit eine Trefferzahl z.B. 1 bis 6 von 6 angezeigt. Wenn ich die Suche zurücksetze, sollten eigentlich wieder alle 11592 angezeigt werden. Wird aber nicht, es steht dann auf 1-99 von 99. Den gleichen Effekt habe ich wenn ich die Pagenavigation unter der Produktliste verwende. Erst wenn ich mich auslogge und erneut einlogge, erhalte ich wieder meine vollst. Produktzahl.
Jemand eine Idee, was hier schief läuft?
In einem anderen VM4/J!3 Projekt tritt genau dieser Fehler nicht auf. Deshalb bin ich mir auch nicht sicher ob es wirklich an VM4 liegt, oder hier noch was anderen reinspielt...
Hier mal ein Screenshot vom Outfit-Manager, da er als Intranet-Lösung ja nicht öffentlich zugänglich ist. Wie gesagt, basiert auf Joomla 4 und JTL neueste Version inkl. eigenem Connector innerhalb der Komponente.
Auf welchen Connector greift ihr zurück? Oder selbst geschrieben?
Ich mache ja aktuell keine Anbindung von JTL zu VM, sondern lediglich von meiner eigens programmierten Joomla-Komponenten "Outfit-Manager" (=OM) zu JTL. Tatsächlich habe ich dafür einen eigenen Connector programmiert.
Will mal ganz kurz zum Verständnis beschreiben was der OM macht: Mein Kunde ist ein Herrenausstatter mit Maßkonfektion - schneidert also indiv. passende Anzüge. Er brauchte zur Organisation seiner Abläufe die Möglichkeit alle Kundenmaße und die indiv. Kundenwünsche zu erfassen. Diese will er überall remote und mobiltauglich zur Verfügung haben (in allen Filialen, in der Produktion, bei Außeneinsätzen, Einkaufstouren etc.) Die Mitarbeiter sollten bei der Erfassung und Verwaltung der Daten und Aufträge optimal supportet werden - zur Fehlervermeidung etc. Zudem sollten sämtliche Terminketten (Schwerpunkt Fertigstellungstermin/Anproben) durch den OM gemanagt werden (Ampel) inkl. dem rechtzeitigen und vollst. Transport von Waren und Anzugteilen etc. zwischen den Filialen, Produktionsstandorten, Lagern, Lieferanten (Picklisten). Du weißt, einige Dinge davon sind so in JTL nicht möglich. JTL versteht sich als Warenwirtschaft und nicht als vollwertiges ERP (hier war Xentral breiter orientiert). Deshalb ist aktuell keine wirkliche Prozessverwaltung, Terminverwaltung oder flexibles KIS in JTL enthalten. Das leistet spezialisiert nun der OM.
Wie gesagt, als Connector zw. externen Anwendungen und dem Wawi-System stellt JTL eine API. Aber diese kann nicht alles und lässt sich auch nicht von Externen erweitern, weil es ein Core-Bestandteil ist und nur von JTL gepflegt wird. Damit stellt JTL die Sicherheit und Stabilität des Systems sicher.
Das Argument mit der Nutzung von VM als Webshop, um die 500 Art.-Beschränkung zu umgehen, ist nachvollziehbar und ich habe ersthaft darüber nachgedacht. Denn für o.g. Kunden soll auch noch ein Webshop entstehen. Jedoch finde ich den JTL-Shop so stark und solide, dass es außer wg. der Kosten keine weiteren Argumente gibt. Evtl. noch der bedauerliche Verzicht auf das Joomla-Framework. Jedoch hat JTL in der neuen Version einen absolut top Composer. Somit ist es nun sehr einfach quasi wie in einem CMS in den Shop weitere Inhalte zu integrieren. In früheren JTL-Versionen war genau diese CMS-Aufgabe immer aufwendig und kompliziert.
In Anbetracht dessen, dass schon die Wawi kostenlos ist und JTL ein super Produkt bereitstellt, würde ich es schäbig finden noch die moderaten Kosten für den Shop sparen zu wollen und deshalb auf VM auszuweichen. Letztlich bietet JTL extrem gute POS-Features die gut mit dem JTL-Shop zusammenspielen.
Hi SirBoerky,
Die Entscheidung für Xentral hat der Kunde vor der Zus.arbeit mit mir allein getroffen, vermutlich nicht mal allein, sondern begleitet durch eine Consultingfirma. Zum einen war es das vollmundig versprochene Leistungsangebot in der Xentral-Werbung und ein potenter Verkäufer. Der Kunde ist vermutlich auch auf die Zugnummer Frank Thelen abgefahren, der das Produkt in höchsten Tönen lobte ... Der Kunde hat ein sehr spezielles Geschäft und spezielle Vorhaben. Es schien so, als ob Xentral mit den vorhandenen Modulen dies am ehesten abbilden konnte.
Als der Kunde mich zu Hilfe nahm, weil das Projekt festgefahren und der Support sich als schlecht rausstellte, war ich ansich auch mit der Entscheidung für Xental sehr zufrieden. Xentral läuft auf LInux, PHP und MySQL, wo ich mich kompetenzmäßig zu Hause fühle und ich wusste, da kann ich helfen. Außerdem gibt es eine "quasi" OpenSource-Version was mir als Entwickler die Möglichkeit bot die gewünschten Anpassungsprogrammierungen und Erweiterungen (z.B. Shopanbindung, Prozesssteuerung, Kassenanbindung ...) anbinden zu können. Tatsächlich ist das Konzept von Xentral wirklich top.
Bei Wawi's ist das i.d.R. so, dass alle versprechen viele Module zu haben, was es aber wirklich leistet und wie gut der notwendige Support ist bekommt man erst raus, wenn man bereits seeehr viel Zeit und Geld investiert hat. Dieser Irrweg hat den Kunden fast 25T€ gekostet.
In einem anderen Post hatte ich schon geschrieben, dass wir gemeinsam die Reißleine gezogen haben und ich den Kunden dann JTL empfohlen habe. (Zum Verständnis: Der Kunde hatte zwei Unternehmen gehabt, beide sollten über Xentral als Mandanten laufen. Die o.g. DIEBEG für die es die VM-Shop-Anbindung gibt, wurde verkauft. Für das andere Unternehmen haben wir uns nun für JTL entschieden.)
JTL ist extrem solide, sehr stabil, leider keine OS und nicht LAMP baisiert sondern MS-SQL-Server basiert. Es bringt seinen eigenen Webshop mit, der ebenfalls grundsolide ist. In Verbindung mit der Wawi ist diese Lösung auch wirklich besser als VM. Speziell die gesuchte Kassenanbindung ist fantastisch. Der Support funktioniert bei JTL, obwohl man Ihn weit weniger benötigt weil auch die Tutorials, Community und Hilfseiten eine gut gefüllte Wissensquelle sind. Zudem gibt es kostenlose Workshops etc. Von JTL bin ich begeistert.
Für JTL habe ich mittlerweile für den Kunden eine Anwendung basieren auf Joomla4 entwickelt. Auch wenn Joomla an sich nicht die zu bevorzugende Wahl dafür ist (besser wäre vermutlich eine Framework wie Laravell gewesen) wurde sich trotzdem dafür entschieden, weil diverse Aufgabenstellung die Nähe zu den CMS-Funktionen anstrebte. Programmiert wurde ein Outfit-Manager als Prozesssteuerung, eine Kundenterminverwaltung und eine Transport-/Pick-listenverwaltung. Da JTL eine proprietäre Software ist und man in den Core kaum eigenen Code bekommt, wurde das außerhalb der Wawi als Joomla-Komponente realisiert. Kompliziert war der Datenbank-Connect zw. Joomla und JTL. Es gibt zwar auch für diese Zwecke eine API, aber da muss man dann mit dem vorhandenen Methodenumfang auskommen, was uns nicht reichte.
Hier mal mein Update zum Thema Xentral-Connector: Das Projekt ist nun seit über einem Jahr online (DIEBEG.de) und der Connector läuft stabil. Leider war der Support von Xentral so grottig und viele dem Kunden von Seiten Xentral-Vertrieb versprochene Funktionen nicht sauber oder noch immer nicht umgesetzt, so dass der Kunde entnervt aufgeben hat. Der Shop basierend auf VM wurde von Xentral abgekoppelt (was ja zum Glück problemlos möglich ist) und quasi stand-alone ohne Wawi betrieben.
Sollte wider Erwarten jemand Interesse an diesem Xentral-VM-Connector oder meinem dafür angesammeltem KnowHow, stehe ich gern zur Verfügung. In das Projekt ist sehr viel mehr Aufwand reingeflossen, als es der Kunde für mich durchfinanziert hat. Wäre also super, wenn es doch noch genutzt werden würde.
Ich habe erste Projekte unter Joomla3 auf VM4 geupdatet. Weitgehend ohne Probleme. Nutze allerdings eigenes Template über das Gantry5-Framework inkl. diverser VM-Template-Overrides.
Ich habe auch Probleme mit der Sprachdatei seit VM 4.0.2 und der Nachinstallation des deutschen Sprachpaketes festgestsellt. Allerdings vermute ich, dass wir auch im engl. so sein. Der Fehler äußert sich darin, dass manche Sprachstrings nicht ausgegeben werden.
Konkret aufgefallen war mir das im Produkt-Details-Default-Template für den Button "Zurück zur Kategorie XYZ". Der Text fehlte einfach im Frontend.
Ich habe das mal untersucht und ermitteln können, dass es immer die Sprachstrings sind, wo in VM mit der Methode sprintf gearbeitet wird. Letztlich konnte ich feststellen, dass in den Sprach-INI-Dateien die Platzhalter mit einem $ stehen also z.B. %1$s. Wenn ich das $ in der Sprachdatei rauslösche funktioniert es.
Syntaktisch ist das mit dem $ aber eigentlich nicht falsch aber vermutlich trotzdem falsch verwendet. Wenn ich die PHP-Regel zu sprintf richtig verstehe, ist es doch so:
Entweder ich verwende den Platzhalter mit einem Ordnungsoperator z.B. %1$s oder ohne, dann aber auch ohne $, also %s.
Aber das: %$s sollte fehlerhaft sein.
Also wenn meine Vermutung nicht vollkommen daneben ist, könnte dann bitte ein VM-interner Profi die Richtigkeit z.B. dieser beispielhaften Sprachkonstanten prüfen?!
Davon könnte es noch einige mehr geben und auch in der engl. Version.
Also ich habe mal in meinen VM-Sprachscripten alle %$s durch %1$s ersetzt und die Fehler waren weg.
Ich habe erste Projekte auf VM4.0.2 umgestellt (z.B. goldschmiede-schenk.de oder ), zwar noch unter J!3 aber erfolgreich und ohne Probleme. Allerdings nutze ich mein eigenes Template (basierend auf Gantry5 für Joomla und diversen Anpassungen/Overrides für VM). Auf Joomla 4 habe ich noch keines meiner J!3-Bestandsprojekte umgestellt, weil leider noch immer nicht alle Komponenten wirklich fehlerfrei unter J!4 laufen oder verfügbar sind (z.B. nicht BreezingForms, was ich in fast allen Projekten einsetze). Jedoch habe ich schon alle neuen Projekte, die seit Anfang 2022 entstanden sind, sofort unter J!4 aufgebaut. Eigentlich macht Joomla4 schon einen sehr stabilen und solide Eindruck. Habe es bisher nicht bereut. Ich bin mir ziemlich sicher, dass VM4 auch super auf J!4 laufen wird.
Also die Importer-API für VirtueMart als Connector zur Warenwirtschaft Xentral funktioniert jetzt schon mal in eine Richtung hin zum Shop. Man kann den Shop schon über Xentral füttern (Produkte, Kategorien, Bilder, Preise, Sonderpreise ...). Da die Kategorie-Verwaltung in Xentral nur sehr schmächtig war, wurde dafür gleich noch ein ArtikelbaumShop-Modul programmiert um alle VM-Kategorie-Features auch von Xentral aus bedienen zu können (Bilder, Beschreibungen, MetagTags, Sortierung, Parentkategorie). Das dazugehörige Erst-Echtprojekt geht sicher in 1-2 Wochen online. Wenn dann erste Bestellungen reinkommen, werde ich langsam die andere Richtung in die API programmieren, also die Übergabe der Kunden- und Bestelldaten an Xentral zwecks dortiger Auftragsbearbeitung/Versand/Rechung etc.
Werde hier weiter berichten. Wer Interesse hat an dieser Xentral-2-VM-API sollte sich bei mir melden.
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:
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)
oder man programmiert es selbst
Besten Dank für Dein Meinung.
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¤cy=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?
Danke Max!!!