plone
Add form block to Volto Core
[!IMPORTANT] If you are not a member of the Volto Team or Developers Team in the Plone GitHub organization, then do not work on or comment on this issue.
PLIP (Plone Improvement Proposal)
Responsible Persons
Proposer: @robgietema
Seconder: @sneridagh @davisagli
Abstract
The volto-form-block is currently an addon which is used to create forms by an editor. Since this block uses custom widgets and is lacking some customization functionality the block has been rewritten to use the default volto form components. For the customizabitily, functionality has been added to the volto form compoment which has already been merged. This PLIP proposes the 4.x.x branch of the volto-form-block to be merged into the volto repository. The package will still be a separate package (similar to for example the slate package).
Motivation
When this package is included in the volto core it will be easier to keep track of releases. This will also add form functionality to the core of Plone and not be an addon so editors will have this functionality by default.
Assumptions
We want editors to be able to add forms to a website and want this functionality to be in the volto core.
Proposal & Implementation
The functionality has already been implemented in the 4.x.x branch of volto-form-block and is used in production on a large website for several months.
Deliverables
The package will be moved from the volto-form-block to the volto repository and included in the build. End user and developer documentation will be added to the plone documentation.
Risks
The package will be available by default but the block will not be enabled by default. The risk is therefor minimal. The block also does not collide with the current volto-form-block, so in theory both can be enabled for the site.
Participants
@robgietema
+1 from me! Forms are an essential feature for a CMS like Plone. In the past, there was often confusion in the community, which added to the use and how well supported it is (PFG vs EasyForm). Shipping Plone with a core form add-on is the way to go!
The volto-form-block requires backend support for full functionality (https://github.com/collective/collective.volto.formsupport)
It would make sense to move collective.volto.formsupport also into core and also discuss possible issues with that in this PLIP, as they are interdependent.
We could add the functionality in collective.volto.formsupport, but then you cannot disable it by uninstalling the add'on. Or maybe we should rename the packate to plone.volto.formsuport instead, the plone namespace being an indication it is a core packages. (and we could do similar for future plone.volto.* core packages that do warrant their own sub namespace. It does smell a bit like plone.app.* overengineering on the other hand as a counter argument.
+1 for me. I'd take the same policy as we did when we incorporated volto-slate to the core, and make it "core add-on".
We move it in there "as is" but changing the namespace to @plone/volto-form-block, like we did with @plone/volto-slate.
The internals will keep being the same, nothing changes.
There is a procedure to make the package "core add-on" config, but it's a one liner in Volto's package.json.
@fredvd indeed. We need to study and investigate how to proceed with the backend part.
OK, let's un-stall this. I will create a repository in the plone org with the current code, keeping history. I will change the names to @plone/volto-form-block and at least issue an 1.0.0-alpha of it. Then, we can start using it with the current backend add-on collective.volto-form-support, waiting for the integration in core.
Once all are ready, we move the frontend add-on also to the Volto monorepo.
/cc @mauritsvanrees
Can someone help me with https://github.com/collective/collective.volto.formsupport/issues/91 and https://github.com/plone/plone.formwidget.hcaptcha/issues/16? Without the unreleased modifications, it's not possible to use Hcaptcha in volto-form-block. If someone gives me permission on PyPI, I can release them myself.
@wesleybl I think I made releases for the package in the past, so I can help out. My concern here is semver and native namespaces. I think your changes warrant a major release. But we also need to update our addon packages to native namespace support to avoid future installation issues.
How should we proceed here. create a 1.x branch, merge these changes to main and release it as 2.x. And then do another 3.x where we add native namespace support and release it not too soon thereafter?
Then we minimise risk of breakage, upholding this PR for too long: people can use 2.x now and switch to 3.x later.
@sneridagh @mauritsvanrees @ericof @gforcada : ^^. Some general guidance on how we advice add'ons to upgrade to native namespaces the next months would be welcome, opinions on the above?
In hindsight, a bit off to add the comment on the plone/volto repo for a backend packaging issue, sorry. I've added a link from https://github.com/plone/plone.formwidget.hcaptcha/issues/16. :-$
In hindsight, a bit off to add the comment on the plone/volto repo for a backend packaging issue, sorry.
@fredvd Sorry, I thought it would be relevant, since you're considering adding volto-form-block to the core.
No, I didn't mean your question, I added that only about my own comment with the native namespace issues mentionned. That's backend :-).
@fredvd for the documentation on how to update a package to native namespaces, see: https://6.docs.plone.org/developer-guide/native-namespace.html
For general advice, with newer buildout 5 and horse-with-no-namespace transition should be not too painful.
