Problem/Motivation
A project we're working on needs two different form modes for the media-instance Add forms on e.g. a Node field. The difference is per field, and so configuration would be in the field widget.
In this case the need arises because some media fields need to use manual crop for the image while others need a focal point method, and so a single form mode (media_library) is insufficient to the task.
Steps to reproduce
The media library hard-codes both the form mode and the preview image style using the name 'media_library', the form mode being set in AddFormBase.php. There are no workarounds.
Proposed resolution
A patch is presented which introduces a new select element on the media library widget, together with the needed changes to the MediaLibraryState object to pass this value along to the place it's needed in AddFormBase::buildForm().
Remaining tasks
I think this works. Test code has been adjusted so it still works, but no new test code has been added.
This patch includes some changes to source formatting mostly to reduce line lengths to somewhat reasonable limits.
User interface changes
A new Select element is added to the Media Library Form widget. It defaults to the existing value (Media Library | media_library).
API changes
A new class, "media_library_form_mode--" + the form mode, is added to the <form> element.
Data model changes
The MediaLibraryState has been extended, but initializations have compatible defaults.
It is possible that media embed code might need adjusting as well (as has been done here for ckeditor).
Release notes snippet
| Comment | File | Size | Author |
|---|---|---|---|
| #43 | core-11.2-3323232.patch | 23.08 KB | graber |
| #42 | core-10.3-3323232.patch | 23.06 KB | graber |
| #28 | 3323232-28.interdiff.txt | 1.27 KB | rivimey |
| #26 | 3323232-26.patch | 38.81 KB | rivimey |
| #26 | 3323232-26.interdiff.txt | 3.13 KB | rivimey |
Issue fork drupal-3323232
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #2
nivethasubramaniyan commentedFixing patch issue
Comment #3
nivethasubramaniyan commentedFixing CCF #2
Comment #5
rivimey@NivethaSubramaniyan thanks for your help, hadn't expected any :-)
I was asked to reduce the number of code style improvements (aka whitespace changes!) and did that before I saw your patch. I believe I've incorporated all the changes you made (good catch on the tests missing form mode var). Although I've retained media library state tests having a class variable I don't think it's actually used (yet).
This patch will probably fail for the same reason the last did - config schema update failure. Not yet sure why.
Comment #6
rivimeySome further work, fix patch format.
Comment #7
heddnthis would have to be something set on the media-embed filter plugin config and we get it from there.
please revert this whitespace change.
no need to add a css class here.
Can we add the form mode as a stored value in form_state? I see that as a more normal mechanism to pass around data for forms.
please don't change the whitespace here.
This isn't needed if we pass the form mode as a stored value in form state.
Please revert this change.
please revert this whitespace change.
please revert this change.
please revert this.
please revert this.
This breaks a lot of contrib modules when we add the form mode parameter. We'll need to add it as the last parameter and do a BC dance.
please revert most of the whitespace changes here.
this change isn't needed. can we revert it.
In the first case, we line wrap. In the second, we do it one longer line. I prefer the second as its less connotative dissonance to read across 2 lines when the things are fairly short. Let's do the same thing in both places.
If we don't remove this line and move it down below, it makes the code more happy when applying in 9.4/9.5. Let's not fix up anything except the summary additions.
Whitespace change. Please revert.
The field widget should have this as a config option.
whitespace noise. please revert.
this is a test, no need for a todo here.
please revert the whitespace fixes here.
is the form mode intentionally empty here?
please revert the whitespace changes here.
no need to ask. this is a test.
please revert whitespace.
no need to ask, this is a test.
please revert whitespace.
same here. and through the rest of the tests. for both the form mode and the whitespace changes.
Comment #8
rivimeyReverted more ws
Fix settingsForm() (no form mode selector if only one media type set up);
Changes to MediaLibraryState to follow.
Comment #9
rivimeyMediaLibraryState change: move new form_mode to end of sig.
Comment #10
rivimeyComment #11
rivimeyAdd in a default view mode constant and use; use default form mode for more things
Comment #12
rivimeyComment #14
rivimeyThree fixes:
- Fix medialib test module schema - add form mode to widget
- Additional form mode default strings - quoted string to use of const var;
- Fix use of static form mode - using as object but decl static => object.
Comment #15
rivimeyComment #16
rivimeyComment #18
heddnHere's some clean-up. I'll have some comments coming next.
Comment #19
heddnThese are duplicates of each other. Let's use the value from State everywhere instead of the widget.
What is this testing?
Let's use the constant from State instead of this value here. Let's use the constants in all the creates directly instead of a class level property.
Instead of setting this as a class level property, let's do individually on each of the state constructions. More configurablity and it will be clearer what is going on.
Comment #20
rivimey@heddn, re:
(1), these aren't duplicates - one is a form mode and one a view mode. I haven't done any work around the view mode but decided that giving this particular constant string a defined name was good for clarity and stopped me thinking it was a form mode string I'd missed!
I could put both in the same place, but given the State class is only about forms, I decided against that.
(2) It's testing that the validation of a form-mode string does reject invalid strings.
(3) ok - I thought of that but rejected it because that would mean it automatically used the 'right' value, whereas in testing we're trying to find out if the right value is the right value, if that makes sense.
(4) ok - I went for something simple as there were multiple uses.
Comment #21
heddnComment #22
rivimey(1) ok, deleted.
(2) deleted. however, I don't think that the tests cover any value other than 'media_library'.
(3) adjusted (& updated a few places to change likewise).
(4) updated to use local form_mode var.
Comment #23
heddnWhy didn't this build on top of #18? Or at least it doesn't seem like it builds?
Comment #24
rivimeyComment #25
rivimeyIncorporate multiple changes from #18 & Improve comments:
* Integrate form_modes fetch into array construction;
* update further comments;
* use (string) as form_mode type when possible, enabling a better validation condition;
* add explicit public for DEFAULT_FORM_MODE.
Comment #26
rivimeyCope with explicitly-passed NULL form mode to create/validate state.
Modify settingsSummary change because for some reason patch refused to apply hunk occasionally.
Comment #27
rivimeyComment #28
rivimeyUpdated patch to fix phpcs notices.
Comment #29
_utsavsharma commentedFixed CCF for #26.
Please review.
Comment #31
rivimeyRe #29 sadly that is the wrong fix - I would have liked it to be the right one, but in fact the code has to be able to accept NULL for form_mode even though there is a default arg value because some code passes NULL explicitly.
My patch #28 doesn't work because I included a change to autoload.php. Removed.
Comment #32
heddnwe'll need an update hook to add a default value for the form_mode anywhere the widget is used.
Comment #33
heddnThis will also need a CR at some point. Several contrib modules have the form mode hard coded. For example, focal_point uses a hard-coded value.
Comment #34
rivimey@heddn I don't understand your request for a hook - the form_mode will be stored in the same schema that stores the existing state...
Is it that some other code thinks it 'knows' media_library is the right form to use and hard-codedly fetches that? I'm not sure how anything can be done except file issues to fix it once this change is merged?
For reference, I believe this is the focal_point module function that would need changing:
Comment #36
graber commentedStyling of links got broken after some recent core update. Going for a local solution and documenting here in case this issue got more attention again eventually:
in implementation of
hook_preprocess_links__media_library_menu()Probably a vertical tabs #type should be used here instead of the
'#theme' => 'links__media_library_menu',that has a couple of preprocess in various themes but not much, currently basically those are links and not much more.Comment #37
graber commentedOk, actually it's a core issue and has nothing to do with the work here. Reproduced on a clean instance with no patch.
Ignore my last comment please.
Comment #39
dieterholvoet commentedI started an MR targeting 11.x with a rebased version of 3323232-29.patch.
Comment #41
dieterholvoet commentedComment #42
graber commentedHere's a re-roll for 10.3 with test changes removed for more simplicity.
Comment #43
graber commentedNo comment.