Override für shopfunctions.php

    Hallo,
    ich musste ./administrator/components/com_virtuemart/helpers/shopfunctions.php zur Anzeige zusätzlicher Gewichtseinheiten im Backend modifizieren.
    Wo gehört die modifizierte Datei hin?
    Funktioniert das im Backend-Template wie im Frontend?


    Joomla 2.5.20
    VM 2.6.7


    FG
    HaeF

    Der Grund warum wir nicht mehr ISO Einheiten haben, ist das es dann eben nicht mehr nach der deutschen PangV ist. Daher wundert mich das etwas. Ausserdem müssen die auch in die Umrechnungstabelle.


    Schöner wäre wir nutzen im Chosen.js einen Trenner "ISO", "Sonstige" und dann tragen wir deine Erweiterungen einfach in den Core ein. Problem war bisher halt nur, dass man dann nicht weiss, welche nach Gesetz sind und welche halt "sonstige" sind.


    Deswegen ist VM ein Projekt, jeder kann prinzipiell mitmachen. Wie sieht dein Code aus?

    Es geht um einen Shop, der Vanille verkauft. Da geht es nach "Schoten" und "Stück". Letzteres wird wohl öfter vorkommen.
    In der shopfunctions.php:



    static function getWeightUnit () {
    static $weigth_unit;
    if ($weigth_unit) {
    return $weigth_unit;
    }
    return $weigth_unit = array(
    'KG' => JText::_ ('COM_VIRTUEMART_UNIT_NAME_KG')
    , 'G' => JText::_ ('COM_VIRTUEMART_UNIT_NAME_G')
    , 'ML' => JText::_ ('COM_VIRTUEMART_UNIT_NAME_ML')
    , 'L' => JText::_ ('COM_VIRTUEMART_UNIT_NAME_L')
    , 'SCH' => JText::_ ('COM_VIRTUEMART_UNIT_NAME_SCH')
    , 'SCHE' => JText::_ ('COM_VIRTUEMART_UNIT_NAME_SCHE')
    , '100ML' => JText::_ ('COM_VIRTUEMART_UNIT_NAME_100ML')
    , 'ST' => JText::_ ('COM_VIRTUEMART_UNIT_NAME_ST')
     );
    }


    und

    static function renderUnitIsoList($name, $selected){


    $weight_unit_default = array(
    'KG' => JText::_ ('COM_VIRTUEMART_UNIT_SYMBOL_KG')
    , '100G' => JText::_ ('COM_VIRTUEMART_UNIT_SYMBOL_100G')
    , 'M' => JText::_ ('COM_VIRTUEMART_UNIT_SYMBOL_M')
    , 'L' => JText::_ ('COM_VIRTUEMART_UNIT_SYMBOL_L')
    , '100ML' => JText::_ ('COM_VIRTUEMART_UNIT_SYMBOL_100ML')
    , 'ST' => JText::_ ('COM_VIRTUEMART_UNIT_SYMBOL_ST')
    , 'SCHE' => JText::_ ('COM_VIRTUEMART_UNIT_SYMBOL_SCHE')
    , 'SCH' => JText::_ ('COM_VIRTUEMART_UNIT_SYMBOL_SCH')
     );
    foreach ($weight_unit_default as $key => $value) {
    $wu_list[] = JHTML::_ ('select.option', $key, $value, $name);
    }
    $listHTML = JHTML::_ ('Select.genericlist', $wu_list, $name, '', $name, 'text', $selected);
    return $listHTML;
    }

    Selbstverständlich müssen die Sprachdateien auch angepasst werden (SCHE=Schoten, SCH=Schote, ST=Stück).


    Preis/100ml, Preis/100g, Preis/Stück sind korrekte Angaben. Ebenso alle anderen, die den Preis/Grundeinheit der Mengenangabe der Fertigpackung liefern.
    Die Angabe Preis/Stück ist auch ein Dummy. Was mach ich sonst mit den eingeflickten Feldern bei Waren, bei denen die Angabe
    nicht vorgeschrieben ist?
    Siehe Arbeitsinstallation:
    Bourbon Vanille aus Madagaskar


    FG
    HaeF

    Keine Overrides für Core-Dateien,
    Das beste ist ein Diff-Programm zu verwenden, und dann die einzelnen Dateien vergleichen.


    Ich mache mir dazu pro Seite immer eine Liste der "bösen" Dateien, die man nicht als Override anlegen kann. So eine Art Update-Manual, da kommt alles sofort hinein, was im Core verändert wird, damit man nachher nicht suchen muss.


    Wenn man zum Beispiel mit Total Commander die alten und neuen Installationsverzeichnisse aufmacht und dann die einzelenen Dateien vergleicht, dauert das oft nur ein paar Minuten.


    So long
    Stefan

    Hattu richtig. Mach ich auch so, aaaber...
    Wenn in der upgedateten Datei was geändert wurde, was vielleicht sicherheitsrelevant ist, musst Du Deine Änderungen jedesmal neu einarbeiten. Sollten eigentlich in Updates nicht nur Dateien aufgespielt werden, in denen tatsächlich etwas geändert wurde?
    Konnte nämlich nix feststellen.


    FG
    HaeF

    Servus,


    ja, das wäre schon eine feine Sache, wenn man per Patch einfach nur die betreffenden Dateien austauschen könnte.


    Wenn man das SVN auscheckt, dann kann man sehen, welche Dateien verändert wurden und nur diese übernehmen. Zum SVN steht was in der Developer-Ecke auf virtuemart.net. Ich benutze das mehr oder minder seit einem Jahr und wenn das einmal läuft, ist das sehr einfach.


    Ich nehme an, die Erstellung eines Patches, der nur die Veränderungen enthält, macht einfach noch einmal extra Arbeit, und deshalb wird der einfachere Weg genommen, der wahrscheinlich für 90% der Benutzer ohne Probleme funktioniert.
    Rein theoretisch muss man auch alle Overrides überprüfen, bzw. die neuen und die alten Originaldateien für die Overrides bestehen. Macht nur fast niemand, weil, wenn es läuft, dann läuft es ja, deshalb ist auch diese Override-Geschichte nicht vollends benutzerfreundlich bzw. sicher.


    So müssen wir uns halt mit den einen oder anderen Dingen herumschlagen, das bleibt wohl nicht aus. ;-)


    Grüße
    Stefan

    Zitat von StefanSTS

    Servus,


    Rein theoretisch muss man auch alle Overrides überprüfen, bzw. die neuen und die alten Originaldateien für die Overrides bestehen. Macht nur fast niemand, weil, wenn es läuft, dann läuft es ja, deshalb ist auch diese Override-Geschichte nicht vollends benutzerfreundlich bzw. sicher.
    Grüße
    Stefan


    Zumindest bei den Language Overrides wird es wohl eine kleine aber wichtige Änderung geben: https://github.com/joomla/joomla-cms/pull/5877


    Bisher bestand die Möglichkeit, sich seine bestehenden Language Overrides zu zersemmeln,
    indem man einfach einen KEY nach einem der in PHP reservierten Wörter [YES, NO, TRUE, FALSE, NULL, NONE] benennt.
    Das führte dazu, das wenn der neue KEY abgespeichert wird, die entsprechende xx-xx.override.ini nur noch den frisch angelegten Key enthält.


    Der oben genannte Pull-Request (so denn sich infograf und brian darauf einigen können, wie denn die entsprechende Fehlermeldung lauten soll) verhindert dann in der neuen Version das entsprechende Anlegen solcher Overrides.


    Gruß,


    Bluezeyes