Klassenerweiterungen für product

[noRiddle (revilonetz)]

Ich erbitte hier die Meinung von Allen die wissen wovon ich rede zu folgendem Thema:

Mit den modified 2.0.X-Versionen kann man ja nun Klassenerweiterungen bauen die im Backend unter Module => Klassenerweiterungen Module aktiviert werden können.
Erstellt man eine Klassenerweiterung für product wird bei Nutzung der Funktion buildDataArray() das dort Definierte auf alles angwendet was buildDataArray() benutzt.
Das sind auch einige Boxen, wie z.B. best_sellers, last_viewed und weitere.

Ich habe nun folgendes Problem damit:
Eine product-Klassenerweiterung soll in den allermeisten Fällen auf das Produkt-Listing wirken, z.B. weil ich da etwas darstellen möchte wie z.B. Farben o.Ä..
Da jedoch parallel auch Inhalte in den o.g. Boxen mit erfasst werden wird Code ausgeführt der unnötig ist.
Das kann sogar bedeuten, daß für ein und denselben Artikel der Code zweimal ausgeführt wird, einmal weil er im Listing vorkommt und einmal weil er in einer Box vorkommt (z.B. last_viewed).

Das Ganze hat mehere unangenehme Folgen, die hier zu beschreiben zu weit führen würde weil es zig Anwendungsmöglichkeiten für eine solche Klassenerweiterung gibt und man dabei immer auf das genannte Problem trifft.

• Sieht jemand eine Möglichkeit die Produkte die in buildDataArray() übergeben werden so zu filtern, daß sie nur auf die Produkte im Listing greifen ?
• Ist unnötig und redundant ausgeführter Code (im Listing und in der ein oder anderen Box, wie oben beschrieben) nicht ein kleiner Performance-Killer ?
• Wenn es keine Filtermöglichkeit nach Punkt 1 gibt - ich habe keine gefunden - wäre es nicht gut eine solche bereitzustellen ?

Ich selbst halte die Implementation so wie sie jetzt ist für unglücklich, wenn nicht gar für schlecht.

Danke für Meinungen und Einsichten zu dem Thema.

Gruß,
noRiddle

Linkback: https://www.modified-shop.org/forum/index.php?topic=39957.0

[GTB]

Schau ob du ein bestimmtes DB Feld du zur Verfügung hast.
im Listing gibt es zB products_short_description was in der Box best_sellers nicht vorhanden ist.
Was ich allerddings für besser erachte ist ein Cache. Somit wird es für jedes Produkt nur 1x ausgeführt.

Gruss Gerhard

[noRiddle (revilonetz)]

Insider: Apropos Cache, kümmere mich bald, ist nicht vergessen.

products_short_description als Filterparameter ist eine seht gute Idee, danke dafür.
Insofern es so bleibt, daß in Boxen products_short_description nicht verwendet wird reicht das als Filter aus.
Z.B.:

Code: PHP  [Auswählen]

    function buildDataArray($productData, $array, $image) {
        if(array_key_exists('products_short_description', $array)) {
            ADD_SMTH_TO_$productData
        }

        return $productData;
    }

Damit wird dann auch nichts Ungewolltes ausgeführt.

Was Cachen bringen soll ist mir allerdings nicht klar.
Die Grund-Queries für Listing und Boxen
- so nenne ich sie mal und meine die jeweilige Haupt-Query, ohne die in der Klassenerweiterung -
sehen ja nicht gleich aus und somit auch nicht der buildDataArray() übergebene Parameter, das übergebene Array und somit auch nicht das Gecachte.
Oder übersehe ich etwas ?

Gruß,
noRiddle

[GTB]

Code: PHP  [Auswählen]

    function buildDataArray($productData, $array, $image) {
        static $add_products_data_array;
       
        if (!is_array($add_products_data_array)) $add_products_data_array = array();
       
        if (!isset($add_products_data_array[$array['products_id']])) {
       
            $add_products_data_array[$array['products_id']] = array(
              'ADD_SOMETHING' => 'blablablabla';
            );
        }
       
        $productData = array_merge($productData, $add_products_data_array[$array['products_id']]);
       
        return $productData;
    }

Ist es so verständlicher ?
Besser wäre noch die Variable in der Klasse slebst statisch zu deklarieren und darauf zuzugreifen.

Insider: Apropos Cache, kümmere mich bald, ist nicht vergessen.

es ist bereits im SVN 
aber auf Feedback freue ich mich.

Gruss Gerhard

[noRiddle (revilonetz)]

Achso, du meinst Cachen im Sinne von einer static Variablen und einer !isset()-Abfrage. Verstehe.

Zum Cache-Problem:
Da hat übrigens wieder jemand wahrscheinlich ein chmod-Problem. => Thread
Wie habt Ihr das gelöst ? (natürlich nicht in vorliegendem Thread zu behandeln)

Gruß,
noRiddle

[GTB]

Da hat übrigens wieder jemand wahrscheinlich ein chmod-Problem. => Thread

der hat den DB Cache aktiviert und da sollten ja Dateien geschrieben werden.

Gruss Gerhard

[noRiddle (revilonetz)]

Jaja, aber das Directory läuft voller und voller.
Das ist auch in diesem Thread ab hier mal besprochen worden.
Es liegt daran, daß ein Überschreiben bereits angelegter Files nicht funktioniert, und dies wiederum weil die Rechte aufgrund von Server-Restriktionen nicht korrekt gesetzt werden.
Ich dachte du hättest das damals mitbekommen, als du mir dann auch hier eine Frage zu Redis gestellt hattest.

Gruß,
noRiddle

[GTB]

Ich habe das durchaus verfolgt. Aktuell haben wir phpFastCache in Version 6.1.3 integriert. Das ist die letzte funktionierende Version auf PHP 5.x. Zudem unterstützen wir das Schreiben in andere Verzeichnise wie zB /tmp

Sollte es dennoch zu diesen Problemen kommen, dann ist die Investition in ein vernünftiges Hosting oder das abschalten des Cache notwendig.

Gruss Gerhard

[Timm]

Ticket #1380 kann ja dann geschlossen werden.

Von Version 3 zu 6 ist ja ein großer Sprung. Danke dafür. Ich versteh nur nicht ganz warum nicht gleich auf Version 7? Php 5.6 wird doch eh  von vielen Hostern nicht mehr eingesetzt und ist end of life. Wer eine neue Shopversion haben möchte, der muss dann halt endlich mal auf PHP >=7 gehen. Die PHP Versionen werden in Zukunft immer schneller von den Hostern abgeschaltet werden, wenn deren Lebenszyklus nur noch ein Jahr beträgt plus Zeit für Security Fixes. Das heißt dann muss die Arbeit nochmal gemacht werden und es wird sicher eh schon genug zu tun geben, wenn deprecated Features immer schneller auftreten durch die schnelleren PHP Updates. Mehr Nutzer mit aktuellen PHP Versionen würden auch mehr zum Fortschritt der Shopsoftware beitragen, weil mehr Fehler zu aktuellen PHP Versionen gemeldet werden würden (mal abgesehen davon, dass man im Interesse der Kunden und sich selbst eh keine nicht mehr unterstützte php Version einsetzen sollte).

Gruß Timm

P.S. Vernünftiges Hosting muss ja mittlerweile nicht mehr teuer sein. Gibt genügend gute Webhoster, wo das Problem nicht auftritt mit den falsch gesetzten Besitzern, Gruppen und Rechten.

[GTB]

Ticket ist geschlossen, danke Timm.

Solange wir PHP5.6 unterstützen bleibt die Version 6.1.3
Wir müssen ja nicht zwanghaft die PHP Version anheben.

Gruss Gerhard

[Timm]

Wir müssen ja nicht zwanghaft die PHP Version anheben.

Das klingt jetzt etwas blöd nach einem Update noch rumzumeckern und ist so auch nicht aufzufassen. Bitte als konstruktive Kritik aufnehmen.

Warum nicht mal vorausgehen? Warum die Kompatibilität zu einer unsicheren PHP Version gewährleisten für einige wenige und damit den überwiegenden Nutzerkreis beschneiden (weil neueste Versionen nicht integriert werden, um weiterhin alte PHP Versionen zu unterstützen)? Mir fällt einfach kein vernünftiger Grund dafür ein.

Veraltete Fremdmodule müssen dann halt hinterherziehen und wer solche Module noch nutzt kann solange nicht updaten bis diese vom Entwickler php 7 fähig gemacht werden.

Wär doch auch eine Einnahmequelle für Euch und andere Entwickler, wenn dann Anpassungen gemacht werden müssen. Mal abgesehen von möglichen positiven Effekten auf die Anzahl neuer modified Nutzer, die auch wieder Aufträge für alle Entwickler bringen.

Das ganze ohne zu wissen wie kompliziert im speziellen Fall die Einbindung von phpfastcache 7 gewesen wäre.

Gruß Timm

[wagners]

[...]
Wär doch auch eine Einnahmequelle für Euch und andere Entwickler, wenn dann Anpassungen gemacht werden müssen. Mal abgesehen von möglichen positiven Effekten auf die Anzahl neuer modified Nutzer, die auch wieder Aufträge für alle Entwickler bringen.
[...]

Sowas passiert dank der Hoster, die nach und nach die PHP-Versionen abschalten doch ohnehin automatisch. Da braucht die modified UG nicht erst künstlich rumdrücken, da der Tag kommen wird, wo die ganzen veralteten Shops und ihre eben so veralteten Module nicht mehr lauffähig sind. Wir haben es doch schon häufiger erlebt, dass hier User panisch Beiträge eröffneten, weil ihr Hoster die lfd. PHP-Version abgestellt hat. (Und irgendwann hilft halt kein PHP5.6-Fix mehr.)

[noRiddle (revilonetz)]

Um zum eigentlichen Thema zurückzukommen:

Code: PHP  [Auswählen]

    function buildDataArray($productData, $array, $image) {
        static $add_products_data_array;
       
        if (!is_array($add_products_data_array)) $add_products_data_array = array();
       
        if (!isset($add_products_data_array[$array['products_id']])) {
       
            $add_products_data_array[$array['products_id']] = array(
              'ADD_SOMETHING' => 'blablablabla';
            );
        }
       
        $productData = array_merge($productData, $add_products_data_array[$array['products_id']]);
       
        return $productData;
    }

Ist es so verständlicher ?
Besser wäre noch die Variable in der Klasse slebst statisch zu deklarieren und darauf zuzugreifen.
...

Damit verhindere ich, daß Artikel doppelt prozessiert werden, ich kann damit jedoch nicht auf das Listuing reduzieren.
Ich habe nur dies als Lösung gefunden (man bedenke auch CrossSelling und AlsoPurchased):

Code: PHP  [Auswählen]

    function buildDataArray($productData, $array, $image) {
       //prevent other products than listing (e.g. boxes) to be processed
        if(array_key_exists('products_short_description', $array) && $array['products_id'] != (isset($_GET['products_id']) ? $_GET['products_id'] : '')) {
            ADD_SMTH_TO_$productData
        }

        return $productData;
    }

Abgesehen davon, daß unnötig ausgeführter Code verhindert werden soll:
In meinem Fall wollte ich für die Boxansicht im Listing in der Lage sein die Einträge zu zählen die ich jeder Box hinzufügen möchte, um das Layout wegen unterschiedlich hoher Boxen nicht zu zerschießen.

Ich denke man sollte eine Möglichkeit finden einen Parameter an die Funktion buildDataArray() übergeben zu können der bestimmt auf was die Funktion genau angewendet werden soll.
Meine Lösung oben funktioniert zwar, steht aber insoefern auf wackeligen Füßen, daß eine Code-Änderung in zukünftigen modified-Versionen die Lösung leicht kippen könnte. Dafür würde es z.B. schon ausreichen auf der Produkt-Einzelansicht die products_short_description potentiell zur Verfügung zu stellen.

Gruß,
noRiddle