Towards using EntityForm.tpl for Membership type & enabling custom data #12591
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Overview
We now have a standard for enabling custom data on a form that does not currently support it - ie. by using the EntityForm.tpl. The membership type form is partially converted & this takes that a bit further
Before
No UI change. Less usage of metadata
After
No UI change, more usage of metadata
Technical Details
There are 2 things to progress to switch the form over
This does a bit of both. It's mostly aimed at reducing some of the 'noise' to find the real issues in the conversion. So far I have spotted the auto-renew text might be a problem. I think the metadata will handle it as written but I haven't tested much and there is nothing in Field.tpl to cope with putting 2 fields on the same row which is the next challenge.
Comments
@mattwire do you want to take a look - it's just another incremental step & a way to break this down into more manageable chunks