Use Media images in Umami demo

@Eli-T

I'm going to mark this as postponed for now, and let's revisit it asap once we get unhidden. I think this will make a great feature (and others are free to work on it in the meantime if they wish).

I am attaching the 'Umami new feature' tag to this item.

I built a first patch based on top of #2939594: Umami missing some Media "plumbing" found in Standard profile

This patch changes the image filed in the article and recipe to a media reference field. It also adjusts the data import to create media entities.

#2939594: Umami missing some Media "plumbing" found in Standard profile landed, so move on here.

Confirming our conversation in Slack. I vote that we remove the link from images and have the cards just display the image. Each card has at least the 'View article'/'View recipe' links and perhaps so many duplicate links on a card to the same location might be irritating to tab through.

So, this new patch does:

• Removing the links from the image
• Fixing the double imported brownie
• Fixing the failing tests

I opened a follow-up for the contextual link issue #2983655: Contextual links are not displayed correctly

Here is the code wrapped in a try/catch

I was surprised there was no image styles or anything removed from umami? Was umami using core shipped stuff or is that still equally needed/used for media given that the images would be one indirection point farther basically but still using those config?

I was curious to see the UX of this as-is now. This is the UX after the patch for the media on a recipe. I did not screenshot the UX before since I did not have a site for that yet.

We created two new view modes for media image, which are using now the already provided image styles from umami.

Hm. I'm *very* torn on this one.

I kind of lean towards postponing this patch until the Media Library + upload UI are both in (at least), or possibly even stable... because unless we do that, we are significantly degrading the UX of one of the major portions of the demo, and the point of the demo is to show people how frigging awesome Drupal is, in order to entice evaluators to start using it. And even if we added the Media Library in here to somewhat soften the blow, it's still vastly easier to use the existing Image UI (at the moment), and that is also what 99% of Drupal sites will use until that new functionality is marked stable. (So kinda feels like a bait-and-switch, "look at this awesome thing... that you can't actually use yet, hahaha!")

However, I am also open to being persuaded. :)

Great work here folks. Really looking forward to this being committed eventually.

I think I'm in the Webchick camp here. That 'Add image' interface is a terrible experience for first time users. What is says is: "we have reusable media, but at first glance you are going to need to remember the name of every media item on your site".

A simple file field is a much easier to understand experience.

To fix this we'd need a contrib module like inline_entity_form, which we obviously can't use or just wait it out like Webchick says until Upload UI is ready (I hadn't realised there was an Upload UI in progress, so that's good news!

I'll leave it at RTBC for now and let others chime in.

Just thinking on this for the past hour, and it's a feature I'd love us to get into Umami asap, I wonder if we change the form display from an autocomplete field to a select list field would that help?

It would still mean that we have to create the media entities on another page (not ideal), but at least when trying to find one, you'd be presented with the list of them within the dropdown. This might not be suitable for a site with loads of images, but on first install, we are only talking about 12 or so images, so is manageable here. Then later when Upload UI is stable, we can switch to using that.

Turns out my suggestion probably isn't good enough - the select list option doens't give the copy around it to say how to create a new media item (I guess since it won't have ajax to automatically pick it up without a screen refresh).

Yeah, multi-select select lists are in most cases an even worse UX than autocomplete, sadly. :\

The two patches in progress to make this whole thing better are #2962525: Create a field widget for the Media library module (select existing media through the Media Library) and #2938116: Allow media to be uploaded with the Media Library field widget (add new media from your hard drive). The second one looks unlikely to make it into 8.6, unfortunately, but the first one is more on the likely side, and that would eliminate the clunky autocomplete widget with a pretty graphical view of existing media to select from. So vastly better than the current UI in #19, but still clunkier than a simple file upload widget for adding new files.

I think there are a few things we need to sort out (and we might want to do so in some other issue):

1) What's the primary goal of Umami? Is it to put our best "Drupal" foot forward? Or is it a "tech demo" of everything core can do?

Personally, I would lean towards the first. Its target audience is new users of Drupal who want to get a decent idea of what Drupal does in a relatively short period of time, and we should sculpt the experience around that target audience.

2) Does it make sense to expose experimental functionality that is not recommended for production use in the demo?

This is a tricky one. There are arguments on both sides. On the one side, experimental functionality is where we're investing efforts in better UI/UX, and that's a big contributor to "best Drupal foot forward." OTOH if as an evaluator I'm trying to get a sense of what using Drupal day-to-day will be like, and I see this awesome Media Library functionality, then go to install my site "for reals" and find out that that's not recommended for production, I will feel mislead and frustrated.

Anyway, this is why my recommendation would be waiting until/unless at least #2962525: Create a field widget for the Media library module makes it in. Then we're introducing an arguably better media experience, at least in terms of selecting from existing media (albeit despite providing an unarguably worse experience for adding new media). In a perfect world, both of those patches would be in, and stable, and then it'd be silly at that point to still be using File/Image widgets. But that's probably 8.7, at best, at this point...

Our general rule has been to use only stable core features, so if the media library is not stable yet, I think we should mark this issue as postponed.

This is at least NR rather than RTBC for #22 on. Whether to postpone it is ultimately a product decision, but postponing it on #2962525: Create a field widget for the Media library module seems like a reasonable choice to me. Thanks!

Here is an updated patch which uses the new media_library.

Question is, do we want to ship umami with an experimental module or do we have to wait until the media library is stable?

At least a good thing about the media library is that it does not provide a data model, so it should get stable relatively fast. IMHO we can get this into 8.7 early in hopes media library gets stable in 8.7.

Looks like this no longer applies to 8.6/8.7. Any chance of a re-rolled patch?

Here's an updated patch that adjusts the config settings that are failing in 8.6.x due to a) content moderation being added and b) the many view mode changes I made for display settings support.

Hopefully I've done this right...

Hi @kjay,

Tested locally,

✔️ Was able to successfully reuse media image in recipe & article contents.
✔️ Also tried creating new content - works perfectly.

[𐄂] I think the following fields also need to be updated to use media fields for block types fields as well.

1. Banner block » Banner image(field_banner_image)
2. Footer promo block » Promo image(field_promo_image)
and subsequently to be updated in InstallHelper::importBlockContent() method.

Am I missing something?
Thanks!!

Nice find @JayKandari

here is an updated patch.

Fixing the config

Here's an issue to address the duplicate tab issue reported in #32: #2992056: [PP-1] The Media library doesn't modify the "media" view if installed in a profile.

The Umami profile could work around this by copy+pasting media_library_install() into demo_umami_install(), or rely on the issue getting fixed by 8.6.

(bad patch, please ignore)

By mistake, the previous patch included all config files.

Uploading a new clear patch.

[WIP]
Recipes are now using field_media instead of field_image.

Todo:
Add a process that adds multilingual images
Currently, images have a language but not related to the corresponding image in the other language.

Fixed previous test error
Enabled media_library module

In addition to enabling media_library, we should also switch Recipes' form display to use Media library (vs. a select list) so we can show it off! :)

Also for some reason, all media items in the library seem to be showing up twice?

Also recommended (not as part of this patch necessarily) to enable Remote video on the field as well, and have one or two examples of YouTube/Vimeo content so we can show off oEmbed.

@webchick thank you for reviewing it and providing the feedback.

This patch was made in a rush, as I thought we could have it for 8.7, but then realized we wouldn't because we'll have to wait for media_library to become stable in core first.

#50 - yes!

#51 - [WIP]
We need to have a process that adds multilingual images.
Currently, there's one image for each language, but they are not connected. (so you see double images) after this process it will work as expected.

#52 - it is already part of the roadmap for 8.8, set as an ambitious goal: #3047414: [META] Out of the box - 8.8 roadmap

[WIP]

This patch replaces all image fields with media_image field and using media_library to select images for nodes.
This patch is still without the needed changes in the content import function, to import media images instead of images.

re #51 it is only a confusing display, not double content in the system. There's a special issue to fix it #3081587: Multilingual content is shown double in the media library view

No interdiff here because the patch from 5 months ago is very different.

#54
Hi shaal i am trying to apply this patch in 8.8 version umami site its not applied getting error please check this patch.
For reference I am adding the screenshot as well.

Hi @jgayathri

I don't know why weren't you able to apply the patch #54.

I attached here the screenshot of a successful patch I tried applying again today:

Hi @shaal patch applied successfully, "This patch replaces all image fields with media_image field" this was not effected for me in content type image field please check. I think so may be i am not understanding clearly what this patch was doing.
I attached screenshot please check.

Hi @jgayathri

From the screenshot you have provided, it seems that the patch was not applied on your machine.
I couldn't find you on Drupal slack (I am @shaal), I'll be happy to guide you through the patch process and make sure it works.

I applied more patches why its not applied i dont know.
Thank you

[WIP]

New in this patch: all recipes' images are imported as media images.

@TODO:
Add to recipe's 'media image' field the reference to the actual media image that was added.
(repeat for all other images used in Umami)

[WIP]

New in this patch: all recipe images are using media images.

@TODO:
(repeat for all other images used in Umami)

[WIP]

New in this patch: all article images are using media images.

@TODO:
(update block_banner and footer_promo to use media images)

[WIP]

New in this patch: -

• Created new view-modes for media image type, according to the (previously regular image's) image styles.
• Added media images configuration to footer promo and block banner

@TODO:
(update CSV of block_banner and footer_promo to use media images)

Tadaaaa.

This patch includes the latest changes needed:

• footer_promo and banner_block now import media image content, and the old image field is deleted
• Template changes required for these blocks
• CSS update

I removed media image's default Name field mapping (to 'skip field), so the Spanish translation of the name of the images will be displayed in Spanish, instead of just the filename.

I found (a bug?) that without using the latest patch from #2992056: [PP-1] The Media library doesn't modify the "media" view if installed in a profile, the media listing page is broken -
only the table listing works, it's not possible to get the grid view, and the menu above displays 'media' twice.

When I apply the patch, the default media listing is grid, and 'media' doesn't appear twice on the menu.

The test failed because image referenced are not found after reinstalling demo_umami_content.
The reason is that the first imported media images are getting the same "ID" as in the CSV, but after uninstall+reinstalling they now get a new, different ID.

We should use the same method we used with saving the actual taxonomy IDs (vs. the original ID from the CSV)

Now media images get the correct Drupal ID, and it is possible to reinstall demo_umami_content.

- Patch applied.
- Every recipe and article has an image. Edit recipe/article, and replace the existing image works. Block footer media image edit/replace the existing image works as well. When replacing images you get the Media Library, where before it was just upload an image right to that field, without the ability to reuse any previously uploaded images. Nothing is broken.
- The mobile/widescreen width looks good.
- Added screenshots.
Marking RTBCed

Does #3081587: Multilingual content is shown double in the media library view still happen?

@Gábor, yes #3081587: Multilingual content is shown double in the media library view is still happening.
According to the conversation thread over there (#17 & #18) it's not a media_library's issue, but an older/deeper Drupal issue when presenting any multilingual content (like a simple Views list of nodes).
I'd love to hear your opinion & ideas on how it should be resolved.

I briefly discussed this, and #2992056: [PP-1] The Media library doesn't modify the "media" view if installed in a profile, with @webchick and @alexpott.

#2992056: [PP-1] The Media library doesn't modify the "media" view if installed in a profile is a very tough (and known) problem, but luckily Umami might be able work around it for the purposes of this patch. I haven't tested this, but according to @alexpott, what needs to happen is:

1. Install Umami, from 8.8.x HEAD.
2. Install Media Library normally.
3. Export the media view, which should be complete and coherent, into Umami's optional config directory.
4. Add the media_library module to Umami's info file.
5. Roll a new patch. :)

The risk is that we run into #2922417: Profile provided configuration entities can have unmeetable dependencies, which would be...trouble.

@phenaproxima thank you for the clear instructions. It worked!!

Note to self: follow instructions in #73 after #3081587: Multilingual content is shown double in the media library view is fixed.

Now /admin/content/media looks good again!

Crediting @alexpott for steering me in the right direction.

In addition to #75, I think the patch should also be updated if #2981105: Media Library should not modify the media view lands first with the instructions of #73.

Just a report that I was testing this as part of testing #3081587: Multilingual content is shown double in the media library view and it worked GREAT! :D

Also spun off a "sister" issue to explore also integrating media with Umami's default WYSIWYG configuration: #3086965: Allow embedding media in CKEditor in Umami

Aw, shoot, spoke too soon; see #3081587-73: Multilingual content is shown double in the media library view.

This might just need some views re-exporting based on the fixes that have gone in in the past ~24 hours.

After #2981105: Media Library should not modify the media view and #3081587: Multilingual content is shown double in the media library view got committed, I re-created views media config export as described in #73

re-rolled #81

Adding the missing 'match_limit' (got lost earlier during the re-roll process...)

Just a heads up that #3082690: Mark Media Library as a stable core module is getting really close, and the patch there makes a ton of changes to Media Library's CSS / markup (moving it to other places in core as appropriate) to ensure better themeability. The flip-side is there might need to be work done on _this_ patch as a result, to ensure Media Library doesn't look overly simplistic and ugly in Umami.

@webchick Thank you for the heads up, I tested #3082690: Mark Media Library as a stable core module together with this patch.

LGTM!

I reviewed patch #88 together with @kjay and @markconroy
We went through the migration process changes and CSV changes (content no longer connects to an image file but to a media reference).

We used https://diffy.website and found 2 differences between current Umami and this patch.
You can download the full Diffy results here:
https://diffy-files.s3.amazonaws.com/2019/10/25/FixUmamisresponsivelayoutstyles2019-10-25-1593.tar.gz

Diffy Screenshots:

Recipes page is missing the hero image:

Homepage has an article view, that is displaying images 3x2 instead of a square (because of a missing view-mode):

I added the hero image that was missing in recipes page.

I added the missing Media-Image's view-mode Square and used the new view-mode inside Recipe's Card Common Alt view-mode.

I fixed test fail
removed from views.view.media.yml the line:
core: 8.x

I removed incorrect description from docblock in installHelper.php

Reviewed during a Google Hangout call yesterday with myself and @kjay and again just now after the issues discovered in that call were solved.

Great work @shaal. Thanks so much.

To the committers, this patch should only be committed _after_ #3082690: Mark Media Library as a stable core module is committed.

+1 for this being RTBC when Media Library is marked stable. Reviewed with @shaal and @markconroy. Media fields are now taking care of the images across nodes and blocks and the media library works as expected for selecting media. Responsive image styles are also setup as previously configured but now via the media display modes. Fantastic work @shaal and it's so exciting to see Media Library happening! :) :)

I tested the Umami demo profile with the new Workspaces module and it worked well until I applied the latest patch here. The hero block placement is breaking in workspaces.

I'll try to find some time to dig deeper into this. But after a quick look at the patch there seems to be things unrelated to Media entities that's changing that might be breaking things (e.g. field weights, Layout Builder stuff, etc.)?

Keeping this as RTBC until I have a patch or more credible proof of that it's actually this patch breaking block placements for Workspaces when used with Umami :)

@dixon_ thank you for the feedback!

Can you please write the steps to replicate the problem you are seeing?

#3082690: Mark Media Library as a stable core module is now stable, so this can now be committed.

I'd really like to get this into beta1, since it's such a huge improvement to the demo experience, so since Media Library is stable, and Workspaces is still beta (and thus not formally supported in Umami yet), and it's been a little over a week since dixon_'s feedback, I'm really hoping that committing this will not cause too much grief to the Workspaces team, and if it does, since Umami is "perma-experimental" hopefully we can get whatever bug fixes we need to sorted out quickly.

Committed and pushed to 9.0.x; 8.9.x; 8.8.x. SO MUCH EXCITEMENT!! Thanks so much for all the excellent work here, folks!

Congratulations everyone!

re: #97, I created a followup ticket for Workspaces core module #3092549: Custom blocks with media are not being displayed

Congrats to the team here for getting this change in, it's awesome! :) We'll follow up in the issue @shaal created on the Workspace related issues. Thanks, and all good! :)

Wohoo for media images in Umami! 🎉