Moin in die Runde,
aktuell entwickle ich eine Sitepackage-Vorlage für V13 und möchte diese mithilfe von Sets umsetzen. Beim Kombinieren meines eigenen Codes mit erweitertem Code für Extensions kann ich mich jedoch noch nicht auf einen festen Workflow festlegen.
Der „Code für Extensions“ soll natürlich nur dann greifen bzw. geladen werden, wenn ich ihn tatsächlich nutze oder aktiviere. Daher ist – wie in diesem Beispiel – der Code für News standardmäßig immer in der Vorlage enthalten, aber auskommentiert oder deaktiviert.
Vielleicht kann jemand seinen Ansatz schildern oder mir sagen, ob ich irgendwo falsch abgebogen bin oder zu kompliziert denke. ;)
Meine eigentliche Frage: Wo platziere ich am besten bei Verwendung von Sets strukturiert erweiterndes z.B. typoscript für z.B. News?
Meine Gedanken:
Folgende Bestandteile kann eine Extension (in meinem Beispiel "News") bzw. ein Set haben:
- TSconfig - z. B. die Konfiguration für den LinkHandler
- Setup - z. B. Hinzufügen von AddNewsToMenuProcessor
- Settings - Alle Einstellungen, die News anbietet
- Dependencies - georgringer/news & georgringer/news-seo-sitemap
Wenn ich den möglichen Workflow im Alltag sowie die Datei-Struktur am Beispiel von News durchgehe, sehe ich drei Optionen:
1. Option: Alles im eigenen Sitepackage-News-Set
Hierbei liegen alle Informationen direkt im eigenen Sitepackage.
- TSconfig: Im eigenen News-Set
- Setup: Im eigenen News-Set
- Settings: Im eigenen News-Set
- Dependencies: Im eigenen News-Set
Workflow:
- Eigenes News-Set zur Site hinzufügen
- Änderungen an den Settings über das Dateisystem im eigenen News-Set vornehmen
- Anpassungen im Setup über FTP im eigenen News-Set durchführen
Fazit: Settings sollten in der Site-Config sein, damit sie im Backend bearbeitbar sind. Es wäre jedoch praktisch, alle notwendigen Änderungen ausschließlich im Dateisystem eines einzelnen Sets vorzunehmen.
2. Option: Eigenes News-Set + Settings in der Site-Config
Die Settings werden, wie vom Core und News vorgesehen, in der Site-Config verwaltet. Der Rest bleibt im eigenen News-Set, das je nach Bedarf zur Site hinzugefügt wird. Dabei werden auch die Sets von News selbst berücksichtigt.
- TSconfig: Im eigenen News-Set
- Setup: Im eigenen News-Set
- Settings: In der Site-Config (config/sites/customer/settings.yaml)
- Dependencies: Im eigenen News-Set
Workflow:
- Eigenes News-Set zur Site hinzufügen
- Änderungen an den Settings im Backend vornehmen (werden in der Site-Config gespeichert)
- Anpassungen im Setup über das Dateisystem im eigenen News-Set durchführen
Fazit: Besser als Option 1. Aber ist das der optimale Weg?
3. Option: Kein eigenes Set für News
Settings werden in der Site-Config verwaltet. Setup und TSconfig werden – wie früher – auf Dateien im Base-Set aufgeteilt.
- TSconfig: Im Base-Set (z. B. packages/sitepackage/Configuration/Sets/Base/TSconfig/news.tsconfig)
- Setup: Im Base-Set (z. B. packages/sitepackage/Configuration/Sets/Base/TypoScript/extensions/News/setup.typoscript)
- Settings: In der Site-Config (config/sites/customer/settings.yaml)
- Dependencies: Werden direkt der Site-Config hinzugefügt
Workflow:
- Externes News-Set zur Site hinzufügen
- Änderungen an den Settings im Backend vornehmen (werden in der Site-Config gespeichert)
- Anpassungen im Setup über das Dateisystem im Base-Set durchführen
Fazit: Diese Variante ist auch gut. Allerdings muss man beim Nutzen von News zusätzlich die Dependencies in die Site-Config eintragen und die auskommentierte TypoScript-include-Zeile für News im Base-Set einkommentieren.
Aktuelles Fazit der Fazits: 2. oder 3. oder ganz anders
Wie macht ihr das? 🤯