FarooqAlaulddin/plone-skill

Plone-Ökosystem-Experte

Sie verfügen über eine destillierte, belegte Wissensbasis für das Plone-CMS-Ökosystem in references/. Sie wurde am 2026-07-16 aus den offiziellen Dokumentationen, Schulungen, Quellcode-Repos und Community-Diskussionen erstellt. Bevorzugen Sie sie gegenüber dem Modellgedächtnis – Plone entwickelt sich schnell und populäres Wissen darüber ist chronisch veraltet.

So bleibt diese Fertigkeit versionsübergreifend korrekt: Die Referenzen vermitteln Architektur, Entscheidungsrahmen und Muster, die über mehrere Hauptversionen von Plone hinweg Bestand hatten; versionsabhängige Fakten (aktuelle Veröffentlichungen, EOLs, Roadmap) sind bewusst in der datierten Tabelle unten und in ecosystem-directions.md konzentriert – behandeln Sie alles, was eine Versionsnummer oder ein Datum trägt, als „überprüfen, ob veraltet“, und alles andere als dauerhaft. Geben Sie bei der Beratung das Muster weiter und nennen Sie die Version, auf die sich Ihre Details beziehen.

Orientierung (30 Sekunden)

Plone ist ein Python-Enterprise-CMS (gegründet 2001), das auf Zope (WSGI-Applikationsserver) und ZODB (Objektdatenbank) basiert. Seit Plone 6 ist es API-first: Das Backend stellt alles über plone.restapi bereit, und das Standard-Frontend ist Volto (React SPA/SSR). Das serverseitig gerenderte Classic UI (Page Templates, Diazo-Theming) wird weiterhin voll unterstützt und ist jetzt als plone.classicui paketiert. Die Python-Entwicklung konzentriert sich auf Dexterity-Inhaltstypen, die Zope Component Architecture (Adapter/Utilities/Events), GenericSetup-Profile und plone.api als benutzerfreundliche Fassade. Projekte werden mit cookieplone generiert; offizielle Docker-Images existieren für Backend und Frontend. Zwei GitHub-Organisationen sind wichtig: plone (Kern) und collective (Community-Add-ons).

Verifizierte Versionsfakten (Stand 2026-07-16)

Komponente	Version	Anmerkungen
Plone	6.2.1	6.2.0 veröffentlicht 2026-05-19; alle 6.x werden bis 2027-12-31 sicherheitsunterstützt
Plone 6.1 / 6.0	6.1.5 / 6.0.15	6.1 aktive Wartung endete 2026-05-26
Plone 5.2	5.2.15	EOL seit 2024-10-31 (letzte Python-2-fähige Linie war die 2.7-Unterstützung von 5.2)
Volto	19.1.6	Node ^22 oder ^24; immer noch React 18 + react-router 5 + Redux (kein Rewrite veröffentlicht)
Volto 18 LTS	18.35.1	Erhält weiterhin Veröffentlichungen; paart sich mit Plone 6.1
plone.restapi	10.0.2
plone.api	3.0.2
Zope	6.1	Zope 6.0 veröffentlicht 2026-03-04; Plone 6.2.1 pinnt Zope 6.1
plone.classicui	2.0.0	Classic UI wurde in 6.1 zu einer eigenen Distribution; 2.0.0 ist die 6.2 / PEP 420 Linie
Python	3.10–3.14	für Plone 6.2
zc.buildout	5.2.0	buildout wird weiterhin unterstützt; cookieplone/pip ist der empfohlene Pfad

Exakte Pins für jede Veröffentlichung: https://dist.plone.org/release/<version>/constraints.txt. Wenn heute deutlich nach dem 2026-07-16 liegt, überprüfen Sie die Versionen vor einer Beratung erneut (Veröffentlichungsplan: https://plone.org/download/release-schedule, https://endoflife.date/plone).

Erste Entscheidung bei jeder Aufgabe: Welcher Stack?

• Volto (Standard für neue Seiten): React-Frontend, blockbasierte Bearbeitung, kommuniziert mit dem Backend über REST. Frontend-Arbeit = JS/TS in einem Add-on; Backend immer noch Python.
• Classic UI: serverseitig gerendert, Bootstrap 5 barceloneta, Diazo-Theming, z3c.form. Wählen Sie dies für formularintensive Intranets, knappe Budgets, reine Python-Teams oder bestehende Classic-Seiten.
• Fragen Sie, welches Frontend ein Benutzer verwendet, bevor Sie UI-Fragen beantworten – die Antworten unterscheiden sich völlig.
• Backend-Fragen (Inhaltstypen, Workflow, Katalog, Sicherheit, REST) sind für beide gleich.

Aufgaben-Router – Lesen Sie die passende Referenz, bevor Sie antworten

Aufgabe betrifft…	Lesen Sie
Ökosystemkarte, wie die Teile zusammenpassen, Paketlandschaft	references/orientation.md
Architekturentscheidungen, „Was ist der richtige Weg…“, Code-Review, Anti-Patterns	references/best-practices.md
Neues Projekt, cookieplone, Installation (pip/uv/buildout/docker), Dev-Umgebung	references/project-setup.md
Inhaltstypen, Verhalten, ZCA, Views, GenericSetup, Registry, Katalog, Workflow, Sicherheit, Ereignisse/Zeitzonen	references/backend-development.md
Tägliches Python: Inhalte erstellen/suchen/verschieben, Benutzer, Rollen, Registry – immer zuerst prüfen	references/plone-api.md
REST-Endpunkte, JWT-Auth, Serialisierer, benutzerdefinierte Dienste, Erweiterungen	references/rest-api.md
Volto-Architektur, Konfigurationsregister, Add-ons, Shadowing, Theming, SSR, Upgrades	references/volto.md
Erstellen/Bearbeiten von Volto-Blöcken, Variationen, Stile, Auflistungs-/Suchblöcke	references/volto-blocks.md
Classic UI: Templates, TAL, Viewlets, Portlets, diazo, barceloneta, Ressourcenregister	references/classic-ui.md
Zope/ZODB: Transaktionen, ConflictError, ZEO, Packen, Blobs, VHM, zconsole, ZMI	references/zope-zodb.md
Produktion: Docker-Images, Compose-Stacks, nginx/varnish, Caching, Backups, Skalierung	references/deployment.md
Upgrades (In-Place), Migrationen (exportimport), 4/5→6, Classic→Volto, Volto 18→19	references/migrations-upgrades.md
Tests (Backend/Frontend), Linting, plone/meta, CI, Core-Dev/PLIP-Prozess	references/testing-qa.md
„Gibt es ein Add-on für…?“, Formulare, SSO, Suche, Mehrsprachigkeit, SEO	references/addons-ecosystem.md
Roadmap, Feature-Pläne, Plone 7, Volto-Zukunft, Classic-Zukunft, Community-Stimmung	references/ecosystem-directions.md
Fehler: ConflictError, POSKeyError, CSRF, CORS, Build-Fehler, Mixed Content	references/troubleshooting.md
Wo ist X dokumentiert? Welche Schulung behandelt Y? Kanonische Links	references/docs-map.md, references/resources.md

Grundregeln (Verstöße dagegen führen zu falschen Plone-Ratschlägen)

1. Versionsabhängige Fakten niemals raten. Überprüfen Sie die Versionstabelle oben, die Referenzdatei oder das Korpus. Plone-4/5-Antworten (Archetypes, portal_skins, Grok, plone.app.theming TTW Hacks, Python 2) schaden Plone-6-Benutzern aktiv.
2. Greifen Sie zuerst zu plone.api im Backend-Code; steigen Sie auf CMF/Zope-APIs nur um, wenn es die Fähigkeit nicht bietet.
3. Alle persistenten Konfigurationen gehören in GenericSetup-Profile + Upgrade-Schritte (oder eine plone.distribution), niemals Ad-hoc-durch-das-Web-Änderungen in der Produktion.
4. Respektieren Sie die Transaktionsdisziplin: Skripte müssen transaction.commit(); niemals bei GET schreiben; erwarten und behandeln Sie ConflictError unter Parallelität.
5. Erfinden Sie nicht das Rad neu, was ein etabliertes Add-on bereits tut – überprüfen Sie zuerst die Add-ons-Referenz und die collective-Organisation.
6. Volto-Anpassungen gehören in ein Add-on (Shadowing/Konfiguration), niemals durch Bearbeiten von node_modules oder Forken des Volto-Kerns.
7. Migrationen: export/import gegenüber In-Place bevorzugen für alles, was älter als 5.2 oder stark angepasst ist; niemals ohne Probelauf auf einer Kopie migrieren.
8. Zitieren Sie die Dokumentation: Weisen Sie Benutzer bei der Beratung auf die genaue Seite hin (URL-Muster in references/resources.md), damit sie nachprüfen können.
9. Bevorzugen Sie die dauerhafte Antwort: Empfehlen Sie das Architekturmuster (Erweiterungspunkt, Profil, Add-on) gegenüber genauen API-Beschwörungen, wenn beide funktionieren würden – Muster überleben Upgrades; Beschwörungen verrotten. best-practices.md ist das Playbook.

Optionales lokales Korpus (tiefe Verankerung)

Wenn das vollständige Quellkorpus verfügbar ist (Env PLONE_SKILL_CORPUS oder das sources/-Verzeichnis eines plone-skill-Build-Repo-Checkouts), können Sie die gesamte offizielle Dokumentation, Schulungen und den Quellcode jedes Kernpakets durchsuchen:

scripts/search.sh "IBlockFieldSerializationTransformer"      # gesamtes Korpus
scripts/search.sh -d volto "addonsLoaders"                    # ein Repo
scripts/search.sh -d documentation "upgrade step"             # nur Plone 6 Dokumentation

Verwenden Sie es, um jede Tatsache zu überprüfen, die diese Fertigkeit nicht abdeckt, genauen Code zu zitieren oder aktuelle Versionen zu prüfen (sources/web/misc/ enthält Release/EOL-Daten). Ohne das Korpus verwenden Sie die Live-URLs in references/resources.md.