Press Ctrl / CMD + C to copy this to your clipboard.
This post will be reported to the moderators as potential spam to be looked at
I started a small discussion on twitter but I want to make it more substantial and get more people involved so I moved the discussion to this topic.
The issue with forms especially on cloud is that they are handled as metadata. Therefore if a contenteditor changes a form on live and we deploy a update the change is overwritten.
The solution can be that the client can't edit forms or that a content stop for forms is in place when working on updates.
This is almost impossible when working on large project where the client has multiple content-editors and there are multiple developers working on new features. It is impossible to prevent something going wrong at some time in the future.
Therefore I propose that forms and workflows should be handled as a form of content. Where you can choose to restore forms from a particular environment and the ability to queue them for transfer.
I'd like to hear your opinions.
I just checked how we solved for a project on cloud where we use forms.
On our local environment we prefix all our forms with "DEV". Editors will not use these forms in content.
So when we make changes we can safely deploy without touching forms on the live environment.
Editors can just copy these forms if they want to use them. Changes to existing forms need to be done manually however.
Since I migrated this site all forms are present on all environments. Therefor all existing forms are in danger right? Testforms can be excluded and prefixing is a great idea.
I was notified of a existing issue in github:
Also I noticed that there is a Queue for tranfer possibility on a form at least in V7. (That seems strange as forms are pushed anyway as metadata? ) but no possibility to restore from another environment.
is working on a reply...
Write your reply to:
Image will be uploaded when post is submitted