Problem/Motivation
In #1875992: Add EntityFormDisplay objects for entity forms we introduced the foundation for form modes but without any actual usage in core. This is the necessary followup :)
Form modes are the equivalent of view modes, applied to entity forms. They were whispered around the corners in various issues for quite a while (e.g. #1668292-17: Move simplified Profile module into core), greated with much enthusiasm at the end of the Field API session from DrupalCon Portland and, imo, mandatory if we want to fix things like #1911080: Replace menu node form additions with entity reference field in a truly generic way. They are also *very* useful for dead-simple creation of multistep entity forms (wizards in ctools speak).
Thanks to the recently added hidden widget and entity form displays, this functionality is achieved by removing code from core .. *gasp* :D In a nutshell, the patch removes half of field_ui.js, 30-40% of field_ui/FieldOverview.php, field_ui/Form/FieldWidgetTypeForm.php entirely, and refactors field_ui/DisplayOverview.php and a couple of other pieces to work generically for both widgets and formatters.
Who will benefit from this
- Kill the checkbox workaround in Field API to show fields on user register form
- Menu entity form embedded in nodes
- Multi step form
- Inline entity form
- DS/FieldGroups - whoever, because we now have a unified UI (technically) for moving rows around, changing formatters etc.
User interface changes
- a new 'Manage form display' tab appears in all Field UI screens, between 'Manage fields' and 'Manage display'
- the drag-n-drop functionality from 'Manage fields' dissapears
- Extra fields are not displayed anymore in the 'Manage fields' tab
-
widgets will be handled (like field formatters) in only one screen: 'Manage form display'. Previously they were scattered in three places:
- they were originally selected in 'Manage fields' when you create a new field
- their settings were handled in the instance edit form
- they could be changed in a separate form, presented as a subtab of the instance edit form
Note that yoroy approves the patch, see #7548917, follow ups are also in there and listed below.
API changes
- a new 'form_mode' config entity is introduced, handled exactly like the 'view_mode' one introduced in #1043198: Convert view modes to ConfigEntity
- the hacky 'user_register_form' setting dissapears from all field instances
Followups/Related
- #731724: Convert comment settings into a field to make them work with CMI and non-node entities
- #2028759: Clean up instance['widget'] in Field UI
- #2028769: Should the 'default value' handling in the instance edit form only use the default widget of a field?
- #1963340: Change field UI so that adding a field is a separate task - additionally - currently, fields are listed alphabetically, could be changed, although it makes sense now. Also 'Manage fields' tab could be converted to EntityListController in there
- #2029835: Deprecate procedural functions which have been moved to the Field class
- #2029857: Field plugin settings edit button doesn't show unless there is a settings summary
- #2041225: FieldInstance::delete() doesn't clean up all form modes
Remaining tasks
implement the new settingsSummary() method for all existing widgetscreate the equivalents of hook_field_formatter_settings_form_alter() and hook_field_formatter_settings_summary_alter() (right now they are still called in the base class, therefore executed for both formatters and widgets)immediately update summary after switching widgetupgrade path
Another debatable/sensitive part is the $operation argument of entity_get_form(), which currently maps to entity form controllers. In the initial patch I've let them coexist in peace, giving us following options. Using 'step_1' as an example form controller/operation AND the same 'step_1' form mode:
- if both the form controller and form mode exist, the entity form will use the 'step_1' form controller and display only the fields configured in the 'step_1' form mode
- if the form controller exists but the form mode does not, the entity form will use the 'step_1' form controller and display the fields configured in the 'default' form mode
- if the form controller does not exist but the form mode does, the entity form will use the 'default' form controller and the fields configured in the 'step_1' form mode
Now, given that #1839516: Introduce entity operation providers has seen some movement lately and it's likely to get into D8, I think it makes sense to just rename the current entity 'operation/form controller api' to a 'form mode api'. This way, we will still have the three cases from above, but the concept will be much simpler: Entity forms use form modes in order to determine what fields to display in a specific form, and form modes can (but not necessarily) have a dedicated form controller for other custom processing needs.
Work happens
In a sandbox, see http://drupalcode.org/sandbox/yched/1736366.git/shortlog/refs/heads/2014...
Comment | File | Size | Author |
---|---|---|---|
#81 | entity-form-2014821-81.patch | 1.17 KB | tim.plunkett |
#76 | 2014821-form_modes-75-do-not-test.patch | 217 KB | amateescu |
#76 | interdiff.txt | 1.16 KB | amateescu |
#74 | 2014821-form_modes-74.patch | 217.06 KB | amateescu |
#74 | interdiff.txt | 9.41 KB | amateescu |
Comments
Comment #1
amateescu CreditAttribution: amateescu commentedI haven't touched the tests at all because we first need to agree on the general direction of this patch, so let's use simplytest.me and/or manual testing for now :)
And please don't start with doxygen nitpicking yet...
Comment #2
amateescu CreditAttribution: amateescu commentedI forgot to say that this patch depends on #1982138: Clean out field_ui.admin.inc and has to be applied on top of the latest patch in that issue.
Comment #3
amateescu CreditAttribution: amateescu commentedHere's a combined patch for easier testing.
Comment #4
swentel CreditAttribution: swentel commentedHELL YEAH - just did a quick spin, this is SO COOL, especially the user part. Are you working on this in a branch ?
Comment #5
Wim LeersIntriguing :)
To me, it is not entirely clear what the exact use cases are for form modes. View modes have very clear use cases, and it's easy to think of examples. Can you provide some practical examples for what form modes brings us?
You mention #1911080: Replace menu node form additions with entity reference field, but to me it's not immediately obvious how this helps address that. You also mention multistep entity forms; I presume each step would then be a form mode of its own?
So I guess what I'm asking is: can you provide more obvious examples?
I think that would help other people understand this issue better too :) Thanks!
Comment #6
swentel CreditAttribution: swentel commentedAn obvious one: User register vs user edit - there's now a stupid workaround in field api when you add fields on the user account that adds a checkbox which says 'show on user register form'. Killing that hardcoded stuff is a must.
Comment #7
tim.plunkettThis is an unfortunate switch, and directly conflicts with the entire premise of #2006348: Remove default/fallback entity form operation.
The magic 'default' fallback is very confusing and has led to over-re-use of form controllers.
Comment #8
effulgentsia CreditAttribution: effulgentsia commentedI don't have an opinion at this time about that with respect to this issue, but once #1875974: Abstract 'component type' specific code out of EntityDisplay is done, we should be able to remove the concept of 'extra fields' entirely.
Comment #9
bojanz CreditAttribution: bojanz commentedBig use case: Inline Entity Form.
An entity being managed inline doesn't need the same fields as when it's being managed standalone.
Comment #10
amateescu CreditAttribution: amateescu commentedFunny you ask that. Today I deleted my entire D8 dev environment because of a drush experiment gone bad :) Luckily enough, I had backups at home and also the current version of the patch on the desktop, so I just lost a bit of git history. I'll push everything to a branch in the Field API sandbox after I finish this post.
Example 1 - what core gets right now.
We replace this:
With this:
Example 2 - Multistep entity forms (wizards):
You are correct, each step will be a form mode.
Example 3 - #1911080: Replace menu node form additions with entity reference field:
That issue needs this patch and another one for Entity reference, an Inline/Embeddable Entity Form widget. If we get them both, we'll be able to expose a form mode that will be used by the IEF widget to only show a restricted set of (relevant) fields of the menu_link entity form, when embedded in the node form.
While it may be unfortunate, we just need to try and find a compromise. The entire form mode concept relies on having a default form controller as a fallback. One thought that comes to mind is that after all the Entity/Field/whatever NG work is done, we could fallback to EntityFormController, which should be able to properly handle all entity fields by then.
Unfortunately.. not really, I already tried :) #1954188: Revaluate the concept of 'extra fields'
Fixed a couple of things in this new patch and implemented settingsSummary() for the File and Image widgets. Also, I'll have to move the part about settingsSummary() from 'followups' to 'remaining tasks'. Without this completed, we won't be able to edit any widget settings :/
There are still a couple of quirks here and there, like settings not being taken from $form_state anymore, but I'm done for today. Eagerly waiting for some actual patch reviews :)
Comment #11
tim.plunkettabstract
Do we actually need another base class?
---
Because of the OverviewBase refactoring/renames, it's immensely hard to see if anything changed, and what it was.
The parts outside of that (deletions and search/replace) look straightforward.
Comment #12
amateescu CreditAttribution: amateescu commentedI'll leave the abstract thing for when there'll be more stuff to fix.
Right now, yes, we still need OverviewBase because FieldOverview uses it. It's mentioned in the OP in followup tasks that we could move FieldOverview to be a ListController, at which point we will be able to merge in/remove OverviewBase.
About the hard to review part:
DisplayOverview
has turned into abstractDisplayOverviewBase
whichDisplayOverview
(yeah, same name, confusing) andFormDisplayOverview
extend. What changed inside it is:- moved the generation of a field and an extra field outside of buildForm() to the buildFieldRow()/buildExtraFieldRow() helper methods
- moved everything that was getting formatter-specific info to helper methods (about 10 of them)
Comment #12.0
amateescu CreditAttribution: amateescu commentedAdded an example issue where form modes were mentioned.
Comment #13
swentel CreditAttribution: swentel commentedHaha, good one :) Got the branch locally, I'll play around with it today a bit as well and - if applicable - commit obvious fixes.
Comment #13.0
swentel CreditAttribution: swentel commentedMoved a task from 'followups' to 'remaining tasks' to be done in this patch.
Comment #13.1
swentel CreditAttribution: swentel commentedUpdated issue summary.
Comment #14
swentel CreditAttribution: swentel commentedMore changes:
Note, if you want to play around with this beauty, it's easier to clone from http://drupalcode.org/sandbox/yched/1736366.git/shortlog/refs/heads/2014... (also added to issue summary)
Comment #14.0
swentel CreditAttribution: swentel commentedUpdated issue summary.
Comment #15
amateescu CreditAttribution: amateescu commentedYay, #1982138: Clean out field_ui.admin.inc was just committed.
Comment #16
swentel CreditAttribution: swentel commentedFixing title
Comment #17
amateescu CreditAttribution: amateescu commentedImplemented all the remaining tasks from the issue summary so I think we're ready for some final reviews!
Comment #17.0
amateescu CreditAttribution: amateescu commentedUpdated issue summary.
Comment #19
amateescu CreditAttribution: amateescu commentedFinally, after 4 tries the testbot had mercy on this patch :)
Comment #20
bojanz CreditAttribution: bojanz commentedThis already needs a reroll, core moves fast.
I'm not the perfect person to review the code of this, but the removal of the user register form checks already shows what a nice cleanup this is.
It is going to offer a whole world of possibilities for Inline Entity Form, since users will now be able to select which fields they want to edit when they're managing an entity inline (VS separately).
Comment #21
amateescu CreditAttribution: amateescu commentedHere we go.
Comment #22
yched CreditAttribution: yched commentedI'm afraid you guys shouldn't wait for me to get this reviewed :-(. I'm going afk in like four days, and I'm buried deep down in #1969728: Implement Field API "field types" as TypedData Plugins. @swentel is hell bent on the patch though, and he's as qualified as me to get this in.
FWIW, I totally dig how this is reorganizing the code for the "manage" screens.
Thanks a ton @amateescu for the awesome job, really sorry I can't help.
Comment #23
swentel CreditAttribution: swentel commentedThis is just a first, quick review. Overall this patch is a beauty, the cleanup, but especially, the consistency in Field UI in code for form and display is like what we once started to work on in #1786198: Make consistent regions in code for fields UI overview screens, where we tried to introduce regions as well. This alone is going to make life less stressfull in contrib.
From the issue summary:
This sounds weird. On manage display, we sort by weight no ?
More will follow during the weekend when I'll be playing around with it on a local install and battle testing it, and also looking at the full code as it's sometimes hard to tell from dreditor.
A few things
This is fantastic, this is paving the way which we are almost exactly exploring in #1875974: Abstract 'component type' specific code out of EntityDisplay
The call to field_bundle_settings will be refactored in #1953528: Store 'per-bundle view mode settings' in CMI, get rid of field_bundle_settings() & its variable, so we can get rid of the variable, no biggie to keep this as is in this patch initially though.
This array_search and array_slice concerns me a little. It reminds me of doing freaky stuff with DS and/or Field group. I'm going to look at the code whether we can't come up with a saner solution.
Nitpick, 80 chars.
Nitpick, missing '.' at the end.
Comment #24
swentel CreditAttribution: swentel commentedI've also asked yoroy to have a look at this patch and briefly explained him what this patch does.
Comment #24.0
swentel CreditAttribution: swentel commentedUpdated remaining tasks.
Comment #25
amateescu CreditAttribution: amateescu commentedIt sounds weird because it is weird :P It was just a silly mistake though, I meant to say the 'Manage fields' tab. Corrected in the issue summary too.
Thanks for starting the review, I'll wait for full thing before doing any updates :)
Comment #26
swentel CreditAttribution: swentel commentedRight, I was almost assuming that :) I'm totally fine with alphabetical.
Comment #27
yoroy CreditAttribution: yoroy commentedExciting patch! Applied succesfully etc.
But it's hard to review with the similarly named tabs, makes it hard to tell what you are looking at :-)
Comment #28
yoroy CreditAttribution: yoroy commentedignore the above attachment
Comment #29
amateescu CreditAttribution: amateescu commentedI suspect you're talking about the node / comment tabs? That's a pre-existing problem in HEAD :( Try looking at the UI for users (admin/config/people/accounts/fields).
Comment #30
yoroy CreditAttribution: yoroy commentedOk, playing around on http://d8:8888/admin/config/people/accounts/form-display
It's confusing to see the same items in different tabs. Lack of context makes it hard to understand what exactly you are editing here.
Drag & drop seems to be broken. I move 'Admin overlay' to the disabled section by using the 'Widget' select list. Moving it back up via drag and drop doesn't work. The 'drop' doesn't seem to register (the value select list isn't updated). I can leave the field in the enabled area but after saving it still shows up in the disabled area
Also, I have no idea what the 'Administrative overlay' field means to do. I see no difference between that one enabled or disabled. Tried the same with disabling timezone field, but that also still showed up on my user edit form.
So far, powerful but confusing, lots of dots to connect across multiple screens and page refreshes in order to grasp what is going on. I'll have to spend some more time with this, but that's it for now.
Comment #31
larowlan#731724: Convert comment settings into a field to make them work with CMI and non-node entities will fix the duplicate node and comment tabs
Comment #32
amateescu CreditAttribution: amateescu commentedRerolled after #1950632: Create a FieldDefinitionInterface and use it for formatters and widgets and fixed nitpicks from #23 as well as the annoying 'No fields are present yet.' message which appeared all the time on the 'Manage fields' tab since we removed the JS that was hiding it. Added a @todo to bring it back in #1963340: Change field UI so that adding a field is a separate task.
Re #30:
Thanks for taking a look at this!
The same thing happens in 'Manage display'... you see the same set of fields for different view modes.
Drag & drop works just fine, you probably need to clear the browser cache :)
The 'Administrative overlay' field was there before this patch, but I agree it's confusing and we should open a new issue to find a better label for this extra field.
The point about hiding extra fields (like 'Administrative overlay' and 'Timezone') is a very good one though, because those fields are usually added in hook_form_alter()s and are not controlled by EntityFormController. So I guess we need to either change the way they're added to entity forms, or implement a form alter at the latest stage possible so we can hide them.
Comment #33
yched CreditAttribution: yched commentedExtra fields not being hidden :
That's my remark in the second half of #1875992-95: Add EntityFormDisplay objects for entity forms : any code that currently adds an "extra-field" in a form (be it in a form controller method or in a form_alter()) should check the visibility assigned in the $form_display first. That's how it works on the entity_view() side.
OR, we could treat things a bit differently on the form side, and have an additional step that runs after the alter() hooks and automatically adds #access = FALSE to all the extra fields that are supposed to be hidden.
But currently, yes, you can configure an extra field to be hidden in a form, but it will still stay visible. In current HEAD, nothing lets you do that through the UI, this is what this patch does - but the wrong behavior is already in HEAD.
Comment #34
amateescu CreditAttribution: amateescu commentedRight, so I ended up with the same conclusion after forgetting that you already warned about this in the initial issue :) Anyway, from those two options, I think I prefer the one that does a bit more hand-holding and hide them automatically in an "post alter" step.
But since this issue is currently followed by 42 people, I'd definitely like to hear more opinions :)
Comment #35
yoroy CreditAttribution: yoroy commentedis ycheds link the issue to learn about extra fields? i'm not sure what they are and why they are 'extra'.
Comment #36
amateescu CreditAttribution: amateescu commented@yoroy, nope, extra fields is a concept that we already have in D7. The best documentation that I can find for them is the one from the doxygen of hook_field_extra_fields().
But for the purposes of testing this patch, you don't really need to worry about extra fields. If you want to see something that works in the current version of the patch, just hide a 'regular' field, like the user picture. Or add a new field and hide that one :)
Comment #37
yched CreditAttribution: yched commentedThe approach of "let each extra field check its own visibility itself" was adopted on the display side because this saves some CPU (not generate possibly costly render data if it's going to be hidden).
Form rendering is less performance critical, and a $form entry being sometimes present / sometimes absent might have nastier effects on the validate / submit flow, so going with "always add, automatically set #access = FALSE on the stuff that should be hidden" on forms specifically might be best indeed.
Comment #38
swentel CreditAttribution: swentel commented+1 one on that
Sorry for the promised update, got completely distracted, will be for the next 3 days as well.
One other thing that I'm not sure of (I should test I know) - can you 'disable' a form mode from the UI from being configured, just like you can with view modes ? So in case 'register' is not used, it falls back on the default one. In case that's ok, please ignore this question completely.
Comment #39
amateescu CreditAttribution: amateescu commentedOk, so I had to fix two bugs in HEAD:
And, finally, moved the code that was assigning weights and added the code that hides extra fields in a form process callback.
Comment #41
amateescu CreditAttribution: amateescu commentedStupid mistake..
Comment #43
amateescu CreditAttribution: amateescu commentedChasing HEAD.. can't seem to catch it, or a working testbot for that matter :)
Comment #45
yoroy CreditAttribution: yoroy commentedI tested the patch in #39 today and spent an hour with amateesco discussing this with amateescu in IRC.
At first glance this looked really worrisome! Another two tabs on Field UI really makes a mess and hits the limits of what that UI can contain right out of the box.
Amateescu had two important points that took away many of the ux concerns (boiling down to overloading an already overcrowded UI):
- #731724: Convert comment settings into a field to make them work with CMI and non-node entities which would remove the comment fields and comments display tabs from the Field UI for content types. This makes room for the additional Form tabs this patch introduces
- #1963340: Change field UI so that adding a field is a separate task would create new specific point of entry for an important task in Field UI. A general issue with Field UI is that most of the magic (all those powerful fields) is hidden in dropdowns somewhere at the bottom of a complex ui
While I of course can't force it, I consider those two issues must-haves in order for this to go in. The form modes in this patch add more complexitiy to an already crowded and hard to grasp interface. The other two move some of that complexity to seperate screens, which balances things out nicely.
To be clear: I really think we should try to land this in core, it's powerful framework stuff with a lot of potential.
So for the patch itself we mostly should look into some better labels for the tabs and probably introduce a line of help text to explain that "over there you arrange the display of the content, over here you arrange the display of the form that content is created with."
Any other changes will quickly hit 'redesign Field UI' territory. Which is not the scope of this issue but that one.
Go go go! :-)
Comment #46
amateescu CreditAttribution: amateescu commentedShould be better now.
Comment #47
plachJust a (probably) dumb question from an outsider perspective, but wouldn't having a first-level "Fields" tab with 4 second-level subtabs help de-clutter these screens?
Comment #48
plachComment #49
amateescu CreditAttribution: amateescu commentedThanks @yoroy for the write-up :)
There are some points there that I want to address:
1) This patch only adds one tab to the Field UI interface, 'Manage form display'.
Only in the case of nodes two tabs are added, one for nodes and one for comments. This is where #731724: Convert comment settings into a field to make them work with CMI and non-node entities helps and gets rid of comment-related tabs from the content type edit UI.
2) The patch from #1963340: Change field UI so that adding a field is a separate task is indeed a must-have, but we can't really consider it as a dependency for this one, as it will be *a lot* easier to do after this one lands, because we refactor/simplify most of the code for 'Manage fields' here.
Comment #50
amateescu CreditAttribution: amateescu commented@plach, then we would need some third-level tabs to display form and view modes :)
Comment #51
yoroy CreditAttribution: yoroy commentedGood clarifications by amateescu. Yes, I didn't mean to suggest technically dependant, just that for an acceptable UX we should get those other two issues done as well.
Comment #52
plachAh, right, the screenshots didn't show the second-level. I still need to study more :D
Comment #53
amateescu CreditAttribution: amateescu commentedAdded some help text for the node and user 'Manage form display' tabs. I don't have any ideas for renaming the tab labels so I'm waiting for suggestions on that :)
Comment #54
amateescu CreditAttribution: amateescu commentedForgot to merge HEAD.
Comment #55
Dries CreditAttribution: Dries commentedI'm supportive of this patch. It looks cool. I haven't looked at it in detail yet (no code review).
Comment #56
cweagansI am SO EXCITED for this patch. I'm hoping to circle back to this for a code review at some point this week.
Comment #57
amateescu CreditAttribution: amateescu commentedThanks, guys! Let the reroll games begin :)
Comment #59
amateescu CreditAttribution: amateescu commentedFixed a new test and a merge conflict.
Comment #61
Berdir#59: 2014821-form_modes-59.patch queued for re-testing.
Comment #63
amateescu CreditAttribution: amateescu commentedRerolled.
Comment #63.0
amateescu CreditAttribution: amateescu commentedFixed wrong tab name.
Comment #63.1
swentel CreditAttribution: swentel commentedUpdated issue summary.
Comment #63.2
swentel CreditAttribution: swentel commentedUpdated issue summary.
Comment #64
amateescu CreditAttribution: amateescu commented@swentel did a live review and we found some small issues, corrected in ef59fea and 4a16ce8.
He also cleaned up the issue summary and added a small followup issue (which needs to fix a current bug in HEAD, not introduced by this patch).
Comment #65
swentel CreditAttribution: swentel commentedLet's do this!
Comment #66
amateescu CreditAttribution: amateescu commentedRerolled after #111715: Convert node/content types into configuration and also includes #2029471: Regression: Content types do not respect all permissions defined by Field UI for reviewing pleasure :)
Comment #68
amateescu CreditAttribution: amateescu commentedRerolled because #2029471: Regression: Content types do not respect all permissions defined by Field UI was committed. The fail above passes locally and doesn't look related.. let's see if this one has better luck.
Comment #69
swentel CreditAttribution: swentel commentedBack to RTBC
Comment #70
tsphethean CreditAttribution: tsphethean commentedAdding follow up to deprecate functions in field.info.inc #2029835: Deprecate procedural functions which have been moved to the Field class
Comment #70.0
tsphethean CreditAttribution: tsphethean commentedUpdated issue summary.
Comment #71
alexpottforn_mode?
This should implement an interface and all the abstract protected functions should be moved there.
We need to implement a testWidgetUI based on testFormatterUI
Comment #72
tim.plunkettProtected methods cannot be on an interface.
Comment #73
alexpott@timplunkett good point... and if we need to make anything public this is an API addition so something we can do later....
Comment #74
amateescu CreditAttribution: amateescu commentedHere we go, less typos and more tests :) Thanks for the review!
Comment #76
amateescu CreditAttribution: amateescu commented@swentel found some debug() leftovers..
Comment #77
amateescu CreditAttribution: amateescu commentedUgh, mixup here.. I just asked for a retest of #74 because #76 doesn't add anything new :)
Comment #78
swentel CreditAttribution: swentel commentedLooks good, RTBC if green, apart from a little one:
Alex, you ok with changing 'hook_field_formatter_settings_summary_alter' to 'hook_field_widget_settings_summary_alter' on commit if nothing else comes up ?
Patch in #76 is the right one.
Comment #79
alexpottCommitted 4586ea1 and pushed to 8.x. Thanks!
Comment #80
effulgentsia CreditAttribution: effulgentsia commentedYay!
Comment #81
tim.plunkettSame as the case below it.
Comment #82
amateescu CreditAttribution: amateescu commentedOops, sorry about that :/ And thanks, Tim!
Comment #83
alexpottCommitted 4b22498 and pushed to 8.x. Thanks!
Thanks @timplunkett
Comment #84
nod_This changes JS file it gets the JavaScript tag.
Comment #85
andypostAdded follow-up #2030207: Do not load all field instances when replacing image style
Comment #86
andypostrevert
Comment #86.0
andypostUpdated issue summary.
Comment #87
andrewmacpherson CreditAttribution: andrewmacpherson commentedAdded #2029857: Field plugin settings edit button doesn't show unless there is a settings summary as a follow-up
Comment #88
yched CreditAttribution: yched commentedFollowup: #2041225: FieldInstance::delete() doesn't clean up all form modes
Comment #88.0
yched CreditAttribution: yched commentedadded follow-up link to #2029857
Comment #89
andrewmacpherson CreditAttribution: andrewmacpherson commentedadded #2041225: FieldInstance::delete() doesn't clean up all form modes to this issue's summary
Comment #90
yched CreditAttribution: yched commentedNote : opened #2049485: Remove traces of the 'user_register_form' field setting to remove 'user_register_form' from the existing config entries and config schemas
Comment #91
amateescu CreditAttribution: amateescu commentedComment #92
catch#2083415: [META] Write up all outstanding change notices before release
Comment #92.0
catchadding follow-up issue #2041225
Comment #93
xjmTagging "Missing change record", as completing the change record updates here blocks a beta: #2083415: [META] Write up all outstanding change notices before release.
The patch for this issue was committed on June 27, 2013, meaning that the change record for this (very delectable) issue has been outstanding for more than seven months.
Comment #94
geerlingguy CreditAttribution: geerlingguy commentedI'm working on a change record... will update when complete.
Comment #95
geerlingguy CreditAttribution: geerlingguy commentedHere's my initial stab at the change record: https://drupal.org/node/2186197 - please see how you like it, edit it to improve it... since there weren't any real API changes, more just additions/subtractions, I didn't have any Drupal 7 vs. 8 code examples.
Comment #97
rlmumfordFor those that are interesting in this feature, something similar can be achieved on Drupal 7 using the Flexiform module. https://drupal.org/project/flexiform
Comment #98
giorgio79 CreditAttribution: giorgio79 commentedJust gave form modes a spin, and created a form mode for a content type. I don't see where can we access the alternative form mode other than the default? I would have expected an option to be presented when clicking on "Add Content" to select "Add xy content with xy form mode"? Raised it as an issue at #2530086: How can we access the new form modes?
Comment #99
yched CreditAttribution: yched commented@giorgio79 : Answered over there