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.
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”)
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?
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.
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
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.
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.
