Refactor isMediaUrl to more generic API that supplies frontend metadata about media entities

This blocks #3246365: [drupalMedia] Show the Image Media's default alt text that is being overridden.

Wonderful progress! :D

Review on the MR.

Having dug into #3245720: [drupalMedia] Support choosing a view mode for <drupal-media>, I now know what additional metadata is needed there: the bundle (i.e. MediaType id) of the embedded media. Because different view modes/displays are available for the content author to choose depending on the bundle.

(This is a relatively new feature in \Drupal\media\Form\EditorMediaDialog for CKEditor 4/other text editors too, see #3097416: When embedding media, don't let authors choose view modes that are not enabled for that media type.)

That could easily happen in that issue after this lands. But … it gives me pause to realize that:

1. HEAD: response returns TRUE or FALSE to indicate whether it is media of the image bundle/media type
2. This MR: response returns
   

   {
     imageMetadata: {
       alt: "blah blah"
     }
   }
   

3. … then I think it'd be far more logical to update this here to return:
   

   {
     type: "image",
     metadata: {
       alt: "blah blah"
     }
   }

   👆 This avoids bundle-specific key-value pairs.

For that reason this MR is following what the current implementation does

Forgot about that :/ So let's clarify this by renaming it to `imageSourceMetadata`?

1. There's no doubt that this is a huge step forward for code organization, understandability and preparedness for the future.
2. I do think that there is still too much nesting of anonymous functions going on, which makes it harder to understand what the different concerns are that are being handled (especially in drupalmediaediting.js). But! This is a pre-existing problem. This is significcant progress. And it blocks a stable blocking issue. Therefore this should not hold up this issue. And … we already have an issue for that: #3248432: [drupalImage] Split DrupalImageEditing into multiple plugins.

So: 🚢

I switched to this branch then added a media item in the editor. The media element toolbar is not available, just this white arrow. I didn't investigate much beyond that, but when I switch back to HEAD there isn't an issue.

• I get the expected element toolbar if I load a node with already present in the field, this is specific to when it is added.
• If switch to source editing and add an alt tag then switch back, the media then has the expected element toolbar

Huh! I definitely did not find that in my manual testing … will try to reproduce. @lauriii, did you ever see this? :O

Reproduced by only looking at the test coverage that @lauriii added.

I don't see the white arrow that @bnjmnm is referring to, but I do see that the ability to override alt for image media was missing in HEAD for freshly inserted media. The fix in https://git.drupalcode.org/project/drupal/-/merge_requests/1787/diffs?co... makes sense too: rather than only handling the fetching of metadata upon upcasting (i.e. for existing media embeds), we now do it also immediately after inserting new media embeds.

Before

After

Setting to NW for visibility on my MR feedback. Most of it is my usual "add too many docs plz" 🙂

All my feedback has been addressed. I'll plan to commit after the commit freeze. In the meantime, patches for 9.3 / 10.0 as needed are welcome!

Looks like a legitimate failure on D10:

1) Drupal\Tests\ckeditor5\Functional\MediaEntityMetadataApiTest::testApi
Exception: Deprecated function: preg_match(): Passing null to parameter #2 ($subject) of type string is deprecated
Drupal\Component\Uuid\Uuid::isValid()() (Line: 28)

+1, RTBC++

Added to 9.4.x / 10.0.x and backported to 9.3.x since CKEditor 5 is experimental.