Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Problem/Motivation
When a new Media Type is created over the UI, the source field is automatically created. However, the form shows this field after the "Save" button, which doesn't feel right:
Proposed resolution
Provide better defaults for the form display of media entities when creating a type on the UI.
Remaining tasks
User interface changes
API changes
Data model changes
Comment | File | Size | Author |
---|---|---|---|
#30 | interdiff-26-rerolled-30.txt | 1.55 KB | marcoscano |
#30 | 2934162-30.patch | 7.63 KB | marcoscano |
#26 | interdiff-2934162-21-26.txt | 2.59 KB | phenaproxima |
#26 | 2934162-26.patch | 6.03 KB | phenaproxima |
#21 | interdiff-2934162-19-21.txt | 2.09 KB | phenaproxima |
Comments
Comment #2
BerdirSuprised to see it even below the save button, isn't that supposed to be #weight 99 or something due to being a type actions?
Comment #3
marcoscanoLet's start with the failing test.
Comment #4
marcoscanoIn the end I changed the location of the test, because inside
MediaUiFunctionalTest
the type is created programmatically, so the fix doesn't apply. InsideMediaTypeCreationTest
everything works as expected.Comment #5
marcoscanoBy the way, these are not strictly part of the patch, but I thought it might be a good idea to have inside our test code the best possible example of the method implementations, and IMHO it would be important here to call the base class method, where the fix lives, for instance.
Comment #7
marcoscanoThe fail patch correctly fails.
Comment #8
chr.fritschThis looks really good. Just found one thing:
Could we also verify somehow that the source field is now directly under the name field?
Comment #9
BerdirI usually do that by checking the position of a string in the text, not sure if there is an official way, at least there wasn't in Simpletest.
So basically get the text, then do a strpos for "Name", "File", "Url Alias" or so, and check that the position of Name is lower than that of "File" and so on.
Comment #10
marcoscanoOh that's a neat trick, thanks! :)
Comment #11
BerdirI see what you're trying to do, but the weight is defined as an integer in the schema, so should we really set it to a float here? I think it will be cast to an integer again at some point due to the config schema casting/validation, but that also means it is somewhat unpredictable..
I'd just do a + 1, worst case is that it then has the same weight as the next field, which is still better than right now. Or we explicitly re-set all weights but I think that's overkill.
You also blindly rely on the name component being visible, but we for example have issues tha are discussing to hide it by default (Although, has commented there, I think that's the wrong approach). But better safe than sorry. Check that you have a name component, fall back to -50 or something? If there's no name, it should probably be first..
I don't think this is working as you think it does.
setComponent() doesn't merge, not like that. Especially not the weight, you can see in the method that if there's no weight in the input, it explicitly sets it to the heighest weight. So pretty sure the second call would then unset your weight again.
That means doing this properly either requires you to get the current component configuration, set the weight and set it again or offer someting like a getDefaultComponentWeight($display) method that can be re-used by the child instead of calling the parent.
and this is pretty bogus too, if all we do is remove the component again.
Comment #12
marcoscanoThanks @Berdir!
Comment #13
chr.fritschWhy not calling the parent, getting the component, changing the type and then re-setting the component like @berdir suggested
Comment #14
marcoscanoThanks @chr.fritsch, here we go.
Comment #15
chr.fritschNow re-add the parent::prepareViewDisplay(), then everything should be in place
Comment #16
marcoscanooops, sorry.
Comment #17
chr.fritschNice, +1 for RTBC from me
Comment #18
phenaproximaWe should change array_key_exists() to isset(), to catch null values.
This could get screwed up if any other form appears on the page, for any reason. Can we find the form using a more specific selector?
I'm not sure how else to do this, but asserting the relative positions of text seems quite brittle to me, and prone to things like false positives or false negatives. I'll try to think of an alternate approach to that...
Comment #19
marcoscanoThanks @phenaproxima!
Addressed #18, except for #18.3:
We can always play with css selectors, with something like this:
which works, but IMHO I still prefer the
strpos()
approach though... Any other ideas you can think of?Thanks!
Comment #20
marcoscanoforgot to attach the patch, sorry.
Comment #21
phenaproximaI found a better way to assert the position of the elements! :)
Comment #22
robpowellComment #23
effulgentsia CreditAttribution: effulgentsia at Acquia commentedI think we should also patch
core/profiles/standard/config/optional/core.entity_form_display.media.*.yml
with some hard-coded weight that's not the current value of26
.Are we sure we want to do it this way? The weight of
'name'
is set byMedia::baseFieldDefinitions()
to-5
. The weight of the URL alias field is set bypath_entity_base_field_info()
to30
. That gives us a lot of numbers in between, including0
and-1
. Would it be better to just pick one of those, and thereby leaving some room for contrib to put things in-between? Or alternatively, changing 'name' to -20 and setting the source field to -10, or something along those lines?Comment #24
robpowellComment #25
robpowell@phenaproxima this worked locally for me.
Small-ish comments below.
I don't think this var is named right as this is really the new component's weight. Also, what happens when the condition is False?
This needs a space between namespace and use.
this comment could be more clear "before the test field"
Comment #26
phenaproximaAddressed both @effulgentsia and @robpowell's feedback here...
Done.
Yes, it would! I decided to make the source field's weight name + 5.
Discussed with @robpowell, and renamed the variable to $source_field_weight.
Comment #27
marcoscanoLooks good to me
Comment #28
xjmIn reviewing this I also noticed #2935159: Give default comment fields a heavier weight so they are at the bottom and new fields don't get "lost" , but that happens with any fields, not just Media fields, so it's out of scope for the initiative.
Comment #29
xjmI think we probably also need to change them for the audio and video form displays now?
Comment #30
marcoscanoNot sure if it was strictly needed, because the name and source fields already had weights 0 and 1, but I changed them in any case, just to be consistent with the other types (which have weights -5 and 0, respectively).
Also, needed a reroll.
Comment #31
chr.fritschLets do this.
Comment #32
xjmTesting this patch keeps giving me more issues to file. :)
Comment #34
xjmCommitted and pushed to 8.5.x. Thanks!