Config im Theme erhalten - Oxid 7

Moin,
wir starten gerade unseren Shop, Module und Theme von derzeit OXID 6.1 auf den Preview von OXID 7 umzubauen da selbst OXID 6.2 mit unseren (ur) alten Modulen nicht funktioniert.

Bisher verwenden wir in unserem Theme [{assign var="oConf" value=$oView->getConfig()}] und dann [{assign var="categoryId" value=$oConf->getConfigParam('privateCategoryId')}]

In OXID 7 besitzt die Klasse \OxidEsales\EshopCommunity\Core\UtilsView nicht mehr die Methode getConfig sondern nutzt überall Registry::getConfig()

Wie ist hier der bevorzugte Weg im Theme an die Config zu kommen?

PS: Wir verstehen, dass OXID 7 bisher nur ein Release Candidate ist und noch nicht für Produktiv eingesetzt werden soll, daher bauen wir unsere Module auch bisher nur um mit dem Risiko/Hoffnung dass sich bis zur entgültigen Version von OXID 7 nichts wirklich groundbreaking passieren wird. Und wir nicht einen Migrationspfad von OXID 6.1 => 6.2 => 7.0 gehen müssen.

Moin @Dakota

wenn ich mir das Flow Theme in Version 4.0 angucke flow_theme/base.tpl at v4.0.0 · OXID-eSales/flow_theme · GitHub dann fällt auf, dass Dein Aufruf rausgeflogen OXDEV-4694 Remove getConfig usage · OXID-eSales/[email protected] · GitHub

Wenn Ihr bereits vorarbeiten wollt, dann wäre die Nutzung vom Twig Theme empfehlenswert GitHub - OXID-eSales/twig-theme: Templates based on the twig engine

Dazu gibt es auch ein Konverter Tool von OXID eSales welches Euch hilft Smarty Templates in Twig Templates umzuwandeln unter GitHub - OXID-eSales/smarty-to-twig-converter: A Tool to convert smarty template engine to twig template engine

Aber das Konverter Tool holt ca. 80% raus, 20% muss man noch händisch nacharbeiten.

Viele Grüße,
Tim

Wow, vielen Dank für deine schnelle Antwort @indianer3c und den Hinweis auf das Flow Theme.

Wir verwenden leider ein ebenfalls sehr altes Theme und mittlerweile komplett eigenes Theme auf Foundation CSS Basis anstatt Bootstrap z.B. - auf Twig umzusteigen ist langfristig eine gute Idee, aktuell haben wir aber leider nicht die Kapazität dafür und denken für den Moment ist es bessere die alten Module auf Composer und Metadata 2.1 umzubauen sowie Abhängigkeiten zwischen den Modulen und Theme zu verringern (derzeit sehr “zusammen gewachsen”) :slight_smile:

Um für den Moment das Theme unter OXID 7 zum laufen zu bringen wäre es der gangbarste Weg ->getConfig() über ein Modul in UtilsView wieder einzubauen - oder gibt es schönere Lösungen?

1 Like

Gerne.

Dies gestaltet sich meist schwierig. Weil dies ein Zusammenspiel ist.

Da wäre eine Überlegung wert komplett auf den Headless Ansatz zu wechseln über die OXID eSales eigenen GraphQL Module.

Dies wäre ein Ansatz um nach und nach das Theme zum 7er Shop zu migrieren.

Dein obiges Beispiel

[{assign var="oConf" value=$oView->getConfig()}]
[{assign var="categoryId" value=$oConf->getConfigParam('privateCategoryId')}]

deutet daraufhin, dass Ihr einen shopspezifschen Wert mit “privateCategoryId” als Konfiguration Variable hinterlegt habt.

Da wäre mein Ansatz zu prüfen wie häufig dies vorkommt und ob man dort nicht auf Controller-Basis für den jeweiligen Seitentyp gleich den entsprechenden Wert zurückliefert, anstatt ein ganzes Konfigurationsobjekt direkt im Smarty Template zu laden.

Beispiel Kategorie Controller erweitern um Methode z.B. getPrivateCategoryId() und in dieser Methode dann die Konfiguration Variable zu ermitteln.

Gehst du davon aus, dass OXID eine direkte Migration von 6.1 auf 7 anbieten wird, oder wollt ihr einen Relaunch machen?

1 Like

Gute Frage!

Weil das Update von 6.1 auf 6.2 ist mit den Modul Zuständen vom Wechsel von 2 Zuständen auf 4 Zustände bereits aus meiner Sicht ein Major Update. Dieser zahlenmäßige Sprung von 6.1 zu 6.2 dort trügerisch.

Zusätzlich wird es in der 6.5er Serie noch einen großen Sprung im Hintergrund geben, dadurch das die Symfony Components aktualisiert auf die LTS Versionen was wiederum die Syntax Änderungen in den 1.yaml Dateien mit sich bringen wird.

Dies hat wiederum Einfluss auf die 7er Serie, weil dort wird an einem zweiten Release Kandidaten gearbeitet welcher mit dem ersten Release Kandidaten dann so gut wie nichts mehr mit einander zu tun hat. Bzw. den Release 1 Kandidaten auf den Release 2 Kandidaten zu migrieren könnte Euch letztendlich große Mehrarbeit bescheren.

Daher wäre zum aktuellen Zeitpunkt davon abzuraten bereits auf den Release 1 Kandidaten zu aktualisieren.

Ich hoffe dies ist halbwegs verständlich. Für das Chaos ist aber die OXID eSales AG verantwortlich, welche anscheinend nicht weiß welchen Kurs Ihr Containerschiff einschlagen soll. Hoffen wir mal das Containerschiff ist nicht zu alt und läuft nicht auf Grund bevor es den Hafen erreicht :nerd_face:

Das verstehe ich, mir fällt es auch schwer hier die “sinnvollen” Grenzen zu ziehen. Ich könnte mir vorstellen, dass es (natürlich je nach Shop) of sinnvoll sein kann zum eigenen Theme bzw. child Theme ein eigenes Modul zu haben ohne das das Theme nicht funktioniert, alle weiteren Module aber über entsprechende Blocks ihre UI in das Theme integrieren - soweit machbar.

Danke, werde ich mir anschauen.

Nein, ich denke nicht dass es eine Migration hierfür gibt. Unsere Module selbst kommen mit 6.2 nicht klar, zudem sind unsere Module noch keine “Composer Module”. Mein Gedanke war hierbei hauptsächlich, dass wenn ich jedes Modul “komplett” umbauen muss im Sinne von neue Metadata, composer.json und verschiedenste deprecations und/oder bereits entfernte Core dependencies zu ersetzen wir den größtmöglichsten Sprung machen anstatt vieler Einzelschritte. Dazu dann die bisher komplett manuell gemachten DB Änderungen in Code zu schreiben über entsprechende (Modul) Migrations.

Danke auch hier für Deine Hinweise auf die verschiedensten Schritte und Unsicherheiten. Vielleicht ist es wie du schreibt dann doch eher Sinnvoll vorerst eher auf 6.4/6.5 zu aktualisieren und dann später die Änderungen zum 7.0 Release mit einzubauen.

Wir werden jetzt schauen wie wir möglichst pragmatisch unsere alten Komponenten aktualisieren und alles “wartbarer” machen via einzelne composer Module, dann sollten die jeweiligen Aktualisierungen auch einfacher verlaufen.

1 Like

Aus meiner Sicht deutet sich an, dass die 6.5er Serie am meisten Sinn dann macht. Weil damit eine Planungssicherheit bis Anfang 2025 aus technischer Sicht entstehen könnte.

Die 7er Serie leider noch weit weg. Damit verbunden auch noch zu viele Unsicherheiten wie die 7er Serie nun im Endeffekt wird.

1 Like