Beiträge von Milbo

    Ich glaube verwaiste Dateien ignoriert die anderen Vorgaben. Die Sprachblase ist einfach erklärt. Wenn man z.B. das Download plugin benutzt, dann werden diese Dateien als verwaist angezeigt, weil der Core die Dateien nur nach Kategorie, Produkt, Hersteller, Verkäufer prüft. Aber ob irgendwelche Plugins das benutzen, übersteigt meine Fähigkeiten.

    Also ich war ja J4 sehr aufgeschlossen, weil ich die grundsätzliche Richtung, mehr libraries von symfony zu nutzen an sich sehr gut finde. Also J4 ist eigentlich ein symfony, welches ein Joomla baut. https://symfony.com/

    Aber da passt man alles an j4.0 an und j4.2 zerhaut alles.

    Aber wir lernen ja aus der Vergangenheit, bei j3 sagte ich gleich, wir gehen erst auf j3.5. Bei J4 schien das anderes zu werden. Es wurde viel mehr auf Aufmerksamkeit darauf gelegt, daß Entwickler eine Version anbieten können, welche auf j3.10 und j4.x läuft. Aber leider gibts da noch viel zu viel Bewegung. J4 ist sozusagen nicht stable.
    Stable, was heißt stable? Stable bedeuted gerade bei Platformen, wie Joomla UND Virtuemart eigentlich, daß sich die Bedingungen für 3rd party developers nicht ändern. Aus dieser Perspektive gesehen ist Virtuemart seit Version 2.6 relativ stable und seit vm3.0 sehr stable. Für Entwickler von Plugins ändert sich kaum was. Es gibt sogar einzelne vm2.6 plugins, welche weiterhin unter vm4 laufen. Wenn sie nicht mehr laufen, dann wegen joomla oder wegen PHP8.


    Ich sags die ganze Zeit und schreibs in die News. Der Fokus des Entwicklungsteams ist konservativ, die Priorität liegt auf joomla 3, ganz klar. Erst wenn Joomla 4 wirklich gereift ist, macht es Sinn sich völlig auf j4 zu konzentrieren.

    Momentan entwickle ich alles auf j3, Forum reports über j4, checke ich dann auf j4 und entwickle aber weiter auf j3 und teste halt obs auf j4 läuft. Es wird auch weiterhin durch die Memberships security bugfixes für j3 geben. So wie für j2.5 und j1.5. Wir haben da immer die EOL um ein paar Jahre nach hintenverschoben und das werden wir auch diesmal. j3 ist wirklich gut, imho wird es diesmal viel länger unterstützt, als j2.5 damals. Also ich glaube man kann j3 noch 5 Jahre und länger nutzen.
    Also das letzte Security problem war nur auf j4. J3 ist imho sehr hacksicher. Es gibt eigentlich keinen Grund j3 in die Tonne zu kloppen. Aber leider sind die Joomlaraner so typische "ich brauch den neuesten Scheiss" Typen. Leider.

    btw, ich habe Kunden, die sind noch auf j2.5! ungehackt.

    Hahah, interessante Lösung. Das gefällt mir. Aber es gibt eine einfachere lösung für das Problem. Aber ja das ist "nasty", da mußte ich mich auch erst reindenken und schrieb jahrelang PHP ohne dieses Wissen (haha, welche "Schande", naja es ist halt wirklich nur selten notwendig, aber ich stolperte immer wieder über dieses Problem, "hol den ersten eintrag, keine Ahnung die Id ist, interessiert mich auch nicht").

    Code
    1. reset($product->prices['VatTax']);    //setzt den array Zeiger auf die erste Position https://www.php.net/manual/de/function.reset.php
    2. $mwStWert = current($product->prices['VatTax']);    //holt den Wert, wo der Zeiger gerade steht. https://www.php.net/manual/de/function.current.php
    3. echo 'inkl. '.round($mwStWert).'% Mwst.';

    Da in deinem Falle die Foreach sowieso nur einen Eintrag hat (imho immer), ist es sogar fraglich ob deine Version soviel langsamer wäre. Naja, im Zweifel doch einige Takte mehr. Allerdings frage ich mich, ob ich das nicht umschreiben sollte. Ich glaube die Zahl ist die ID der Steuerregel.

    Btw, das ganze ist komplett mit den Befehlen "end", "prev" und "next". Man kann also eine foreach auch als while schleife schreiben, aber is immer kagge, wegen den Abbruch Bedingungen. eine While schleife sollte immer eine Abbruchbedingung haben. Gab da mal ne Untersuchung darüber. 95% der Schleifen (oder so) sind daher mit for bzw foreach.

    Danke Milbo,
    .....
    2. Nun habe ich in der Datei /template/NAME/html/com_virtuemart/sublayouts/prices.php weitergesucht und folgende Änderungen ausprobiert:

    2.1. Aktivierung des VMDebug Ergebnis: Egal, an welche Stelle ich die Zeile vmdebug('My product',$product->loadFieldValues()); hinterlege; es kommt beim Aufruf im Frontend immer die Warnung => Call to undefined method stdClass::loadFieldValues()

    Ja, "lustig", oder? Den Fehler hatte ich dann einen Tag später auch und wunderte mich, wie ich die Ausgabe erhalten habe. Werde mich aber um das Rätsel später kümmern

    2.2. Als nächstes habe ich dann versucht, die Zeile $product->prices['VatTax'][1][1]; mit zu integrieren. Das habe zwischen folgende Zeilen gepackt:


    $infotax = vmConfig::get('vm_prices_info_tax', 0);

    $product->prices['VatTax'][1][1];

    $infodelivery = vmConfig::get('vm_prices_info_delivery', 0);

    Nach meinem Verständnis, müsste ja nun etwas zwischen "inkl. MwSt. zzgl. Versandkosten" dazwischengepackt werden. Aber leider keine Erfolg.
    Wo habe ich denn hier einen Denkfehler?

    Eigentlich keinen wirklichen. Also letztendlich geht der Code für eine schöne formattierte Ausgabe doch etwas anders, merk ich grade. Entweder man nimmt den Namen, in meinem Falle steht dann da Tax 20%. Also

    Code
    1. echo $product->prices['VatTax'][1][0];

    Oder man baut es sich zusammen, also das wäre so

    Code
    1. echo 'inkl MwSt: '.round($product->prices['VatTax'][1][1],0).'%';


    Übrigens, wie kann ich den den Quelltext als Code, wie bei Dir oben in diesen Editor einfügen? Der Quellcode und auch der Inlinecode funktioniert dazu nicht.

    Im hintergrund arbeitet ein html editor. Kann man oben ganz links ansehen, was im Hintergrund passiert. Oben rechts neben der Sprechblase kann man Absätze als Code definieren. Aber in meinem Falle hat der das beim kopieren erkannt und automatisch gemacht. Mußte auch erstmal suchen.

    Haste dir das schonmal durchgelesen? https://docs.virtuemart.net/tu…basics-for-templater.html

    Es ist alles da. Es ist günstig die debug möglichkeiten von vm zu nutzen. Also bau mal in der default.php das ein

    Code
    1. vmdebug('My product',$this->product->loadFieldValues());
    2. //bzw in prices.php
    3. vmdebug('My product',$product->loadFieldValues());

    Man kann vmdebug grundsätzlich wie console.log in js benutzen. Also

    Code
    1. vmdebug('My product',$myValue1, $interestingValue2, $WasIshier, ...);

    Im oben Falle braucht man das loadFieldValues, damit der nicht die verlinkte db des VmTables mitlädt.


    Dann vmdebug für admins aktivieren, auf der Seite einloggen und man sieht die Ausgabe (geht daher live!). Da sieht man dann die Ausgabe für "My product" und ne menge anderen Krempel, das einfach ignorieren. My product is auf jeden Fall die größte Ausgabe darin, also nicht zu übersehen. Ganz oben bei der Ausgabe für "My product" steht "Array", das liegt an loadFieldValues, es ist eigentlich ein Object! Also eigentlich sollte da Object stehen und nicht Array. Ansonsten wirds jetzt einfach.

    Man sieht da ein Array "allPrices", das erstmal ignorieren, wir scrollen weiter zu "prices" was wieder ein array ist. Dort gibts wieder ein Unterarray und das heisst VatTax, dort steht die benutzte Tax drin. Also bei mir sieht in etwa so aus.


    Also bekommt man mit

    Code
    1. $this->product->prices['VatTax'][1][1]

    den exakten Steuerbetrag.

    Sollte ich wohl mal in ein manual packen. Ich wüßte nicht, wie ich das über das EuvatId plugin machen könnte, da nach meiner Erfahrung gerade das Preislayout am ehesten angepasst wird.

    Ahja, und weil du im sublayout bist, ist es immer $product und nicht $this->product

    Haste das mit einer "neuen alten" Version getested? Kann man nur testen, wenn man einen alten shop updated. Der shop wo bereits die config gespeichert wurde, hat ja den Fehler nicht mehr.