Volto Team meeting minutes 2025-02-11

stevepiercy · February 15, 2025, 12:26pm

Volto Team meeting minutes 2025-02-11

Attendees

Steve Piercy
Alok Kumar
Piero
Victor
Dylan
Tisha
Jakob

Housekeeping

Designate Note Taker - @stevepiercy
Designate Time Keeper - @stevepiercy
Review agenda topics, presenters, and timings - @timekeeper
Topics should not exceed 15 minutes of discussion time, as that probably means it is too complex to resolve during this meeting. Ad hoc meetings or sprints may be a better venue.

Agenda/Notes

Old Business

These items are updates from previous meetings. Usually they are information only, and don’t require further discussion. Occasionally they may require further discussion and clarification.

Become a Volto Team member - Timo, Steve
PLIP process - General - Plone Improvement Proposals (PLIPs) — Plone Documentation v6
PLIP process - UI/UX - PLIP Process for User Interfacing Changing PLIPs · Issue #6628 · plone/volto · GitHub
PLIP process private Discord channel created. Ask @stevepiercy for access, if interested.
PRs
- Stop generating sitemap.xml.gz - Mikel - Review
  - Stop generating sitemap.xml.gz (#6561) by reebalazs · Pull Request #6562 · plone/volto · GitHub
  - Refs: Do not deliver the old sitemap.xml.gz · Issue #6561 · plone/volto · GitHub
  - [Mikel] I proposed in the PR comment to serve the index file in the sitemap.xml.gz file, as it is by itself a sitemap file. We have done some tests with this implementation and Search Console reports that the index file is valid, so the solution of presenting the sitemap index in the previous sitemap.xml.gz (and yes, it is a gzipped file), is correct.
  - [Mikel] I added a PR to Classic to have this implementation also there, for reference: generate a sitemap-index and split the contents in several sitemap.xml.gz files by erral · Pull Request #382 · plone/plone.app.layout · GitHub

New Business

Seven PLIPs: Plone 7 frontend (Seven) · Issue #6638 · plone/volto · GitHub
- Effort split between Volto 19 and Plone 7. Seven will be a complete rewrite. Volto will continue development in parallel. However we need to better describe how we will make progress on both Volto and Seven simultaneously.
- We need to better explain why Seven will be a complete rewrite, as it raises a lot of concerns. For example a Volto 19 Roadmap will reduce those concerns.
- Started planning in the PLIP. Created dozens of PLIP tasks as sub-issues of the PLIP. Included admonitions in each sub-issue to deter first-timers. The CMS UI is the largest set of features.
- Victor expects to attend the Bucharest Sprint, do more planning and prioritization, and maybe start development.
- Victor https://seven.sneridagh.dev/ is running both Seven and Volto 18 on his site.
Upcoming Sprints: Bucharest Plone Sprint 2025
- We should designate which tasks out of the Seven PLIP should be worked on at this sprint.
- We need to prioritize before the sprint.
  - Victor
  - Piero
  - Steve
  - Your name here
Vitest PR: Feature/jest to vitest migration by Abhishek-17h · Pull Request #6605 · plone/volto · GitHub
- We decided to:
  - maintain Jest config in Volto 18, so people can continue to run Jest for their add-ons and projects
  - migrate our Jest tests to Vitest in core in Volto 18
  - Don't upgrade Cookieplone before Volto 19
  - Document how to migrate your add-on tests from Jest to Vitest
PLIP #5629: Enhance timezone support in UI for plone.app.event based types
- PLIP: PLIP #5629: Enhance timezone support in UI for `plone.app.event` based types · Issue #5629 · plone/volto · GitHub
- Project Board: PLIP - plone.app.event based types · GitHub
- Which tasks are blocking progress on Volto tasks? Let's identify and prioritize them.
Good of the order
- PLIP: Plone 7 Documentation Layout, Structure, Theme, and Search to Improve Usability · Issue #4097
- Seven (VoltoTNG) docs will be written in the Documentation repository.
- Investigate the possibility of forms in Pull Request templates and automating that necessary checks are satisfied to ensure that PRs in Volto are linked to their PRs in Documentation.
  - Multiple pull request templates: Creating a pull request template for your repository - GitHub Docs
  - Forms are not available in pull requests, only issues: Syntax for issue forms - GitHub Docs. "Issue forms are not supported for pull requests."

mtoepfl · February 16, 2025, 10:39am

Are there parts of Volto which should be ported to Typenscript before they are "copied" over to Seven?

stevepiercy · February 16, 2025, 11:31am

Yes. See the individual sub-issues of the main PLIP.

mtoepfl · February 16, 2025, 6:08pm

Thank you very much! Is it currently desired to work on this?

stevepiercy · February 16, 2025, 10:20pm

I don't know. I know that the PLIP is still in the planning stage, but there may be some PLIP tasks that can be started. I assume that the TypeScript migrations are such tasks, since they are discrete units of work that have no depencies on other tasks. Let's ask @sneridagh.

sneridagh · February 17, 2025, 7:53am

@mtoepfl yes, the idea is that Seven is TS only. The parts that we have to port, will need to be refactored into TS.

I will add a proper guidelines and style guide to the PLIP.

sneridagh · February 17, 2025, 7:54am

@mtoepfl The work on Seven will start in the Bucharest Sprint. However, there's been a bit of work done, all the baseline is in place already.

mtoepfl · February 17, 2025, 5:13pm

@sneridagh We have some free resources at the moment. Should we start porting helpers at the Volto side? So both sides can benefit...

sneridagh · February 18, 2025, 3:08pm

@mtoepfl By all means, any help is welcomed.

It has to be done in a sensible way though, could be that we don't want all of them on the Seven side. But I'd say that yes, we would want the vast majority of them.

Take a look at all the sub-issues and tasks in:

github.com/plone/volto

Plone 7 frontend (Seven)

opened 11:20AM - 02 Feb 25 UTC

sneridagh

03 type: feature (plip) 43 lvl: complex

## PLIP (Plone Improvement Proposal) ## Responsible Persons ### Proposer: Víct…or Fernández de Alba (@sneridagh) ### Seconder: Timo Stollenwerk (@tisto) ## Abstract Modernize Volto using the current standards and frameworks. ## Motivation Plone Volto frontend is (as per 2025) eight years old. We architectured and implemented Volto using the libraries, frameworks, resouces and best practices that were available back in the day. These have all changed, in the midst of the ever-changing and ever-evolving React ecosystem, therefore, the way of developing React applications nowadays have dramatically changed. React 19 is stable now, settling (at last) a common paradigm for efficient data fetching in both the server and the client. Nowadays React frameworks leverage and are embracing this paradigm, battle testing them in production. Plone has to embrace also these best practices an patterns, replacing all the legacy libraries and old patterns with the current ones. We decided to use React Router 7 as framework of choice for the implementation of the Volto successor. See the rationale behind in the corresponding PLIP: https://github.com/plone/volto/issues/6324. We have settled on the strategy explained in this PLIP, after working on the PoCs that we've investigated during the last months. I explained it thoroughly in https://github.com/plone/volto/issues/6320. The summary is that if we were to implement the list of approved improvements, we would end up by rewritting the vast majority of what we know today as Volto, and the final outcome would be still a complete different beast. Volto is the sum of small pieces that put together make our beloved frontend in which we grew all these years. These fundamental and structural pieces are the ones that we sliced and made them work standalone in the last year. The idea is to grab this pieces that define Volto itself, and put them together in a new, modern and capable frontend. Taking `@plone/registry` as base, and using exactly the same add-on driven development approach and by using the same concepts, patterns and data structures, we plan to achieve the maximum compatibility with existing Volto sites, carefully designing the migration path from Plone 6 to Plone 7. We think that crafting add-ons able to work in both Plone 6 and Plone 7 would be possible, even today with the existing PoCs. These are the points of improvement for PLIPs for Plone 7: - Move to a modern bundler (Vite) (React Router 7 already is Vite-powered) - Use React Router 7 as framework - https://github.com/plone/volto/issues/6324 - The CMSUI as a pluggable standalone app - https://github.com/plone/volto/issues/6325 - Refactor the base components (both public UI and CMSUI) removing Semantic UI and using `@plone/components` - https://github.com/plone/volto/issues/4352 - A new theming system (without Semantic UI) - https://github.com/plone/volto/issues/6322 - A new unified block model for both public UI and CMSUI - https://github.com/plone/volto/issues/6316 - Enhanced contents view - https://github.com/plone/volto/issues/4756 - Use the new JS client package - https://github.com/plone/volto/issues/4347 - Implement Quanta in the CMSUI - https://github.com/plone/volto/issues/4332 ## Assumptions We have all the basic pieces identified that we will need on the table so we can start building up. These pieces are commanded and orchestrated by `@plone/registry` and are composed by the API-first `@plone/*` packages. Some of these pieces will require to be improved and evolved, but basically, all "rocket science" level issues are sorted out. ## Proposal & Implementation We will continue developing and maintaining Volto as we know it today. Volto 19 is scheduled and its roadmap is clear and will happen in the upcoming months. We will develop the successor of Volto (codenamed `Seven`, the final name to be decided in the future) along side Volto (in `main` branch) as it happens during the next months. Since Volto only relies in `@plone/registry` it should be easy to keep compatibility so it can be used by Volto and Seven. The rest of the Plone frontend modular packages (`@plone/*`) will continue evolving and used by Seven. It would be easier if none of them became part of Volto core for the time being. We compiled the Seven Mantras of Seven: - "Use the standards, the framework and the ecosystem in your favor as opposed to fight them" - "If it ain't documented, it's broken." - "Document as you didn't have 20 years of Plone experience" - "Prioritize practical client feature requests" - "Provide a clear upgrade path forward from Plone 6 to Seven" - "Deprecated and unmaintained mean exactly what it's supposed to mean" - Mantra 7 TBD ## Deliverables The Seven package is already in place in `packages/seven`. It is a React Router 7 app and will be the base of the Public UI, completelly detached from the CMSUI part. We will create another app for the CMSUI in `packages/cmsui`. It will be the base of the CMSUI side based in the same principles as Seven public UI counterpart. You would be able to use the same add-ons as in the public UI, so both can share the features, theming and customizations. As they will be separated builds, the public part will be quite thin and lightweight, with the ability to be deployed wherever a React Router 7 can be deployed (Clouflare, Edge providers like AWS lambdas, Vercel, Netlify, etc). The CMSUI could be traditionally deployed alongside the public UI or in a separated server or even encapsulated in a desktop app or in a native mobile app for convenience. Both of them will be pluggable with add-ons, as in they are meant not to have any code in it, but the boilerplate that will pull other pieces together. These apps would be the ones that the projects will run and inject their own project add-ons to customize them. The basics and some acceptance tests are already in place for Seven. Complete developer documentation. More deliverables are described in the related PLIPs or sub-issues of this PLIP. ## Risks Documentation first is a *must*. It is mandatory that we shape the documentation and validate this documentation with people external to the project. Coordinate such an effort will be hard, we have to plan it carefully and split the tasks in different parts. There are still things to be decided in several key places, and some others that need to be investigated, PoC'd and test drive them. ## Participants Víctor Fernández de Alba (@sneridagh) Piero Nicolli (@pnicolli) Steve Piercy (@stevepiercy) Volto Team (@plone/volto-team) > [!IMPORTANT] > > This PLIP is for Plone's core developers and the subsequent issues are part of the organization of this project. > It is not intended for newbies or first time contributors.

We will continue working on them before the Bucharest Sprint starts.

jensens · February 18, 2025, 5:30pm

Well, it helps if the document is at least readable for anonymous visitors.

jensens · February 18, 2025, 5:33pm

Who had the glorious idea for Codename Seven?
At least name it Plone Seven - if you like to write more letters it doesn't matters.

tkimnguyen · February 18, 2025, 9:17pm

Hey at least no one wrote it here as Se7en… until now

stevepiercy · February 18, 2025, 11:21pm

It's for internal use only in its draft state.

stevepiercy · February 18, 2025, 11:53pm

Naming things is hard, and we don't have the marketing expertise of Apple to create codenames. You should have seen some of the other suggestions, including references to DEVO, Star Trek, and a few expletives for some bleeping codename.