Neu Kritik an den Umgang mit strukturierten Daten und den Blocks

[Oliver Mayer]

Hallo JTL,

beim erstellen unseres ersten Shops hat alles super geklappt, erstmal ein grosses Lob an der Stelle. Ich entwickle seit Jahren Templates für viele gängige CMS und Shop Systeme und bin unter anderem auch Elite Author auf der Theme Plattform "Themeforest", daher denke ich das ich weiss wovon ich rede.

Es war wirklich überhaupt kein Problem ein eigenes Child Theme zu erstellen. Trotz allem haben mich während der gesamten Entwicklung 2 Dinge wirklich sehr gestört!

1.) Strukturierte Daten im Quelltext, warum? Das macht das ganze wirklich deutlich komplizierter! Das Markup ist aufgeblähter und schwerer zu lesen! Warum verwendet ihr nicht wie die meisten anderen Systeme auch das Schema.org anhand von JSON-LD?

Dies kann deutlich stressfreier eingebunden werden und ist losgelöst vom Markup des Templates. Ein Beispiel: ich habe die H1 Headline über den ganzen Content beim Produkt gebracht und die Bewertungen innerhalb der Headline. So jetzt wurden die strukturierten Daten nicht mehr korrekt erkannt und ich durfte manuell das ganze schema.org ändern weil es ja sonst nicht mehr passt.

Das ist wirklich nicht besonders "sinnig". Der grundlegende Sinn eines Templates ist ja das der "Code" von den Funktionsaufrufen getrennt ist.

Hier mal ein Beispiel des Shops und ein Link zu den JSON-LD Markup

https://www.kfz-batterie-ladegeraet.de/ctek-ladegeraet-mxs-5-0
https://developers.google.com/search/docs/guides/intro-structured-data

2.) Das zweite was ich wirklich als sehr störend empfand war eure Überzahl an "Blocks" im Template. Muss das den sein? Ich für meinen Teil denke das es am sinnigsten ist eine ganze Datei zu überschreiben und beim Update zu prüfen welche Teile sich verändert haben. Wer überschreibt den bitte teilweise pro Datei bis zu 40 Blocks? Das ist ja mehr als nur unübersichtlich.

Wenn ihr wirklich mit Blocks arbeiten wollt ist das ja ok, macht aber einfach wenig Sinn wenn ihr die Funktionen ohnehin per include reinholt. Beispiel sind die Produktdetails. Das sind ja ohnehin schon 20 oder 30 Dateien. Und jetzt sollte man hier auch noch die einzelnen Blocks überschreiben, egal ob per replace, append, prepend oder wie auch immer.

Macht euch doch darüber mal ein wenig Gedanken bitte ob dies der richtige Weg ist.

Viele Grüsse,
ein Fan im Anfangsstadium mit Drang zu Verbesserungen und optimierungen

 

[FMoche]

Danke für das umfangreiche Feedback.
Zumindest zu Punkt 2) eine Erläuterung:

Der bislang am häufigsten geäußerte Kritikpunkt von Entwicklern war, dass es zu wenige Blöcke gibt. Es ist also durchaus lustig, jetzt das Gegenteil zu lesen.
Davon abgesehen dürfte sie dich beim Erstellen eines Childtemplates ja nicht stören.

Der eigentliche Hintergrund für die erhöhte Anzahl an Blöcken ist aber auch nicht deren Verwendung in Childtemplates, sondern als möglichst flexibler Einstiegspunkt für Plugins.
Wir möchten so weit es geht von PHPQuery weg. Und es gibt nunmal eine Unzahl an Plugins, die an allen möglichen Stellen kleine Inhaltsblöcke einfügen möchten.

 

[Oliver Mayer]

Gern geschehen. Zu Punkt 2) genau das selbe dachte ich auch als ich das Child Theme angefangen habe das wirklich viele Blocks die ich benötigte fehlen.

Also gesagt getan und angefangen. Und schnell habe ich gemerkt das dass Child Theme mit Blocks zu erstellen viel zu aufwendig für meinen Geschmack ist. Besonders als ich dann mal angefangen habe Updates einzuspielen musste ich ständig überprüfen ob sich dieser Block verändert hat den ich überschrieben habe. Wenn ich aber die ganze Datei überschreibe kann ich mir die veränderten Stellen einfach anzeigen lassen und deutlich einfach abgleichen.

Ahh ok, ich verstehe das mit den Plugins natürlich. PHPQuery ist ja auch nicht die optimale Lösung. Hier kann ich euch aber auch empfehlen mal einen Blick in das Joomla CMS zu werfen, dort werden die Plugins auch eventbasiert gesteuert was sich sehr gut handeln lässt! Zumindest wenn ich Sie jetzt richtig verstanden habe ...

Ich bin jetzt auch kein riesen Fan von der Smarty Engine aber Sie tut was Sie soll und ist ja doch recht ähnlich wie PHP.

https://docs.joomla.org/Plugin/Events

 

[FMoche]

Mit Events hat das jetzt wenig zu tun (nutzen wir übrigens alternativ auch, vgl. https://gitlab.jtl-software.de/jtlshop/shop4/blob/master/classes/core/class.core.EventDispatcher.php).
Es geht um den Zugriff auf das durch Smarty gerenderte HTML.
Allein über Events kannst du ja auch in Joomla nicht das finale HTML modifzieren, sondern musst auch da Templates überschreiben/ergänzen.

 

[Oliver Mayer]

Das stimmt so leider nicht. Mit den Events kann ich problemlos die Ausgabe steuern. Ich habe bspw. ein Shortcode System entwickelt, wenn der User bspw. eingibt {button link="#" color="success" title="Text"} eingibt erzeuge ich eine HTML Ausgabe mit
<a href="#" class="btn btn-success">Text</a>

Das klappt problemlos und denke auch das ist das was ihr auch bezwecken wollt mit den Plugins. Die Ausgabe kurz vor dem Rendern zu verändern.

Aber kann auch sein ich liege da falsch, ist nicht mein Kerngebiet

 

[t.oster]

Da hier @FMoche mitliest ist das hoffentlich die richtige Stelle für meine doch sehr spezifische Kritik (in gitlab konnte ich leider keinen Quellcode-Kommentar abgeben):
Nach dem Update auf 4.06 wurde die articledetails/tabs.tpl ja komplett umstrukturiert, was dafür sorgt, dass mein Child Template nicht funktioniert. Was ich kritisieren möchte ist folgendes Konstrukt: https://gitlab.jtl-software.de/jtlshop/shop4/blob/master/templates/Evo/productdetails/tabs.tpl#L11

{$tabsPaneleArr['description'] = [
        'id' => 'description',
        'cName' => "{block name='tab-description-title'}{lang key='description' section='productDetails'}{/block}",
        'content' => '<div class="desc">' ,
        'content2' => {$Artikel->cBeschreibung},
        'content3' => '',
        'content4' => '</div>',
        'content5' => "{block name='tab-description-attributes'}{include file='productdetails/attributes.tpl' tplscope='details'}{/block}"
    ]}

Hier wird Smarty Code in eine Variable gepackt und unten ausgegeben. Diese enthält wieder einen Block. Warum das überhaupt funktioniert, ist mir schleierhaft, aber es funktioniert auf jeden Fall nicht den Block tab-description-attributes zu ersetzen! Wenn man das versucht kommt der auf einmal zweimal (WTF?), einmal mit ursprünglichem Inhalt und einmal mit dem ersetzten. Meiner Meinung nach war die tabs.tpl vorher relativ übersichtlich, aber jetzt ist sie sehr kryptisch. Außerdem scheint der Block tab-description-content komplett verschwunden?

 

[t.oster]

@FMoche entschuldigung für das nochmalige Missbrauchen dieses Threads aber du hast mich mit der Aussage

Der eigentliche Hintergrund für die erhöhte Anzahl an Blöcken ist aber auch nicht deren Verwendung in Childtemplates, sondern als möglichst flexibler Einstiegspunkt für Plugins.
Wir möchten so weit es geht von PHPQuery weg. Und es gibt nunmal eine Unzahl an Plugins, die an allen möglichen Stellen kleine Inhaltsblöcke einfügen möchten.

sehr neugierig gemacht. Ich finde bisher in der Doku keinen Hinweis darauf, wie man Blöcke in Plugins als Einstiegspunkt nutzt. Ich kannte bisher nur die DOM-Manipulation-via PhpQuery in Hook 140 Methode. Kannst du genauer erläutern, was du meinst und wie das geht?

 

[FMoche]

@t.oster Es ist bislang noch nicht dokumentiert, aber seit 4.06 kann man einfach im Pluginordner < shop-root>/includes/plugins/<plugin-id>/version/<versionsnummer>/frontend/template die Struktur des Frontendtemplates nachbauen und wie in ChildTemplates Blöcke modifizieren.
Im Example-Plugin hab ich da ein Beispiel:

https://gitlab.jtl-software.de/jtlshop/exampleplugin/commit/31c25373e6c68e87bc45ea8b6153692a2da28944

Hier erweitert also das Plugin die layout/footer.tpl des Templates - was komplett ohne PHPQuery auskommt.

 

[t.oster]

@FMoche danke für die schenlle Antwort. Das klingt interessant. Ich nehme an, das Plugin-Templates dann auch das Child-Template überlagern und später installierte Plugins frühere? In deinem Beispiel ist gar keine `{extends}` Zeile. Wird die implizit eingebaut? (d.h. ich kann nur einzelne Blöcke überladen, nicht ganze Templates?)

 

[FMoche]

Korrekt.

 

[css-umsetzung]

ich hab ja noch gar nicht wirklich danach geschaut, da es noch recht neu ist, das bedeutet dann das wir im Plugin, je nachdem, das Child oder das z.B. Evo als Parent haben?
Kann interessant werden wenn der, der das Child erstellt hat, meine verwendeten Blöcke herausoperiert hat.

Ich glaube ich muss mir das mal dringend anschauen, besser als phpQuery ist es aber in jedem Fall.

 

[ag-websolutions.de]

der das Child erstellt hat, meine verwendeten Blöcke herausoperiert hat.

Joo ... oder zwei/mehrere Plugins diese Technik nutzen und sich gegenseitig in die Quere kommen.

 

[css-umsetzung]

Ja, das wird echt spannend, wie das in der Praxis läuft, ich sehe schon die battles der SP im Slack, wer wessen Block unberechtigt geändert hat

 

[FMoche]

Joo ... oder zwei/mehrere Plugins diese Technik nutzen und sich gegenseitig in die Quere kommen.

Das kann dir mit pq() aber genauso passieren..

 

[css-umsetzung]

Aber dann geht man in der config vom plugin einfach auf eine andere Klasse oder ID die vorhanden ist.

Wie gesagt ich bin noch nicht dazu gekommen mir das anzuschauen, bisher kann der Shop Besitzer sich das ja selbst aussuchen welche klasse oder ID er nimmt (ist ja recht komfortabel), wenn er sich aber auf Blöcke beschränken muss die er ja eigentlich gar nicht sieht, weiß ich noch nicht genau wie das dann am besten konfigurierbar gemacht werden sollte.