Say hello to Blicca: Plone Classic UI has a new name

[petschki (Peter Mathis)]

For years, the server-rendered frontend of Plone has gone by a working title: Classic UI. As of today, it has a real name — Blicca.

This is more than a label change. It reflects a decision the team has made about the future of the project: the classic, server-rendered frontend is here to stay, and it deserves a name that says so.

Why rename it now?

"Classic UI" was always kind of an internal project name for the successor of the Barceloneta theme — the established, server-rendered interface, set apart from the new React-based frontend, Volto. The theme name stuck around through Plone 6, and it will carry into Plone 7 — but with significant renewal and investment along the way.

This frontend is very much a living part of Plone: actively developed, first-class, and with a long road ahead. A name like "Classic UI" undersells that — it can sound like the old way of doing things, when in fact it is one of two modern, supported paths forward.

So we gave it a proper name — one that can grow with the project rather than dating it.

Why "Blicca"?

The name comes from the water, by tradition. Plone's underlying application server, Zope, shares its name with a freshwater fish — the zope (Ballerus ballerus), a member of the carp and minnow family. When it came time to name the frontend, we wanted to stay in that family.

Blicca is Blicca bjoerkna, the silver bream — a real fish, and a genuine member of Leuciscidae, the very family Zope's namesake belongs to. It earned its place by quietly doing everything we hoped a name might do:

• View — in German, Blick means a look, a glance, a view: exactly what a user-facing frontend is.
• Shiny — the silver bream is iridescent, a nice nod to a polished interface and to theming.
• Family — it belongs to Zope's own fish family, keeping the lineage intact.
• Clean — the name was free across PyPI, npm, GitHub, and trademark registers, so there were no collisions to inherit.

What's changing

The rename is already rolling out across the project. The team formerly known as the Classic UI Team is now the Blicca Team, and the community channels — including Discord (blicca channel) and GitHub (@plone/blicca-team) — have moved to the new name. Documentation and references will be updated continuously to use Blicca as part of the future development.

The frontend you know continues exactly as before, with the same goals and the same momentum toward Plone 7 — and there is plenty ahead. A major focus is theme separation, pulling the theme layer and rendering templates fully apart from the backend so that Plone can serve as a completely headless backend — and it will include the new theme. Alongside that, frontend editing is getting real attention, including a rewritten folder contents management and continuous effort to reuse editing UI components across the frontend stacks.

Cheers, the Blicca Team

[mtrebron (Norbert)]

Great initiative! I would love to see this approach be reflected in the way a user is guided through their first addition of a Plone site. Meaning both Volto and Blicca should receive equal mindspace, unlike now.

[davisagli (David Glick)]

Congrats on the new name!

the server-rendered frontend of Plone

I find this is a misleading way to communicate the difference between the two frontends. Volto also does server-side rendering of HTML. And Blicca also renders some things in the browser after fetching data via async requests.

I would love to see this approach be reflected in the way a user is guided through their first addition of a Plone site. Meaning both Volto and Blicca should receive equal mindspace, unlike now.

@mtrebron We’ve tried to cover both frontends in a balanced way in the docs.

• There are demos for both frontends: Get started — Plone Documentation v6
• Get started — Plone Documentation v6 starts by pointing the user to a guide to help the user pick between the two frontends.
• Install Plone with Cookieplone — Plone Documentation v6 also points to the same guide, and includes instructions for both frontends.
• The view for adding a Plone site lets you choose between the two distributions: Add a Plone site — Plone Documentation v6

Were you looking somewhere else?

[tco]

@petschki

A major focus is theme separation, pulling the theme layer and rendering templates fully apart from the backend so that Plone can serve as a completely headless backend

This is really a great idea!
I wonder how acquisition of templates will be handled. AFAIK Plone REST API handles acquisition of content. But how to handle acquisition of templates if the templates are not in the backend? Must then acquisition be implemented in the frontend?
Maybe I do not understand it right.

[petschki (Peter Mathis)]

The main goal is to move every page template out of the core so that HTML rendering completely happens in a separated "layout package". This package then can be installed or not, depending on your projects need. For example in Volto projects you would not need the classic-template stack. So you install only "Plone headless". Which dependencies are installed is usually handled by the distributions plone.volto and plone.classicui (and in the future plone.blicca)

You can follow (and participate in) the progress here:

PLIP: Start separating Classic UI code from the core

[yurj (Yuri)]

Great news!

Looking at today "frontend" servers, they ended up to be full backend servers, sharing the same issues and heaviness. So this is the right time to push the python Plone code. I would go for python 3.14 noGIL version too.

[Esoth (Eric Wohnlich)]

Exciting stuff! I really like Volto and React, but aside from just the technical use of React it also leans in to a particular kind of editor experience via the use of blocks. I talked about this with @acsr a bit - Volto in my opinion favors design-oriented editors that want to create something that pops, to sell a product or an idea to an external group of people. Nothing wrong with that - most of the internet is probably that way. I want to move as many projects to Volto as I can, and use it on new projects. But it doesn't fit all of my projects as appropriately as Classic UI does.

I have a lot of projects that use Plone as an extranet with non design-oriented editors that just want to make clean content to share with colleagues, research collaborators, etc. Plone is a great choice for them - user/role/permission security is huge here, Dexterity allows us devs to facilitate what they want to share, etc. Traditional Plone stuff. But Volto is a bit of a hard sell for editor experience - they just don't need anything more complicated than rich text paragraphs with images and links to files most of the time. They don't need blocks.

So with that in mind, I am really excited to see Classic UI/Blicca continuing to receive support and am curious what kind of use cases other people envision for each project. I have positive experience with @petschki in both guidance and bug support, so this all sounds great! The "Why rename it now" section is spot on and alleviates my fears with the future of Classic UI/Blicca.

This may be off topic, but the biggest developer headache for me with Classic UI has been customization of content that ships already webpacked. Like the folder contents section. Doing that in React, where I just have to customize a component, is much easier. I could even see a case where Plone has two React (or similar) frontends with different editor UX philosophies, but similar dev and user philosophies.

[yurj (Yuri)]

Yes, the need of repackaging staticresources just to make a customisation is an issue. Maybe the new way to import modules will fix it?

[MrTango (Maik Derstappen)]

For things like the contentbrowser and soon also for the new folder_contents (pat-filemanager) we will allow overriding some of the templates from outside. It is already possible for contentbrowser, but we could add more of the pieces. We need to register those smaller components via @plone/registry so that they will be picked up from there. Then a developer can come with an addon and re-register it, hence override it with there own version. Which parts of the user interfaces we need to be overrideable, we can discuss.

For the blocks, i have made an interesting experiment during the Buschenschank Sprint, where i was implementing rendering of Volto blocks in Blicca. So for now you would put a Volto next to you Plone with Blicca UI and edit you content with blocks in Volto as a CMS UI. The Blicca UI will render all core and VLT blocks by it self. In the future it might even possible to integrate the editor part in Blicca directly. So that you don’t need a separate node server running with Volto. But for that, we might wait a bit for the upcoming Plate Editor work in Aurora (seven) to settle.

So far it is only an experiment, but even as it is, it opens new possibilities for existing Blicca projects which want something like blocks. So they don't need to use other technologies like Mosaic, they can just use the same blocks as Volto, which can bring the two worlds closer together.

[tkimnguyen]

@MrTango

i have made an interesting experiment during the Buschenschank Sprint, where i was implementing rendering of Volto blocks in Blicca. So for now you would put a Volto next to you Plone with Blicca UI and edit you content with blocks in Volto as a CMS UI.