Cookieplone, two years in: lessons learned and the road to 2.0

Two years of Cookieplone taught us a lot. Here is what worked, what did not, and what is coming in Cookieplone 2.0.

If you have been around the Plone community for long enough, you know that code generation tools come and go. Every few years a new one appears, solves the problem of the moment, serves the community well for a while, and then slowly fades as maintenance dries up and requirements change. ArchgenXML, Paster, ZopeSkel, mr.bob, plonecli — each of them has a place in our collective muscle memory.

Cookieplone is the current chapter of that story, and it just turned two years old. With the release of the first 2.0 alpha today, it feels like a good time to stop, look back at how we got here, and talk about what comes next.

The itch that started it all

A few years ago, probably during one of the Beethoven Sprints, a small group of us was once again arguing about code generators. The Plone and Zope community has always been good at building ambitious tooling, but the cost of keeping those tools alive is high, and the pool of maintainers is never as deep as we would like. We wanted something different this time: templates that were easy to maintain, quick to update, and backed by a user base big enough to actually absorb the cost of keeping them healthy.

Around the same time, Jens Klein put together a cookiecutter template to generate Zope instance configuration. I had been using cookiecutter for years, both on Pyramid and Ruby on Rails projects, and I was already sold on the idea. The choice felt obvious: cookiecutter would be our path forward.

cookiecutter, and the price of success

cookiecutter worked. It worked so well that, before we realised it, we had templates everywhere:

• collective/cookiecutter-plone-starter
• collective/cookiecutter-plone-distribution
• plone/cookiecutter-volto
• plone/cookiecutter-plone
• plone/cookiecutter-zope-instance

Every repository had its own structure, its own pinned versions, its own filters, its own validators, its own tests. A fix in one place almost never made it to the others. Worse, a modern Plone project is rarely "just a backend" or "just a frontend" — it is backend and frontend and deployment and CI and a distribution on top. We needed templates that could call other templates, share code, and be tested together.

Axolote Sprint, 2024: enter Cookieplone

At the Axolote Sprint in 2024, I sat down with my friend David Glick and we finally put words to what we wanted. Unifying the template repositories was the easy part — cookiecutter already allowed that. The harder part was reducing the duplication of filters, hooks, fixtures and subtemplate logic that had been piling up across repositories.

Our answer was to build a thin wrapper around cookiecutter that would:

• Centralise filters, validators and pytest fixtures in a single package.
• Make it practical to have templates call other templates (subtemplates).
• Give template authors a single CLI to worry about.

That wrapper became cookieplone, and the companion repository cookieplone-templates became the home for the official Plone templates. For the last two years, uvx cookieplone has been the canonical way to bootstrap a Plone project.

Two years of lessons

Two years is enough time to be honest with yourself. Cookieplone did solve real problems, but it also exposed new ones.

Duplication did not fully go away. Having the templates in a single repository helped enormously, but we still carry duplicated information across templates — component versions being the most painful example. Every Plone release turned into a tour of cookiecutter.json files.

Subtemplates are still complicated. The mechanism works, but writing a template that composes other templates is harder than it should be, and debugging it is not fun.

The user experience is brittle. If you make a typo halfway through a long list of prompts, the generation fails and you start over. There is little validation as you go, no way to jump back to a previous answer, no preview of what you are about to generate. For a tool that is supposed to be the front door to Plone, that is not good enough.

Companies need to customise. This was the biggest surprise. The demand for "official templates, with my own flavour" is enormous. Eau de Web does not use GitHub Actions; they run Jenkins. At kitconcept we use GitHub Actions, but our CI/CD setup has enough particularities that maintaining a fork is tempting. Every serious Plone shop has its own opinions about deployment, linting, release process, security scanning. A rigid template cannot serve all of them.

Cookieplone 2.0

The real push to turn all of these lessons into a 2.0 happened at the Bucharest Sprint 2026, hosted by our friends at Eau de Web. Most of the important discussions — on the new configuration format, the UX overhaul, subtemplates and the extension mechanism — happened in that room, with Alin Voinea, Valentina Bălan, Victor Fernández de Alba and Fred van Dijk. A huge thank you to all of them, and to Eau de Web for hosting us.

All of this feeds directly into Cookieplone 2.0, whose first alpha landed yesterday. The goal is simple to state and hard to deliver: improve the user experience, improve the template author experience, and make extension a first-class concern.

A better experience for end users

The most visible change is the interactive layer. Cookieplone 2.0 is built on top of tui-forms, a small library that turns JSONSchema definitions into rich terminal wizards. In practice, this means:

• Grouped templates: when cookieplone-config.json defines categories, the CLI presents templates hierarchically instead of as a flat list.
• Input validation as you type, with dedicated validators for things like plone_version, volto_version and python_package_name.
• Navigation: you can go back to a previous question without restarting the whole process.
• Summary and confirmation before anything is written to disk.
• Answers files: every generated project drops a .cookieplone.json with the answers you gave, and you can replay them with --answers — perfect for scripted setups and reproducible demos.
• A new cutter2plone command to help migrate legacy cookiecutter.json files to the new format.

A better experience for template authors

Behind the scenes, the changes are just as significant:

• New file formats based on JSONSchema, with proper validation.
• Better handling of subtemplates, including global variables accessible across templates.
• New pytest fixtures for testing templates end to end.
• The foundations for an extension mechanism, so organisations can publish their own template packs on top of the official ones instead of forking.

What comes next

The alpha is just the starting line. Over the next months, the plan is:

• Refactor the existing templates in cookieplone-templates to take full advantage of the new format.
• Land the extension mechanism, so kitconcept, Eau de Web and anyone else can ship their own flavour of the official templates.
• Write the documentation this tool deserves. (We have a start, but there is a long road before we earn the Steve Piercy Seal of Approval.)

The goal I am holding myself to is to have all of this in place by the next Beethoven Sprint. If you want to help, whether by testing the alpha, porting a template, or just telling me what breaks on your machine, the tracker is open and I would love to hear from you.

Two years ago, Cookieplone was a small thin wrapper we hacked together during Axolote Sprint. Today it is the front door to Plone for a lot of people. Cookieplone 2.0 is our chance to make that front door one we are genuinely proud of.