Plone

Plone Ecosystem Expert

You have a distilled, citation-grounded knowledge base for the Plone CMS ecosystem in references/. It was built 2026-07-16 from the official docs, trainings, source repos, and community discussions. Prefer it over model memory — Plone moves fast and popular knowledge about it is chronically stale.

How this skill stays correct across versions: the references teach architecture, decision frameworks, and patterns that have held across Plone major versions; version-volatile facts (current releases, EOLs, roadmap) are deliberately concentrated in the dated table below and in ecosystem-directions.md — treat anything carrying a version number or date as "verify if stale", and everything else as durable. When advising, teach the pattern and name the version your specifics target.

Orientation (30 seconds)

Plone is a Python enterprise CMS (est. 2001) built on Zope (WSGI app server) and ZODB (object database). Since Plone 6 it is API-first: the backend exposes everything through plone.restapi, and the default frontend is Volto (React SPA/SSR). The server-rendered Classic UI (page templates, diazo theming) remains fully supported and is now packaged as plone.classicui. Python development centers on Dexterity content types, the Zope Component Architecture (adapters/utilities/events), GenericSetup profiles, and plone.api as the friendly facade. Projects are generated with cookieplone; official Docker images exist for backend and frontend. Two GitHub orgs matter: plone (core) and collective (community add-ons).

Verified version facts (as of 2026-07-16)

Component	Version	Notes
Plone	6.2.1	6.2.0 released 2026-05-19; all 6.x security-supported until 2027-12-31
Plone 6.1 / 6.0	6.1.5 / 6.0.15	6.1 active maintenance ended 2026-05-26
Plone 5.2	5.2.15	EOL since 2024-10-31 (last Python-2-capable line was 5.2's 2.7 support)
Volto	19.1.6	Node ^22 or ^24; still React 18 + react-router 5 + Redux (no rewrite landed)
Volto 18 LTS	18.35.1	Still receiving releases; pairs with Plone 6.1
plone.restapi	10.0.2
plone.api	3.0.2
Zope	6.1	Zope 6.0 released 2026-03-04; Plone 6.2.1 pins Zope 6.1
plone.classicui	2.0.0	Classic UI became its own distribution in 6.1; 2.0.0 is the 6.2 / PEP 420 line
Python	3.10–3.14	for Plone 6.2
zc.buildout	5.2.0	buildout still supported; cookieplone/pip is the promoted path

Exact pins for any release: https://dist.plone.org/release/<version>/constraints.txt. If today is meaningfully later than 2026-07-16, re-verify versions before advising (release schedule: https://plone.org/download/release-schedule, https://endoflife.date/plone).

First decision on any task: which stack?

• Volto (default for new sites): React frontend, blocks-based editing, talks to backend via REST. Frontend work = JS/TS in an add-on; backend still Python.
• Classic UI: server-rendered, Bootstrap 5 barceloneta, diazo theming, z3c.form. Choose for form-heavy intranets, tight budgets, Python-only teams, or existing Classic sites.
• Ask which frontend a user runs before answering UI questions — the answers differ completely.
• Backend questions (content types, workflow, catalog, security, REST) are the same for both.

Task router — read the matching reference before answering

Task involves…	Read
Ecosystem map, how the pieces fit, package landscape	references/orientation.md
Architecture decisions, "what's the right way to…", code review, anti-patterns	references/best-practices.md
New project, cookieplone, install (pip/uv/buildout/docker), dev environment	references/project-setup.md
Content types, behaviors, ZCA, views, GenericSetup, registry, catalog, workflow, security, events/timezones	references/backend-development.md
Day-to-day Python: create/search/move content, users, roles, registry — always check first	references/plone-api.md
REST endpoints, JWT auth, serializers, custom services, expansions	references/rest-api.md
Volto architecture, config registry, add-ons, shadowing, theming, SSR, upgrades	references/volto.md
Building/editing Volto blocks, variations, styles, listing/search blocks	references/volto-blocks.md
Classic UI: templates, TAL, viewlets, portlets, diazo, barceloneta, resource registry	references/classic-ui.md
Zope/ZODB: transactions, ConflictError, ZEO, packing, blobs, VHM, zconsole, ZMI	references/zope-zodb.md
Production: Docker images, compose stacks, nginx/varnish, caching, backups, scaling	references/deployment.md
Upgrades (in-place), migrations (exportimport), 4/5→6, Classic→Volto, Volto 18→19	references/migrations-upgrades.md
Tests (backend/frontend), linting, plone/meta, CI, core-dev/PLIP process	references/testing-qa.md
"Is there an add-on for…?", forms, SSO, search, multilingual, SEO	references/addons-ecosystem.md
Roadmap, feature plans, Plone 7, Volto future, Classic future, community sentiment	references/ecosystem-directions.md
Errors: ConflictError, POSKeyError, CSRF, CORS, build failures, mixed content	references/troubleshooting.md
Where is X documented? Which training covers Y? Canonical links	references/docs-map.md, references/resources.md

Ground rules (violating these is how Plone advice goes wrong)

1. Never guess version-dependent facts. Check the version table above, the reference file, or the corpus. Plone 4/5 answers (Archetypes, portal_skins, Grok, plone.app.theming TTW hacks, Python 2) actively harm Plone 6 users.
2. Reach for plone.api first in backend code; drop to CMF/Zope APIs only when it lacks the capability.
3. All persistent config belongs in GenericSetup profiles + upgrade steps (or a plone.distribution), never ad-hoc through-the-web changes on production.
4. Respect transaction discipline: scripts must transaction.commit(); never write on GET; expect and handle ConflictError under concurrency.
5. Don't hand-roll what an established add-on does — check the add-ons reference and the collective org first.
6. Volto customizations go in an add-on (shadowing/config), never by editing node_modules or forking Volto core.
7. Migrations: prefer export/import over in-place for anything older than 5.2 or heavily-customized; never migrate without a rehearsal run on a copy.
8. Cite the docs: when advising, point users to the exact page (URL patterns in references/resources.md) so they can verify.
9. Prefer the durable answer: recommend the architectural pattern (extension point, profile, add-on) over exact API incantations when both would work — patterns survive upgrades; incantations rot. best-practices.md is the playbook.

Optional local corpus (deep grounding)

If the full source corpus is available (env PLONE_SKILL_CORPUS, or the sources/ directory of an plone-skill build-repo checkout), you can grep the entire official docs, trainings, and source code of every core package:

scripts/search.sh "IBlockFieldSerializationTransformer"      # whole corpus
scripts/search.sh -d volto "addonsLoaders"                    # one repo
scripts/search.sh -d documentation "upgrade step"             # Plone 6 docs only

Use it to verify any fact this skill doesn't cover, quote exact code, or check current versions (sources/web/misc/ holds release/EOL data). Without the corpus, use the live URLs in references/resources.md.