It also introduces the No Description checkbox that @brianteeman introduced in other places (so basically now it's also available for the images inserted into an editor)

Thanks for doing this.

I am not in favour of the ALT Description and checkbox being hidden behind an obscure button. To satisfy the BC release blocker it must not be hidden and must be located near to the insert image button

Please label the two fields the same as the ones I have created for everything else for consistency

cc @carcam

To satisfy the BC release blocker it must not be hidden and must be located near to the insert image button

Realistically speaking I don't see this happening but let me explain the reason (there are tight constrains here). The container that holds all the fields for the extra data is appended on the fly (it's not part of the media manager, it's a own small app, if you like with a sole purpose to make available the data inserted in those fields from the user). The problem comes that both this container and the media manager (which unfortunately is an iframe) share the same space. If you want to have this always visible you'll end up with two possible scenarios:

• Always pushing the content of the media manager down
• have the additional fields below the media manager

Both are way worse than the detail element.

Edit That said I can open the details on the select event, so it would be the same, from ux point of view

Done the additional data panel will open automatically whenever an image is selected

Thanks - will try to find some time tomorrow to test

I have tested this item ✅ successfully on dd4e239

I like it! It works as advertised. I have some afterthoughts that I will post separately (I need a record because I will revise associated Help screens when this is merged).

Could the Additional Data drop-down be given a border and some padding? It appears in the open state and is not so obviously a drop-down.

If you enter some Additional Data and click the image again the data is lost.

If you insert an image with Additional Data and later select the image to edit the Additional Data is blank. If left blank and saved the figure data is preserved but the image data is replaced - so the img class is lost.

If two images are inserted the second figure block is inserted inside the first figure block:

<figure class="fclass1 float-left mr-3"><img class="iclass1" src="images/sampledata/parks/landscape/120px_rainforest_bluemountainsnsw.jpg" width="120" height="99" loading="lazy" /> 
<figure class="fc2 float-right"><img class="imc1" src="images/sampledata/parks/landscape/180px_ormiston_pound.jpg" alt="Another" width="120" height="90" loading="lazy" />
<figcaption>Another</figcaption>
</figure>
<figcaption>Pretty Place</figcaption>
</figure>

Is that a bug? Or is there a workaround?

They're bugs. You shouldnt have to have a workaround. Please adjust your test results.

If you enter some Additional Data and click the image again the data is lost.

Expected behaviour. The Media manager is different app that communicates with the selector only by events. Re-selecting the same image triggers the event and the image selector resets everything.

If you insert an image with Additional Data and later select the image to edit the Additional Data is blank. If left blank and saved the figure data is preserved but the image data is replaced - so the img class is lost

I think your expectations are wrong here. The workflow for the image XTD button is only for inserting a new image. If you want to edit the inserted image you need to select the image in the tinymce toolbar (I mean the tinyMCE native, own button)

If two images are inserted the second figure block is inserted inside the first figure block:

That is also a problem with all the nested elements. You can do that either with native tinyMCE buttons or the Joomla XTD. Not a limitation or bug. Just make sure that your cursor is in the correct place (eg outside to the previous image)...

Could the Additional Data drop-down be given a border and some padding? It appears in the open state and is not so obviously a drop-down.

As I wrote in the description, this is essentially unstyled. You're welcome to style it as you like either with a PR to this branch or with a another PR once this is merged (if ever)

Thanks for testing

Edit: #31427 might solve the reselection problem If you enter some Additional Data and click the image again the data is lost. (tbh I haven't tried the combo but iirc the other PR will only spit one event per image, thus solving the problem)

I have not tested this item.

Having thought about this some more I am not sure I like it so much. When inserting a second image I did put a space after the first image and before selecting the insert tool - that produced the code I quoted, which is invalid. It seems to me it would be better to have a completely separate way to insert a picture template and let the media manager deal with the img tag alone.

Having thought about this some more I am not sure I like it so much. When inserting a second image I did put a space after the first image and before selecting the insert tool - that produced the code I quoted, which is invalid. It seems to me it would be better to have a completely separate way to insert a picture template and let the media manager deal with the img tag alone.

Please test the same features on J3. Then retry the J4. I'm not reinventing the wheel here...

Just make sure that your cursor is in the correct place (eg outside to the previous image)...

impossible on an article with no existing content - try it and you will see

@carcam please have the accessibility team test this

Please test the same features on J3. Then retry the J4. I'm not reinventing the wheel here...

Confirming the bug is present there as well. So it should be its own issue report and doesnt prevent this being merged

I have tested the alt text stuff and it works as expected - thanks for updating the text as well.

As far as I am concerned it does resolve the release blocker.

Not a huge fan of the way the alt text etc is displayed but as it opens by default it does satisfy my wish for the alt text stuff to be "in your face" - as you said the design etc maybe can be improved but that doesnt prevent this being merged

I am not commenting on the usability of this with a screen reader as to be honest the entire media manager is pretty tricky to use anyway

Confirming the bug is present there as well. So it should be its own issue report and doesnt prevent this being merged

I've just fixed it here by altering something in tinyMCE's config and adding couple contenteditable="" tags. Not sure if this could be back ported in J3, iirc the versions are different so it might not work...

I added an image to an article in J3 - no figure data of course. Saved image, saved article. Select image to edit - the edit form (media manager) opens with all of the previously entered data all present and correct.

In J4 when I select an image to edit the media manager opens without the image selected. If I select the same image then I have to enter all of the metadata again. So I have to remember to to use Insert/Image instead of CMS Content/Image.

I am suggesting we have an Insert/Figure option. And somehow fix the media manager to show the selected image for editing, as in J3. Is that possible?

Added later: just realised I was using JCE rather than TinyMCE for J3. The former does keep img data for editing and the latter does not.

I am suggesting we have an Insert/Figure option. And somehow fix the media manager to show the selected image for editing, as in J3. Is that possible?

@ceford you need to step back a bit and realise what all these CMS Content are doing: they are just inserting data to the editor (tinyMCE, Codemirror, none, or any 3RD party). They're there to just hand in some data (links, img tags, etc) to the editor. Editing the inserted content is down to each editor's capabilities. The button are stateless so it's kinda impossible to, let's say select a menu and then reclicking the button to edit the menu as the buttons don't have this information (stateless)...
Basically what you're asking is something I tried to implement many years ago #7170 but it was rejected as it would have made 2 different experiences (core will be different than any 3rd part extension)

@dgrammatiko thanks for the comments. I think I see what you mean. I have had a look at the TinyMCE documentation on their web site and looked through some of the code. It is a little beyond my experience.

At the moment the data entry form is showing JFIELD_MEDIA_CLASS_LABEL and
JFIELD_MEDIA_FIGURE_CLASS_LABEL.

@ceford should be ok now

I have tested this item ✅ successfully on 84264a4

If you create an image with Figure data, then replace the image but don't fill in the Figure data, then the previous Figure data is preserved. I like that. And I can change the figure class using the code view or the toggle editor view. So that is an easy way of experimenting with layouts. Good to go!

I would like to test the PR by installing it, but I cannot download the complete package.

If you do a test then I will try.

@richard67 @Quy can someone restart drone here?

@dgrammatiko It seems drone has hung up so nobody can access the page to restart it. You can trigger a new run by pushing some changes to your branch, e.g. by updating it to latest 4.0-dev.

Hmm, Drone still doesn't start. I have no idea why. Maybe we just need to be patient, at least I hope so.

@richard67 is it normal that drone doesn't even appear here? @zero-24 any clues?

@dgrammatiko No, it's not normal, and I don't have a clue.

@HLeithner thanks for fixing Drone. Btw can someone add the Release Blocker tag here?

Added "Release Blocker" as inherited from the issue.

Thanks!