Zikula 3 - Cross-Release und weitere Ausrichtung

in  Zikula Apps , , , ,

Zikula 3 - Cross-Release und weitere Ausrichtung

Heute sind gleichzeitig zwei neue Versionen vom Zikula Core veröffentlicht worden.

Zikula 3.0.4 bringt Fehlerkorrekturen

Mit der Version 3.0.4 wird ein weiteres Bugfix-Update für die Hauptversion 3 bereitgestellt.

Die Änderungen im Detail werden in der Release-Ankündigung aufgelistet.

Zikula 3.1.0 hat etwas mehr an Bord

Außerdem ist auch Zikula Core 3.1.0 erschienen; dieses Update beinhaltet zusätzlich einige Neuerungen, bringt aber auch Veränderungen mit.

Auch hierfür gibt es eine detaillierte Liste mit den Korrekturen, hinzugefügten Features und sonstigen Neuerungen.

Die wichtigsten Änderungen werden hier noch einmal kurz vorgestellt:

  • Die dynamischen Einstellungen vieler Systemmodule, welche nicht in der Datenbank gespeichert, sondern als Parameter im Symfony-Container verfügbar gemacht werden, schreibt das System nun nicht mehr mit dem DynamicConfigDumper in die Dateien config/dynamic/*.yaml. Statt dessen werden, wie man es im Symfony-Umfeld kennt, eigene Bundle-Konfigurationen verwendet. Mit Hilfe einer Klasse Zikula\Bundle\CoreBundle\Configurator können diese dennoch zur Laufzeit vom System verändert werden.
  • Der Zikula Core nutzt nun ebenfalls Symfony Flex.
  • Das Action-Suffix bei Controller-Methoden entfällt ab sofort.
  • Ein neues Modul StaticContent erlaubt das Darstellen vordefinierter Seiten via Templates. Auch einige Blöcke aus dem Blocks-Modul wurden dort hinein kopiert, um sie zukünftig aus dem Blocks-Modul zu entfernen.
  • Ein neues Hook-Konzept wurde eingeführt, welches sowohl für Entwickler als auch für Bediener einfacher wird.
  • Das Theme-Modul verwendet das WebpackEncoreBundle, um automatisch Webpack-Assets über einen Listener hinzuzufügen.
  • Als Authentifizierungsmethode wird nun per Standard native_either verwendet.
  • Ein neues DefaultTheme löst das bisherige BootstrapTheme ab.

Was ist als nächstes angedacht?

In den letzten Wochen haben wir einige Überlegungen dazu angestellt, wie wir mit der Entwicklung weiter vorgehen wollen. Nachfolgend ein paar Punkte, die wir charmant finden:

  1. Zuerst wollen wir den Bundle-/Modul-Generator von ModuleStudio auf die ausschließliche Verwendung von PHP 8 und Zikula 3 umstellen. Hier wird also der Support für einige ältere Versionen rausfliegen. Dann werden wir ihn überarbeiten und auf noch aktuellere Best Practices aktualisieren, insbesondere im Hinblick darauf, wie Doctrine Repositories genutzt und erweitert werden. Die Idee ist, dass der Generator in der Lage ist, die neue “Blaupause” dafür zu erstellen, wie Erweiterungen aussehen sollten. Wir haben in den letzten zwei Jahren neuen Input gesammelt und spannende Dinge gelernt, so dass sich einige Ideen aufgestapelt haben und darauf warten, in Zikula anzukommen.
  2. Im Frühling/Sommer 2022 planen wir ein Pilotprojekt, anhand dessen wir überprüfen wollen, ob die Dinge wie erwartet funktionieren.
  3. Für Zikula Core 4 haben wir eine grundsätzliche Änderung im Sinn:
    • Anstatt in den Zikula Core sowohl Symfony als auch verschiedene Drittanbieter-Ergänzungen einzubetten, wird Symfony die Kontrolle übernehmen. Das bedeutet, dass man Zikula System-Bundles wie jede andere Erweiterung mit Composer und Flex einbinden kann. Die zusätzliche Verwaltungsschicht für Erweiterungen wird und kann somit komplett entfallen.
    • Es wird weiterhin eine offizielle Distribution geben, um mit dem kompletten Zikula zu arbeiten. Aber es wird auch möglich sein, z.B. nur das Theme Layer ohne andere Zikula-Komponenten zu verwenden - oder nur das Benutzersystem und die Permissions von Zikula zu verwenden. Das bedeutet eine gravierende Änderung: im Moment bekommt man nur Zikula komplett oder gar nicht. Mit der Core-Version 4 kann man dann auch mit einem normalen Symfony beginnen und nachträglich einige Zikula-Bundles hinzufügen, wenn man das möchte - so wie man es mit allen möglichen anderen Bundles gewohnt ist. So werden die Dinge viel kompatibler zueinander.
    • Wir müssen hierbei eine Differenzierung vornehmen: Wo macht es wirklich Sinn, unsere Energie zu investieren? Wo ist der Mehrwert von Zikula Core? Wie können wir das Symfony-Ökosystem noch stärker nutzen, ohne unsere derzeitige Flexibilität aufzugeben? Zum Beispiel muss der ModuleStudio Generator immer noch in der Lage sein, sich auf einige Konventionen zu stützen, die wir etabliert haben und die mit einfachem Symfony nicht gültig sind. Es ist nicht einfach, hier eine Grenze zu ziehen, z.B. wie viel von unserem Benutzersystem brauchen wir so wie es ist und inwieweit könnten wir auch mit anderen Implementierungen von UserEntity arbeiten.
    • Mit ModuleStudio generierte Erweiterungen sind dann im Prinzip keine Zikula-Module mehr, sondern Symfony-Bundles, die aber einige Zikula Core Bundles erfordern. Wenn eine modellierte Erweiterung zum Beispiel Kategorien verwendet, benötigt das generierte Bundle entsprechend das zikula/categories-module.
  4. Um wiederholte Arbeit zu vermeiden und das erforderliche Maß an Entkopplung von Dingen voneinander zu vereinfachen, kann es von Vorteil sein, einige Core System-Bundles mit Hilfe des Generators neu zu implementieren. Als Ergebnis der Punkte 1 und 2 sollte es möglich sein, die Modernisierung von Systemmodulen zu beschleunigen, indem ein großer Teil ihres Codes generiert wird. 🚀
  5. Um den Wartungsaufwand in anderen Bereichen zu reduzieren, wollen wir prüfen, wo wir mehr Nutzen aus bestehenden Lösungen im Symfony-Ökosystem ziehen können. Zum Beispiel könnte Scribite Symfony-Bundles (wie FOSCKEditorBundle) einbinden/ummandeln und vereinfacht ausgedrückt als Wrapper fungieren, so dass wir die Editoren nicht selbst auf dem neuesten Stand halten müssen. Gleichzeitig können wir den Vorteil beibehalten, dass die Editoren dynamisch geladen werden (in Formulartypen ließe sich immer noch TextType anstelle von CKEditorType verwenden). In ähnlicher Weise müssen wir erneut prüfen, wie wir bestehende Content-Management-Lösungen für den Umgang mit Medien usw. nutzen können, anstatt alles selbst zu machen und zu erfinden. Es gibt mächtige CMS, die auf Symfony basieren (z.B. Bolt, Sulu, etc.), vielleicht können wir eines davon für unsere Zwecke verwenden.

Es bleibt also wie immer spannend 😄

Wohin mit dem Feedback?

Fehler und sonstige Probleme sollten auf GitHub gemeldet werden. Dort können die Entwickler diese Rückmeldungen sichten und einarbeiten.

Zur Klärung von Fragen, bei Anregungen und für sonstige Diskussionen stehen die Zikulaner gerne auch in Slack bereit.

Weitere Beiträge in Kategorie Zikula Apps

Kommende Neuerungen in Symfony 5.4
- Vor einigen Tagen wurde Symfony 5.4.0-BETA3 veröffentlicht. Dies nehme ich zum Anlass, um einmal einen Überblick über die wichtigsten neuen Funktionen zu geben, auf die wir uns im Rahmen dieses …
Kommende Neuerungen in Symfony 5.3
- Vor zwei Tagen wurde Symfony 5.3.0-BETA4 veröffentlicht. Dies nehme ich zum Anlass, um einmal einen Überblick über die wichtigsten neuen Funktionen zu geben, auf die wir uns im Rahmen dieses Updates …
Symfony Messenger - Behandlung erneut fehlgeschlagener Nachrichten
- Im Symfony Messenger gibt die Möglichkeit, fehlgeschlagene Nachrichten an eine failed queue zu leiten. In diesem Sammelbecken können diese dann inspiziert und nach Korrektur des zu Grunde liegenden …
Response-Eigenschaften im Zikula Theme-Layer anpassen
- In Zikula gibt es eine Besonderheit zu beachten, welche Einfluss darauf nimmt, wie die aus einem Request resultierende Response zum anfragenden Client gelangt. Per Standard wird die Response in …
Tabellennamen mit Doctrine dynamisch anpassen
- Mit Hilfe der Metadaten von Doctrine lassen sich jegliche Daten zu einer Entität zur Laufzeit verändern. Allerdings kann das in manchen Anwendungsfällen fortwährend notwendig sein, zum Beispiel in …