Feature #82211
closedAllow generlOverride in formDefinitionOverrides
0%
Description
Currently it's possible to override form definitions for specific identifier.
If you have multiple forms and allow editors to add forms not all identifier are known while add typoscript for overriding.
Having an generalOverride that gets merged before the override of an identifier this would solve it.
Updated by Gerrit Code Review about 7 years ago
- Status changed from New to Under Review
Patch set 1 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/53809
Updated by Mathias Brodala almost 7 years ago
I'm not sure how exactly this would help with the usecase described. The only thing that would work reliably here is overriding toplevel form definition properties. As soon as you have renderables
keys can be arbitrary (of course identifier
s too) which makes it next to impossible to override specific entries.
Updated by Susanne Moog almost 7 years ago
- Target version changed from 9.0 to 9.2
Updated by Björn Jacob almost 7 years ago
- Status changed from Under Review to Needs Feedback
Sebastian, what do you think regarding Mathias's response? Do we still need this feature? How did you solve the issue for you? If you do not need this feature anymore, please abandon the patchset. Afterwards, we can close the issue. We are also open for discussing. On February 19 and 20 we are having a small sprint. This could be a good time for discussions ;)
Updated by Sebastian Fischer almost 7 years ago
Hi Bjoern,
i did not solved it for me. I just copies the form and modified the needed keys.
But to catch up Mathias comment i agree on what he said. BUT if we dont need a general overrides feature, why do we have an override for individual form definitions? Because what is true to my addition is also true to the part that is already there.
Once you are in a scope of renderable keys you cant override with $formDefinition['identifier'] anymore too.
For what i needed it was not solved by logic and clever coding but by swapping out templates by changing pathes via typoscript conditions. I still think its a stupid way of doing that but i wasnt willing to carry patches agains the core for that purpose.
If you still have problems with the patch i would like to know what the problem with the patch is. But by know it was only delayed without any good reason. I'd like to bring this issues to a solution but dont realy see what is blocking it.
I put it in your hands. If you think that having the opportunity to override all forms with certain values is less important then overriding values in forms with defined names then drop my request and explain why you dont want to have it in.
Kind regards
Sebastian
Updated by Sebastian Fischer almost 7 years ago
In addition: small example what is possible with that patch. You are able to override labels in a multilanguage multitree situation. Define the form once in german and have in a separate english tree different labels.
Or you can override email finisher configuration for development/staging to send the emails to a different testing emailbox then on production environment. For all forms even those that get added by editors in a later project state.
Updated by Björn Jacob almost 7 years ago
- Status changed from Needs Feedback to New
- Assignee deleted (
Sebastian Fischer) - Sprint Focus set to Remote Sprint
Thx Sebastian. Next week we are having a small sprint to discuss the features of v9. I will put this issue on our agenda. Thx again for the detailed feedback and your effort.
Updated by Ralf Zimmermann over 6 years ago
The feature to override specific form definitions with typoscript is thought for integrators that render static forms from their site package.
Since these forms can not be changed by an backend editor, all form elements and their positions are known.
I think an override which applies to all forms for reasons already mentioned above is not helpfull.
We are currently developing a concept for conditional form elements, which should also solve the usecases you described.
In the next few days i will upload a first related patchset.
Updated by Ralf Zimmermann over 6 years ago
In the next few days i will upload a first related patchset.
Updated by Ralf Zimmermann over 6 years ago
- Related to Feature #84133: Variants - Frontend implementation added
Updated by Ralf Zimmermann over 6 years ago
- Status changed from New to Needs Feedback
- Assignee set to Sebastian Fischer
I think your use case can be handled with variants #84133.
Feel free to test the patchset :)
Updated by Sebastian Fischer over 6 years ago
Looks good to me. So this ticket can be closed in favor of 84133
Updated by Ralf Zimmermann over 6 years ago
- Status changed from Needs Feedback to Closed
- Assignee deleted (
Sebastian Fischer)
Thanks.