Problem/Motivation
When reusing the same image in different places, the alt text of the image might be different for each use. Since images could contain a lot of elements, you might want to describe different parts of the image depending on the context of how the image is used. It is currently not possible to override the canonical alt text of a media image on a per use basis. (Similarly, different tags might be needed depending on where it is used.)
As the WCAG makes a distinction between:
- Informative Images - where the text alternative should convey the meaning or content that is displayed visually
- Decorative Images - where a null (empty) alt text should be provided (alt="")
This is also discussed in #3081475: According to the WCAG guidelines decorative images should not have an alt-text but this is not possible
Proposed resolution
Add an map field to the media entity reference to store the field overrides. Note the override is per fieldand not per field_property.
Remaining tasks
Add more doxygen to the media item class, especially around the per field vs per property override.
User interface changes
API changes
Data model changes
Release notes snippet
Comment | File | Size | Author |
---|---|---|---|
#72 | interdiff_3023807_69-72.txt | 1.53 KB | ankithashetty |
#72 | 3023807-72.patch | 79.53 KB | ankithashetty |
#69 | 3023807-9.2.x-69.patch | 79.96 KB | alexpott |
#69 | 67-69-interdiff.txt | 3.16 KB | alexpott |
#67 | 3023807_67.patch | 79.22 KB | anmolgoyal74 |
Comments
Comment #3
a.milkovskyDo you mean to extend the entity reference field a few more sub-fields? As a workaround, we can use an additional entity for that.
Comment #4
seanBDo you mean to extend the entity reference field a few more sub-fields? As a workaround, we can use an additional entity for that.
We have not yet decided the best way to do this. A couple of ways I see currently:
All of these approaches are not perfect, so we have to choose which one is the lesser of all the evils. I would love to get some input on why we should definitely NOT choose the approaches above (I think that is the quickest way to find out which is the lesser evil). There must also be other ways, so I would love to get more input on that as well.
Comment #5
a.milkovskySome small feedbaack from me:
We should think about use-cases where this solution will be needed. Currently I am thinking about:
1:As you said, we should not "not mess with existing entity reference fields.". That's why I like 2 and 3 more.
2: "A field that allows data to be added to the references" makes sense.
FYI there is a similar module for Drupal 7 Relation, it might contain interesting solutions.
But the existing Entity reference field has an own small eco-system already because it is supported by many other modules (E.g. Inline Entity Form).
If we build a new field type people will have to build some custom integrations for the new field type as well.
3: New entity sounds more interesting, seamless and native to Drupal. In this case we can easier integrate it with existing media modules like Embed, Entity Browser. I think revisions should, we can have a look what Paragraphs are doing, they are using Entity Reference Revisions field.
Comment #6
weseze CreditAttribution: weseze as a volunteer commentedI'm curious as to how this problem can be "solved" currently?
Since Drupal 8.7 now ships with media in core and a fantastic widget "Media library" I assumed it would be possible to use this. But not being able to set an alt tag on an image specific as to where it is used, is just a showstopper for us. None of my coworkers working with the customer, with the content and optimising for SEO find this acceptable. For them this solution is "broken".
We are currently still using file_entity module and plain image fields to set these things up.
How can we get around this as of now (Drupal 8.7 with media library) Which contribs do we need, which field setups for images?
I would imagine that at the technical level we would need an entity_reference field that can store additional meta data? Does such a thing already exist? Would this be the path forward for Drupal core? Or should it remain in contrib?
Comment #7
Wim LeersThis not yet being solved for Media entity reference fields makes it much harder for the WYSIWYG equivalent over at #2994702: Allow editors to alter embed-specific metadata, as well as `data-align` and `data-caption` to solve this.
I don't yet understand why #2834729: [META] Roadmap to stabilize Media Library lists per-use metadata as a MUST-HAVE for WYSIWYG uses and a SHOULD-HAVE for entity reference uses.
Comment #8
andrewmacpherson CreditAttribution: andrewmacpherson as a volunteer commentedRe #7 - We discussed must-have vs. should-have for the per-use metadata in comments 8-10 at #2994702-8: Allow editors to alter embed-specific metadata, as well as `data-align` and `data-caption`. The points there apply equally to this one. I'm happy to treat both issues as a11y should-haves for the media library stabilization roadmap.
Setting priority as major, to reflect the awesome-sauce impact it will for authors and our ATAG coverage.
Comment #9
phenaproximaThis was discussed at Dev Days Cluj between @alexpott, @amateescu, @seanB, @Wim Leers, and myself. I'm pleased to report that we hatched a plan to address this.
We are going to create a new field type, called 'media', which will be similar to the 'file' and 'image' field types in that it will extend the base entity reference field type with an additional property. That additional property will be of the Map data type, to store a simple set of key/value pairs: the name of the metadata property to override, such as 'alt', and the override value itself.
This means that there will be an update path which will convert all existing media reference fields to this new type. According to @amateescu, this is feasible, although it does involve changing the type of an existing field, which is not quite ultra-kosher...but doable, and the best option we have at our disposal to accomplish this task. The dangers of the update path are significantly mitigated by the fact that we will be adding a database column to existing fields, but not migrating or changing existing data in any way. The only thing that is a bit questionable is the fact that we are changing a field type, but @amateescu does not believe this will pose a problem. In our discussion, @alexpott agreed with that assessment.
So much, then, for the data layer.
In considering the UI of this, @seanB and I drew up some sketches on paper -- of which we will soon post pictures -- with @ckrina (UX maintainer) and @Gábor Hojtsy (product manager) present to validate our ideas. We also presented the sketches to the UX team (including @webchick and Gábor) on the weekly hangout to get wider feedback. Generally, it was very well received and we reached a consensus (!) on most of the proposed UX.
The overall idea is that, when you have added media items to the field via the media library widget, you will see the grid of thumbnails of the chosen items, as you do now -- and each one will have two small icons attached: one to remove the item from the set (as we have now), and one which will open a modal that allows you to override particular metadata values. Exactly which values can be overridden is something that will be left up to the media source plugin. (For example, the Image plugin will allow overriding the alt and title text; the Remote Video plugin, by contrast, may allow one to override the default thumbnail.)
Each overriddeable value will follow what we termed the "machine name pattern", in that the default value will be displayed as a label, with a link or button that says "Edit" (or "Override" -- the jargon is not fleshed out yet) next to it. When you click that button, the value will be instantly displayed in a form field instead, allowing you to change it, and the Edit/Override button will disappear and be replaced by a "Restore default" (or "Revert" or something...again, don't worry about terminology yet) button that, if clicked, will disappear the form field and display the original value as text.
So, this means that:
The WYSIWYG variant of the media library will follow the same overall workflow. First, you choose an item from the media library, and it is instantly embedded in the editor with default metadata. There is an additional button to click if you want to override that metadata, and it calls up a similar modal window that works in just the same way.
Comment #10
seanBHere is a link to the usability meeting where the designs were discussed: https://www.youtube.com/watch?v=MwNa2nNCQr0
Comment #11
Wim LeersCan we still add photos or scans to this issue of the paper sketches? 😊
Comment #12
seanBI took some pictures as promised :)
ER widget proposal:
WYSIWYG proposal:
Override metadata modal proposal:
Also made a proposal on what the image with the buttons could look like:
Comment #13
Wim LeersThe screenshot of a hacky mock-up at the bottom of #12 is becoming reality: see #3039829-35: Remove link to media item from media library view.!
Comment #14
chr.fritschI think #2568289: Not possible to reuse field formatters between entity_reference, file, and image fields is highly related if not a blocker for this. Because when we introduce a new field type "media", we are not able to use the "Rendered entity" formatter anymore.
Comment #15
chr.fritschPosting my first WIP patch. This patch adds a new field type "media" and an update path to switch to that type for existing media entity reference fields.
Comment #16
chr.fritschOk, #2568289: Not possible to reuse field formatters between entity_reference, file, and image fields is not a blocker for us. I thought it's about making entity_reference formatters dynamically available on entity_reference sub field types but we want to stick with the opt-in behavior. So we can make the entity reference formatters available for the media field type with hook_field_formatter_info_alter().
Comment #17
chr.fritschA lot more changes. The good thing about the new field type is, we can remove some hacky code :)
So let's see how many tests will fail.
Comment #18
johnwebdev CreditAttribution: johnwebdev commentedHaven't really looked at the patch yet; though I'm wondering about:
do entities have any read-only mode to ensure that the entity is not saved with the overrides?
Comment #20
phenaproximaI discussed this on Wednesday with @daniel.bosen, @chr.fritsch, @seanB, and @amateescu.
We were leaning towards making this into a meta-issue, since there are at least two very clear things we need to do in order to implement this feature.
First, we need to create the new "media" field type and its update path, plus API additions in the media system to allow source plugins and media types to define which pieces of metadata are overridable at the per-reference level. To do this, we're thinking we should leverage the Typed Data system, since this would allow us to integrate cleanly with the entity field system and JSON:API. Media sources will get a new method allowing them to expose their overridable metadata (and/or certain configurable fields on the media type) as typed data definitions, kinda like so:
The "media" field type plugin will be responsible for using this information to actually apply the overridden values to referenced media items.
We're hoping that using Typed Data will smooth out the integration with JSON:API, but we're still not entirely sure how we want to expose the overridden data to it. This will also give contrib and custom code an extension point, and hopefully make it easier to create/modify the form where overridden values are set.
After that, we need to implement the actual UI outlined in #12 in the existing media_library field widget.
Comment #21
Wim LeersI like #20 :)
So #17 includes a
overwritten_property_map
field. I think the intent here is thatgetOverridablePropertyDefinitions()
specifies which keys are allowed to exist (and their corresponding values), for the media source associated with this media field. Is that correct?JSON:API (or REST or GraphQL) will not be calling
MediaSourceInterface::getOverridablePropertyDefinitions()
, they will simply normalize what is stored inoverwritten_property_map
for reads and a corresponding validation constraint will ensure that during writes only properties returned by that method will be allowed to be written. Meaning that none of them need to change a single line of code as long as this is implemented inMediaItem
and includes a validation constraint.Comment #22
Ghost of Drupal PastApparently a lot more is possible here than just overriding the alt text.
Comment #23
Ghost of Drupal PastLet me take a stab at it. Also, do we want to do field properties instead of whole fields? Right now:
and that means you can only override the entire image field including target_id et al and overriding just alt is not possible.
Comment #24
Wim LeersThanks for updating the title and issue summary, @Charlie ChX Negyesi! The issue summary had indeed not yet been updated for #9.
Comment #25
chr.fritschOk, here is what I have so far.
I introduced a new "read-only" wrapper entity around the media entity; the new media field type returns that. It passes most of the method calls to the original media entity but prevents saving.
I tried to implement @phenaproxima's proposal about the
MediaSourceInterface::getOverridablePropertyDefinitions()
, but I really don't know how that could work.So what I did, is the following. The MediaType can now return an array of allowed property overwrites in
MediaType::getOverridableProperties()
. Additionally the new field type got a constraint validatorOverwrittenMetadata
. This validator checks which properties are allowed to overwrite and then checks the overwritten values against the typed data of the original fields.Note, the MediaReference widget can be ignored. It is just to set some values and make testing, especially of the validator more comfortable. The media library will take over that in the future.
Comment #27
chr.fritschSo I had to implement the MediaInterface for the ReadOnlyMedia entity because other parts of Drupal expect that. That meant, that I had to implement every single method of that interface and it's parent interfaces. not nice, but I don't see another option.
Comment #29
alexpottDoes this need to be be in the reserved entity namespace. It doesn't have an entity annotation.
Should be a RuntimeException.
I'm not sure this should work. I think the overwritten properties should only be settable on construction.
Should we ensure that we only override existing properties?
So this code result in the original actually changing - this seems a bit dangerous.
I'm not sure these should work.
This creates a Media item... seems interesting behaviour.
Having setters that work on an object called ReadOnly seems odd.
I think it would be better if this was
return $this->media->toArray();
instead. Same in all the other places.It would be good to assert that the file itself is not overridden.
Comment #30
chr.fritschThx @alexpott for a first review. I adjusted most of our remarks.
Regarding #29.4:
I think we already check that in the OverwrittenMetadataConstraintValidator. Or do you think about something else?
Comment #31
chr.fritschHere is the interdiff..
Comment #33
chr.fritschFixing a test that was introduced in #3055516: Notice: Undefined index: target_bundles when new reference media field created
Comment #34
alexpottThis should be prevented on read only entities.
I think this should throw an exception too. Not sure why we need them. Tricky.
If you can't load these - I think is not necessary either.
This doesn't create a duplicate. Probably should be prevented. Not 100% sure.
This one is interesting. Should this return the overridden values?
Nothing should change right?
Not sure these should be allowed on a read only entity. Again not 100% sure at all.
Feels like this should be prevented.
As a preSave hook - probably should throw an exception.
This is not part of read-only ness. However thinking about this does make me wonder about translations and how we plan to handle that. We definitely need multi-lingual test coverage.
Comment #35
chr.fritschSo again preventing more stuff and I also added a test for the validator and for translation support.
Comment #36
amateescu CreditAttribution: amateescu for Pfizer, Inc. commentedThe patch looks really good to me, I like that we're able to simplify a lot of code because we don't need to check for the entity reference field type anymore :)
Here's my initial review:
How about "Change entity reference fields targeting media to use the 'media' field type."?
This update function only covers configurable fields, we need to take care of base fields as well, which might be stored in the shared tables or in dedicated ones if their cardinality is higher than 1.
Also, the database schema updates rely on the table structure defined by core's default SQL content entity storage, so we need to bail out if the entity type that contain these entity reference fields does not use
SqlContentEntityStorage
.The default widget for the new
media
field type isentity_reference_autocomplete
but we are also adding a new media-specific widget below. Why don't we use that as the default widget?I don't think we should hardcode a configurable field shipped by the Standard profile in here.
Also, I'm not sure what's the purpose of this code and why we need a new widget just for it...
This should be marked as @internal in case we decide to generalize the concept of read only entities.
Is there a reason we're restricting the overwritten properties to just a single (first) value of a field type?
Why do we mention migrations here? Shouldn't this use the same "It's not allowed ..." message as above?
The typed data object returned by this method won't contain the overrides, which means it will be inconsistent with the actual values of the read-only media and it's very likely to cause subtle and hard to track bugs down the line..
Same here :/
Shouldn't we throw an exception here?
Is this empty interface really needed?
It doesn't seem like it fails :)
Can we also add these assertions before saving the entity? We need to ensure that changing
overwritten_property_map
has an "instant" effect on theentity
property of the media reference field."by an media" -> "by a media" :)
Comment #37
joseph.olstadThere appears to be a contrib module that provides this:
https://www.drupal.org/project/file_management
#3081475: According to the WCAG guidelines decorative images should not have an alt-text but this is not possible
Comment #38
geek-merlinThis may have synergies with the preview-in-editor use case.
Comment #39
bnjmnmRebase of #35. Keeping this at Needs Work since the feedback in #36 still needs to be addressed.
Comment #40
chr.fritschAddressing #36:
1. Done
2. Do we have any example for that? Base fields are defined in code. How to change that?
3. + 4.. That widget was only for testing purposes. It will not be in the final patch.
5. Done
6. You are right. Fixed that and added a test for that.
7. Done
8. Fixed that and added a test for that.
9. Fixed that and added a test for that.
10. Done
11. When I added the interfaces directly to the ReadOnlyMedia class I got
Class Drupal\media\ReadOnlyMedia must implement interface Traversable as part of either Iterator or IteratorAggregate
. With the ReadOnlyMediaInterface it's fine.12. Copy/paste leftover...
13. Done
14. Done
Also fixed the ContentModerationTest test.
Comment #43
alexpottWe're adding a method to an interface to a stable module. I think this is okay in a minor under the 1 to 1 rule as this is implemented only by \Drupal\media\Entity\MediaType and that's really the only implementation we expect.
We're adding a method to an interface to a stable module. I think this is okay in a minor under the 1 to 1 rule as this is implemented by \Drupal\media\MediaSourceBase and that's really what we supporting extending.
I'm not sure why this is here. Needs a comment. It seems to be assuming there will be an alt tag.
This doesn't need to be here.
Too much space
Let's add some docs also formatting of the commas.
Doolittle (then PHPStorm won't complain about spelling :D)
----------------------------------------------------------------------
FOUND 6 ERRORS AFFECTING 4 LINES
----------------------------------------------------------------------
1 | ERROR | [x] The PHP open tag must be followed by exactly one
| | blank line
2 | ERROR | [x] Namespaced classes, interfaces and traits should
| | not begin with a file doc comment
7 | ERROR | [x] There must be one blank line after the namespace
| | declaration
12 | ERROR | [x] Expected 0 spaces between "MediaInterface" and
| | comma; 1 found
12 | ERROR | [x] Expected one space after the comma, 0 found
12 | ERROR | [x] Expected 1 space before "IteratorAggregate"; 0
| | found
----------------------------------------------------------------------
PHPCBF CAN FIX THE 6 MARKED SNIFF VIOLATIONS AUTOMATICALLY
----------------------------------------------------------------------
Comment #44
alexpottGood progress here. However there seem to be some rough edges.
Warning: Invalid argument supplied for foreach() in Drupal\media\Plugin\Validation\Constraint\OverwrittenMetadataConstraintValidator->validate() (line 53 of core/modules/media/src/Plugin/Validation/Constraint/OverwrittenMetadataConstraintValidator.php).
Comment #45
chr.fritschThanks again for reviewing, @alexpott!
I fixed all the comments from #43 and #44.
Comment #46
alexpottDo we need a new testcase for #44 or was that covered by the fails in #40?
Comment #48
Wim LeersGlad to see this making progress! 👍
Comment #49
oknateReroll. The MediaLibraryTest file wasn't applying. All the rest works, even with #3082690: Mark Media Library as a stable core module applied.
Comment #50
oknateAll through the patch I'm seeing the word 'overwritten' while the issue title says 'Override'. When talking about field values, I would think overwrite is more for writing to the database and override is more for overriding it in other contexts. I think we might want to change the wording of this in variables, classnames, etc. added by this patch to be "OverriddenMetadata", "overridden_property_map", "OverriddenMetadataConstraint", allowed to be overridden", etc.
I suggest we replace 'overwrite' with 'override' and 'overwritten' with 'overridden'.
Update:
Now that I think about it, it is writing it. It's writing it at the field level. So it's both overridding the original written data (on the original media field) and writing it at the reference field level. So in this way, I'm contradicting myself, and I think now 'Overwrite' and "overwritten' are appropriate.
Comment #52
oknateFixing tests. For this one, I'm not sure why but it was evaluating true here:
if (empty($value->overwritten_property_map))
.I fixed it this way, although, it'd probably be better to fix the Mock object.
Comment #53
oknateWhat are the next steps here? Do we need to add a UI to update this within this issue? Or should that be in another issue?
Comment #54
chr.fritschRe #53: I wouldn't add the UI in this issue. It's already quite huge. Better do it separately.
Comment #55
Belshi CreditAttribution: Belshi commentedReally glad to see progress here, but since my lack of skill doing it by myself I have to ask: Is there any chance to get this working in current Drupal stable release?
Comment #56
phenaproximaUnfortunately not, due to the deadlines in core development. Once a beta has been released, there is almost zero chance of getting new features (and this counts as a new feature) into the forthcoming stable release. Since the next feature release is (as far as I know) 9.1.x, this feature will be targeted for 9.1.0, I think.
Comment #58
johnwebdev CreditAttribution: johnwebdev commentedComment #59
vsujeetkumar CreditAttribution: vsujeetkumar at Srijan | A Material+ Company for Drupal India Association commentedRe-roll patch created, Please review
Comment #61
Berdirdrive-by-review, without reading up on the issue in depth. And sorry for that, but this is super complex with a lot of cases that haven't really been throught through I fear.
This looks super, super scary to me. We never had a field schema change API because it is very complex, with a change like this, any claim of supporting pluggable entity storage is out of the window, we should at least make sure we only do it for the default storage.
Also, this is going be a breaking change for custom formatters, widgets and custom code that checks for the entity reference field type.
It would also not work on non-configurable fields.
And because that's not enough fun yet, here are some other fun things that this might break:
* multilingual: usually entity reference fields are untranslatable, but if you would want to translate alt/title/description or whatever. We could use the column grouping stuff that we have on image field.
* normalization/API-first, we'd need to make sure to have normalizers and stuff in place to support that new field type
* the field type only seems to override __get(), that wouldn't work for more generic code that works through properties, would need to happen lower on the property level
* Render caching. The overridden entity would end up being cached the same way for multiple usages. we'd need to disable that/include the information from the parent.
* This seems to include several changes that would break existing regular entity reference fields pointing to media, like no longer supporting that field type for formatters and so on. Also removing the common target breaks tests as visible here with the necessary changes.
To be honest, I'd strongly suggest to not enforce this change and make this available as a separate, optional field type. Possibly experimental, considering all the complexity mentioned above and that's just what I could think of right now. If we want we could offer the conversion as a manual operation that people can trigger, maybe even in a contrib module.
In fact, the whole thing seems like something that should maybe mature in contrib first? I get that it is a common use case but not everything can be in core. But it's easier to say in contrib that this first version doesn't support multilingual/normalization or whatever yet.
you would be able to bypass this easily with $storage->save($media)
Comment #62
stomusicFin for fields without revision table
Comment #63
stomusicReroll
Comment #64
phenaproximaComment #66
dejan0 CreditAttribution: dejan0 at acolono GmbH commentedWe needed the solution for `entity_reference_media` and the Caption field so we created a small contrib module.
https://www.drupal.org/project/entity_reference_media - just in case someone needs it
Comment #67
anmolgoyal74 CreditAttribution: anmolgoyal74 at OpenSense Labs for DrupalFit commentedFixed self-deprecation notices.
1) Declaring ::setUp without a void return typehint
2) $modules property must be declared protected
Comment #69
alexpottFixing the test and coding standards issues.
Comment #70
alexpottWe need to change this number to be 9200.
We need to account for a tricky situation. We need to cope with what happens when a module is providing a media field. I think we should implement a field storage and field config pre save hook to fix the data. They should also emit deprecation errors.
We could change the update functions to only detect what fields need fixing and trigger a save so we don't have to duplicate code.
This is not inheriting any documentation.
Should be
Implements the magic method for getting object properties.
These methods no longer exist in D9 and can be removed.
Comment #71
alexpottWe also need an update path test for the update hook.
Comment #72
ankithashettyUpdated the patch in #69 addressing #70.1, #70.3 and #70.4. Kindly review.
Thank you!
Comment #73
phenaproximaJust got off the phone with @chr.fritsch and @alexpott to discuss this dragon of an issue.
@Berdir's points in #61 are valid, and he's right that this poses some very scary technical challenges from a runtime, operational standpoint. To quote (emphasis mine):
Personally, I'm far less worried about the update path than I am about these questions. The update path would probably work well enough, considering how much badass brain power we could throw it it. But we don't know how well this would work day-to-day for authors and editors, and what kind of technical problems (up to and including data loss) might result from those unknowns. So this still feels extremely risky.
Nonetheless, we need this feature. It's important not just for accessibility, but also for content strategy. So I see two possible paths right now, both of which are longer-term projects:
I think I'm partial to the first option, mostly because contrib is not bound by the core processes and gates and can therefore iterate faster. But I'm certainly amenable to the second option too, precisely because of core development's high quality standards.
The one thing I think we shouldn't do is put this functionality directly into stable core modules and enforce it with an update path.
Thoughts?
Comment #74
John Pitcairn CreditAttribution: John Pitcairn commentedMy 2c worth - yes, contrib.
Comment #75
marcoscano+1 for contrib, opt-in.
Comment #76
johnwebdev CreditAttribution: johnwebdev commentedI also think that moving the effort to contrib would make sense, Berdir's point are very compelling and highlights some complexity that needs to be addressed. I'm wondering if by doing that it also makes sense to still target the use case of media rather than solving it generically? Faster progression perhaps.
Comment #78
chr.fritschThe last couple of weeks, the Thunder team (mainly @alexpott and me) were working on a solution for this in contrib. So we came up with https://www.drupal.org/project/media_library_media_modify.
The module provides a new field type, that extends entity_reference and an extended media library widget. The modifications that can be made to the referenced media items, are stored in the field, next to the target_id. The referenced media items will never be changed. All the modifications only exist in the context of the referencing entity.
The fields, that are allowed to be edited, can be defined with a form mode. So we also have the flexibility to define in which widget these fields should be rendered.
Theoretically, the new field type can hold any entity type as a reference. We currently limited it to only work with media, because we only have a nice working widget for media.
We also provide a drush command, to migrate existing entity reference fields, to the new field type.
Comment #79
joachim CreditAttribution: joachim at Factorial GmbH commentedI had a try of https://www.drupal.org/project/media_library_media_modify.
I really like the edit button that shows in the media library widget on the host entity's edit form. Very nice and clean UI!
But I wonder if this pop-up is going to clash with the need to edit media entities in a modal: #2985168: [PP-1] Allow media items to be edited in a modal when using the field widget.
Also, I'm wondering why the overwritten_property_map field column uses big text format rather than the map data type. Is that because of issues with the map type?
Filed some issues over at that module. I seem to be a magnet for bugs, sorry! :/
Comment #80
joseph.olstad@joachim, I also tried that module, it conflicted with 2985168, seemed to mess up the configuration too.
For now I'm going with
#2985168-106: [PP-1] Allow media items to be edited in a modal when using the field widget
Comment #81
joachim CreditAttribution: joachim at Factorial GmbH commentedThis should be postponed for the same reason as #2985168: [PP-1] Allow media items to be edited in a modal when using the field widget.
Comment #83
joachim CreditAttribution: joachim at Factorial GmbH commentedComment #87
Martijn de WitAdded some extra context into the issue summary regarding WCAG specs