Adding alt and title attributes from fields to image markup

Great idea and a good point of matter, but I think you should choose better title and category to get attention from maintainers and users.

And I also choose feature request because I really wonder why such a huge project like media is not covering alt="" and title="" from the beginning by default ...

BTW: Testing your work-around sadly shows still nothing here in image markup with Bartik theme @ testing enviroment with Drupal 7.10-dev. Still had no time to check thru' variables and array items. Just did copy/paste. If I find anything wrong, I let you know.

If there's a better way to do this, let me know :)

I'd like to ask first, if this is the best scenario to have alt="" and title="" stucking on file instead of per node basis. Since many images may get reused, you cannot use individual alt="" and title="" for that other node no more on the same file / image.

What about custom formatters with html and tokens from a custom field of node type? You even can implement colorbox here, but I am not sure if the gallery option will function properly, since you need the count of images in the article for that.

On the other hand you can always create views with own markup, but I am not sure if you can rebuild the inner -img- markup too. Therefore you need the internal file source path, of course.

Let me know what you think ...

I actually think that attaching alt and title tags to the image is not the best solution. It should be attached at each instance that the file is used - the node.

That's what I sad. I don't think that having stuck these attributes only once on images would be best solution, because you can't use the images with other alt="" and title="" values again, what wouldn't be a good thing, because these image attributes often depend also on other things than the image itself, like the topic the are used in for example.

I had a longer chat with DaveReid on IRC yesterday about it and he agreed with me on that it isn't that simple to decide than it may appears from the first look. Since we actually are discussing entities these days, not node types holding images (or any other file), it should be common for all work-arounds to think of node entities and file entities on the same level. And from this point, we should try to look at this both attributes and think from there, where is the best to implement them.

I am not scared to provide patches, even for big contrib packages like media, or for a field which can be injected as attribute like single-line text-field. But before that we need a decision.

I already follow this discussion from the beginning over there: http://drupal.org/node/1291262

I just upgraded to 7.2 release of Media as it was supposed to support Alt and Title. I can't see the UI for that, neither on the upload screen nor in the node editor where the media instance is used. What am I doing wrong? I cleared the cache, to anticipate the suggestion.

As per the discussion where the alt/titles should be stored - I would recommend a cascade rule. Provide default attribute contents for an asset on library basis, when overridden on instance level (string not empty) - display the instance attribute values. Support appropriate tokens on a given level. Enter '' if no alt/title should be used (although I don't see why one would want that.) Support i18n.

Cheers,
Art

@moniuch

There is no features in the module that stores and uses this out of the box yet. It actually quite a few different use cases to consider to get this right, including who should be able to edit those fields for already existing files.

However, if you use the WYSIWYG plugin then you can simply double click embedded images, at least in the CKEditor, and set custom Alt/Title texts for just that embed.

As I want to set alt and title tags like in the image.module I've re-enabled this functionality with this little patch.

It sets this attributes on a per-field_data basis. So it's no substitution for per-file attributes.

Interesting (and working btw) approach, but it doesn't solve this when using the multimedia asset field type where we also should be able to add title and alt descriptions.

Both nice solutions for different use cases. I needed the patch from #6 and it works perfect. Thanks!

Call me n00bie but something is strange to me, so please clarify.

First, I assume that this patch should be applied to latest dev version, however, when I drush dl media-7.x-2.x-dev I get in media.info that version is 7.x-2.0-unstable3.

Patch cannot be applied with patch < 0001-title-and-alt-attributes-for-images.patch it throws this error:

patching file media.fields.inc
Hunk #1 FAILED at 152.
Hunk #2 FAILED at 167.
2 out of 2 hunks FAILED -- saving rejects to file media.fields.inc.rej
patching file media.module

but must also contain -p1 argument so it is like patch -p1 < 0001-title-and-alt-attributes-for-images.patch.

This applies ok.

Even then, I see no title/alt field, neither in node/edit nor in Structure -> ... -> Manage field edit.

What am I doing wrong and how can it be applied to to have title and alt fields in node edit (or where are they supposed to appear?)

Does Insert module then see attributes and fill them or what was satisfying result for you, torotil at #6?

@MacMladen: Yes this is the usual way to format patches with git (that's why the unit tests worked). As you've said it indeed applies to the latest dev version (or rather the latest commit on the 7.x-2.x branch at that time).

As mentioned in my previous comment #6 it just reenables the behavior from the file-widget. With this patch (and the correct field configuration) you're again able to add per-node (as in node/%/edit) alt and title attributes to images. If configured correctly the input-fields appear right below the "Select media" button.

@swentel do you mean the field-type media? If so: it is deprecated anyway, so I won't add support for that.

Sorry, but it looks like yesterday's last commit on branch 7.x-2.x-dev invalidates your patch (concerning the edit button being displayed on a content type's image field, here's the link: http://drupal.org/node/1213252)

patching file includes/media.fields.inc
Hunk #1 FAILED at 152.
Hunk #2 FAILED at 167.
patching file media.module
Hunk #1 FAILED at 454.
Hunk #2 FAILED at 776.
Hunk #3 succeeded at 887 (offset 40 lines).

@Marc-Antoine Dave Reid have been pretty busy committing a lot of new stuff, so its probably just a reroll of the patch that is needed.

I see now why drupal-org.make does not like dev, I think system should include some dev-ID then it would be easier to which dev version we refer to or patch.

However, I tracked down dev version according to date of patch and applied as I said, went fine but I just cannot see how can I configure those fields to appear. It is easy in Image widget, they are on Structure » Content types » Article » Manage fields then on field_image and in operations edit. I've included images with Image widget and Media selector where I miss everything below Maximum upload size field.

If your patch is working I see no reason not to include it as I see it quite vital for overall usability and adoption of Media module, or is there some better solution for this need, like adding that as new fields or making some new entity or field_collection?

Could you maybe post whole your Media patched module for those who have trouble patching or finding right dev version to patch? It would be some 178k and will help a lot, thanks!

It's supposed to give you back two options in the main edit-tab of the field settings (Manage fields -> edit link) to add the title and alt attribute to the node form.

Here is an attempt to reroll the patch.

The #16 patch is not available in the 7.x-2.x-dev tar.gz (161.57 KB) | zip (189.16 KB) 2012-Jan-27, is it?
As I can see no alt/title options in the form Manage Fields > Edit.
Would it be a problem to apply a patch and provide a public download? I tried to set up Git and tried to follow the instructions on how to apply a patch, but I was getting missing includes notice. So I assume the Git way is not for me at the moment.

@torotil: thanks for fast reply but I'd really love if you could take time and look at my images from #15 and comment. As I see it, moniuch also is struggling to have it working and I believe there are many others that would love to jump media boat and never look back but this is obstacle.

I assume your patch from #16 is supposed to work on latest dev from 2012.01.27 so I've done that and got Alt field but there is no title field. Am I the only one, or am I missing something?

I'd repeat and join #17 in plea for torotil to make attachment here of his version.

As insert module is also not working, it seems to me that media module is not ready? I like the idea, I like browser, library and integration, but to be serious we have to have alt and title attributes and I really do not see how to add them using media module, just too long in dev and still not delivering. Also, I'm puzzled as to why other media module are still working only for 1.x branch and are not ready for 2.x?

Oh I've found a small error in my previous patch. So again another one:
This should bring back the title field.

Regarding my version: It is basically the current 7.x-2.x branch with this patch applied. As I am not able to support or maintain my own branch of media (due to limited time/budget) I won't provide one. I hope this patch is accepted and commited to git soon.

Ok I've uploaded the wrong file again. So here another one.

I've investigated the matter a bit more and found that those are omitted by design as explained in #1291262: Add 'alt' and 'title' tokenized text options for image formatters, and a 'title' option for the generic file formatter. While that discussion is lengthy and involves some pretty deep knowledge of Drupal, I'm not sure I can follow.

All I can say is that I see that having alt and title on every node typed as seem appropriate (so it can be different depending on image or any media usage) I really see no point for not embracing this solution as it seems quite natural and media handling is so complicated at the moment in Drupal as it involves many modules and many configuring (modules, plugins, filters, browsers, helpers...) and it is really unspeakable pain to get it working for the end user. I just can't stress enough how important it is to have this module with everything needed to have good user experience with media handling and at same time, have developers happy with controlled and full semantic content entry.

Drupal gods, have mercy on us!

Although I think it would be great to have alt and title content connect to the entity with an option of overriding I just need something like stated #1291262: Add 'alt' and 'title' tokenized text options for image formatters, and a 'title' option for the generic file formatter. I have been bouncing back and forth between the image widget and media selector because of this. The reality is that I want the best of both worlds. Until something better comes along this answers my need. Perhaps baby steps should be taken here - implement (commit) something like the patch in the link so that we have something usable - accessible and even works with other modules like colorbox. When the great minds working on the project have a better solution I am sure it wouldn't be that big of a deal to have an upgrade path.

Love media - alt and title are just deal breakers - thanks to torotil I now have a patch.

This patch seems to be functioning well for me so I have marked it off as reviewed - not sure why simple tests have not been run but I believe it is ready.

There's some odd stuff going on with the pre-rendering so I'm not sure this is quite RTBC.

Dreditor doesn't like the last patch from #21. So I agree with Dave Reid. And all I can say from here now is about to remove the mass of trailing white spaces, since I am not deep enough in the whole issue to reroll the patch with optimized pre-rendering ...

Here is a reroll of the patch removing any trailing whitespace.

Regarding the "non-optimized pre-rendering". I'm not sure what you mean by that.

I've already tried to move the code to media_element_process, so that the input fields are only shown when there actually is a file. But this lead to the fields not being inserted by the JS after selecting a new file. Any pointers on where's the code that handles this case? Any other suggestions on the patch?

Changing status for bots.

I just manually applied this patch to the 1.0-rc3 version and it seems to be working well. I've uploaded my patched files. Please consider back porting.

git clone --branch 7.x-2.x hxxp://git.drupal.org/project/media.git

cd media

wget hxxp://drupal.org/files/0001-title-and-alt-attributes-for-images_3.patch

git apply -v 0001-title-and-alt-attributes-for-images_3.patch
Checking patch includes/media.fields.inc...
Checking patch media.module...
Applied patch includes/media.fields.inc cleanly.
Applied patch media.module cleanly.

After enabling media file selector for image field and activating the checkboxes for title and alt attribute in the field edit forms all works as expected. RTBC from me. Screenshot attached.

We should probably be adding some kind of notice that this information is not used on all formatters? The WTF here which made us hide these fields is that people will fill in alternate text and when they use the 'Rendered file' formatter it will not be visible.

@Dave Reid: We need to make sure alt/title is properly used in all places in the Media module.

Took a quick look at the source code of the #27 patch and found a two things:

• Is it common practice to include 3rd party links in comments in source code? Found one to http://www.gawds.org/show.php?contentid=28 that talks about how to write an alt-text. Not really sure how that is relevant to the code it is a comment too.
• Looking at the screenshot in #30 I believe we need to clarify that the fields will use the HTML attributes "alt" and "title".

Will take a more in-depth look later tonight or tomorrow of this patch, including testing it. Great work so far based on the reports it is working.

We cannot link alternate and title data when we use file_view() or file_view_file() it's impossible (as far as I know) to know how the user has configured a specific view mode and where to put that data. I'm open to ideas if someone does know a way.

We need to make sure alt/title is properly used in all places in the Media module.

Don't barrage me with marshmellows, but to be honest, I don't get the WTF here. And strictly speaking: the upside down situation here is also a WTF now, if you want so. It reminds me of the 300+ issue in core about prevent loosing content by clicking the filter tips info link starting 2006, ending up yesterday with a two lines patch. Finally they all agreed that there won't be an all-embracing solution this time and finally put the simple target="_blank" in it for God's sake. And nobody says that this will be the solution for all times.

And in this case here: As Dave already sad, why not adding an odd description which warns that this alt and title attributes are only shown under certain formatter settings in the moment? Ok, it's not a ninja move. But there are just too many use cases out there needing the alt and title attribute now. Not me, because I don't use media file selector atm. But obviously enough others. And finally I do all say that to wish you all that this issue gets closed ;-)

PS: Ok, I didn' saw the link in the comments, but I agree and think it is not needed. Rerolled patch with removed link and added Notice like suggested by Dave Reid.

oops

Errm ... forgot the screenshot (5:32 in the morning here)

Hot Digidog!

While I think that better integration will be great, I think that this is a first step that should be committed.

I will leave the review process to someone that can be more thorough - but as I said before the patch works in my circumstance.

#34 works great in latest dev. Thanks Digidog.

#34 applies and works for me against latest dev, using the "media file selector" widget for an image field contained in a field collection.

Would be nice to hide these fields if there is no image yet.

Works for me too - thanks oodles! Astounding that this basic functionality has been neglected this far - you rock, Digidog!

The code in #34 is working great for me as well, but the patch failed against 7.x-1.x so here is a reroll for anyone who needs it against 1.x

I also added a note on the slightly related issue #1307054: Accessibility - Media browser image alt and title fields to update their patch to match the field names and descriptions used here.

I see that as of today, April 10th, there's a new dev - the patch works great in delivering the needed functionality (in 2.x-dev) and I'm reluctant to change up.

Will this be incorporated in the 2.x version; should I go to 1.0 and try #41, should I download the latest dev and patch it or should I just stand pat now that everything's working as desired? Thanks much!

Potential solution in File entity: #1553094: Alt and Title support for Images

Arguably it's better to have the flexibility when displaying the alt and title values. Along with token that patch will give full flexibility for those who want user's to handle the title and alt text (or even use one field for it, or the [file:name] token). Please give it a look.

This is related although it may not seem so: could there somehow be added a class to distinguish field so that it can be used to insert media macro into node with fid, title and alt?

There is need for non-wysiwyg editors to have possibility to insert media in text area that is lacking now. I used some sandbox project and it insert fid based on class but I cannot see how to add some class to title and alt form field on node edit so that some selector can be used to select and insert media with alt and title to node?

Or is there some other solution?

Setting this to duplicate of #1553094: Alt and Title support for Images as this needs to be addressed in the File Entity module and not require the Media module to work.

This is just a quick line to anyone confused about how best to add alt and title tags to their media-module image fields; this patch worked great for me with the latest dev release of the media module today and I'm super happy about this (have spent a ton of time reading through media module patch vs file entity patch discussions and trying out all of them.)

Great job guys - thanks digidog.

q./

I applied the patch in 34 to the latest dev version, 7.x-2.0-unstable6+9-dev, and it works some times. I'm using Commerce and adding a product with an image field works and lets me enter alt and title tag. However if I try and create a product display and a product at the same time using the Inline Entity Form module (which basically embeds the add product form into the add product display form) then it flags the alt and title fields as being required and missing if I click the Save Product button in the nested add product form.

So close, so far away, so frustrating! ;-)

Also I noticed that when I click on the Library link in the Media File Selector dialog I don't see any of the previous images I used this widget to upload. Don't know what's going on but I think I'll roll back to the stable version.

@nicholsonma: As explained in #47 this issue is closed. Look at #1553094: Alt and Title support for Images for what we are working on.

I look for a simple implementation of this in 1.x to enable the alt tag to be driven from either a file field or a field on a content type. I can't get the template.php route in #1 to work. Any ideas?

The patch from #41 applies to Media 7.x-1.2. Automatic testing fails because the bot tries to apply the patch to 7.x-2.x (see http://qa.drupal.org/pifr/test/251074).

Can someone port the patch to 7.x-2.x so we can get it fixed first in the dev version? Hopefully we can also get it to apply the the 7.x-1 release. Usually that's the way to get things in and then back-port them. However, some modules do it differently.

Hi Mike,

I'd like this getting fixed but actually disabling alt and title attributes is by design:

// On image fields using the media widget we remove the alt/title fields
http://drupalcode.org/project/media.git/blob/93b4d7134b6da41751ef330a391...

And there's also the general discussion started by Dave Reid at #1291262: Add 'alt' and 'title' tokenized text options for image formatters, and a 'title' option for the generic file formatter whether alt and title information should be part of the image field in the first place:

Having alt and title information as a part of the image field itself is a conceptual failure. Alt and title information is related to display, hence they should be options in a field formatter.

However, IMHO Media module shouldn't mess with the Image field code in this way because choosing a mere widget for the image field shouldn't alter its functionality, especially as there's no alternative solution in sight yet.

For all of us who develop accessible sites there is no such thing as an image-field without an alt attribute. It's "the image" for the visually impaired. Not having an editable title/alt tag per field makes the site broken in that sense - regardless of dreid's opinion.

If the alt and title tag is removed by the media module "by design" this makes the media module "broken by design".

btw, we can change the version to 1.2 and then the test bot will try it on that version.

#41: media_7x_1x-adding_alt_and_title_attribute_fields_to_image_markup-1343022-34.patch queued for re-testing.

@Everett agrees "Agreed that alt and title are contextual, and should be at the field instance."

I don't really care where the code sits as lot as it is easier to have people add in alt text.

I believe this is now fixed in the latest release of File entity (fieldable files) #1553094: Alt and Title support for Images which was what was marked as the duplicate (and master) of this initial thread.

If that's the case then we won't need to re-open this. I think my comment in #53 was too quick. I must have forgotten some of the context of this thread.

@YesCT - I should have reloaded the page before beginning to respond. Sorry. I do believe we can keep this marked as a closed duplicate so not reverting that.

A reroll for the 1.x patch that removes the "Notices" introduced in #34. The warning is meant for site-builders not for end users. We found that it only confuses people.

Rerolling the patch at comment #34.

So, just to be clear:
This is fixed in 7.x-2 (in File entity).
The patch is for 7.x-1.
However, as per the project page, 7.x-1 won't get any new features.
If this patch won't get in please mark this as won't fix.

The patch for 7.x-1.x in #41 working well for me

#41 and other discuss are all for Image. I try to according the same logic to make Title for Video; but won't work.
Because Image's Title and Alt was defined in Image modules, but Video wasn't.

Does anyone could make Media Video Title working?

How is this fixed for 2.x? I don't get the attributes.

Edit: I realized that it is working when inserting media in WYSIWYG. But the images in image fields on nodes and then output using views do not have the attributes. Is this a media, a file_entity or a views issue?

I'm seeing the same for 2.x - can add alt and title but I can't show them in Views or otherwise. This, with respect to the dedicated contributors and maintainers here, should be a base feature of the module(s).

Any guidance as to actually using these fields would be appreciated.

Not only do the alt and title fields not appear in Views, all of the alt and title information previously entered via the Image widget appears not to carry over. Perhaps there should be an option to choose to store the data with the field (like I assume the Image widget does), with the file, or with both. Either way, I hope there will be some way to migrate over data from the image widget.

For now, I'm sticking with the Image widget as that seems to work just fine for my needs.

I ended up using display suite to create a new displays formatter that shows images from media correctly. I'm happy to share this if there's interest. Perhaps it could be turned into a media image formatter to be included with the media module to make alt and title tags usable.

@MJCO - Yes please! A sandbox or just a zip file with the code would be a good start.

EDIT: Sorry I may be mistaken on this, I'll check the site in question and get back to you.

First:

1. In display suite, add a new view mode (I called this Image (Accessible).
2. Under manage file display for Image (Accessible).
3. Uncheck everything apart from Image.
4. In the Alt Attribute box put: [file:field_file_image_alt_text].
5. In the Title Attribute box put: [file:field_file_image_title_text].
6. Set the image style as appropriate.
7. Repeat for any more image styles/view modes.

Then:

1. In your view select the formatter as rendered file.
2. Select your view mode in the box which appears.
3. Save the view and check out your new alt & title tags.

Notes:

• You must have set alt and title tags for your images, you must be using the media module (similar steps may work for core).
• Your alt and title tags should be different to comply with WCAG.
• Enjoy it!

Note that the title tag isn't needed for accessibility. The alt tag is all that is required.

What we also need is following. In Germany we need to put under the image the source of the image if we bought a image or use a image from the web. As source of the image we need to show the autor or/and the url to the image/stock service. It will be nice to have such field.

neofelis1985,

What you're looking for can be accomplished using display suite. It is however completely unrelated to this issue.

Please post a separate issue if you require help with this.

So I'm not sure if with the latest patch from @cbiggins or from the default code if it is possible to require alt text for images. I'd like to see this be something that could be enforced (optionally) in the configs.

Should that be a new issue?

EDIT: Actually you can drop Title & make Alt text required by adjusting settings in admin/structure/file-types/manage/image/fields

I have had nothing but problems with this patch since I've switched to the latest version and re-applied the patch.

Images were not being properly handled (attributes were being lost on save) and they never copied from one node to another when copying the source by hand.

I finally found the problem is that there is a comment added to the media syntax: MEDIA-WRAPPER-START- ... .
By removing the filter and using the img and span a tags everything works properly.
The only issue then is to remove the extra data-file_info attribute on display.
I did this by using php DOM to walk through and strip that attribute.

I left the special media syntax preg_replace in the hook filter in order to not break existing content that is using the [[ ... ]] syntax that does not work so well.

Sticking to html with custom attributes works best for my case.

Attached is a patch that I applied _after_ the patch from number #60.

FYI: I am using ckeditor 3.x.

fixing code example which was missing the array ['und']

This doesn't apply against the git repo.

Is there a way to make this work in the stable version 7.x-1 ?

I don't know what happened to media_filter() or for that matter includes/media.filter.inc or js/media.filter.js

Not sure if this is useful here or not, but I was able to set alt tags this way using [theme]_preprocess_file_entity(&$variables)

function mytheme_preprocess_file_entity(&$variables) {
  if (empty($variables['content']['file']['alt']) {
    $variables['content']['file']['alt'] = 'My alt text goes here';
  }
}

It's a quick workaround until I find something more permanent, but seems to do the trick.

Updated patch from #60.

Whoops, wrong patch paths. Let's try this again.

putting this into 7.x-3.x, as it's a feature request , we can let it bake in there for a few weeks.

fixed in 7.x-3.x

back to 7.x-2.x
needs review
if you cannot wait, then use 7.x-3.x dev release

this patch is in 7.x-3.x .
I'm waiting for feedback on this before putting it into 7.x-2.x

@greenSkin , have you tried the 7.x-3.x release with this commit included?
any feedback?

Whoops, last patch had wrong variable in the default value lines. This fixes those.

I haven't tested in 3.x as we're currently still using the 2.x branch.

An interdiff or a 3.x path would be preferred. As I would eventually cherry pick the commit or merge it from 3.x to 2.x.
This is included in the 7.x-3.0-beta4 release,
It will not go into 7.x-2.x until I get more feedback from those using it in 7.x-3.0-beta4 or unless I actually use it myself.

So back off the commit from comment #88 and replace it with #95?

?

updated 7.x-3.x with the changes between patch 86 and patch 95

FYI: I just tagged a new 7.x-3.x release (7.x-3.0-beta8) that has patch 95.
Please confirm that this works as designed so that I can evaluate this for merging to the 7.x-2.x branch.

Sorry I didn't catch your request for the interdiff, but sounds like you got it squared away.

As is the patch from #95 is working for us with one exception. The image field's alt/title values don't sync back to the file entity on save. When the file entity has an alt or title set, it overrides the image field value when viewing the edit form. Saving the edit form as is would subsequently save the file entity's alt/title into the image field's alt/title, but it doesn't work the other way around.

I presume the focus of this issue is about exposing the file entity's alt/title fields into the form rather than the image field's alt/title. I believe if we can find the best way to update the file's alt/title values from the image field's values on save, we can apply it and ultimately close this ticket. The difficulty I'm facing is finding a way to update a file entity's alt and title fields without relying on using their default field names. Any insight or ideas would be greatly appreciated.

We've been using #95 on the 2.x branch in production with success.

Recent versions of media have resolved most of peoples concerns and is compatible with entity translation, multilingual and various advanced configurations. Due to the high volume of inactive and most often irrelevant issues we are Closing this as (outdated). If for whatever reason this issue is important to you AND you still have issues after checking the media recipe documentation, then let us know and we will review your concerns.

Otherwise, see the recipe documentation for how to configure media and for troubleshooting tips OR refer to the media_dev distribution if you want to see a working media setup.

As mentioned, feel free to make some noise in this issue if you still feel it is important to you or someone else.

Thanks,

Media team

Considering 7.x-2.x has a stable release, It would be good to have the changes backported to 2.x. This would allow the existing sites to upgrade to a stable release and work on upgrading to 3.x (which is still RC)

Patch in #95 still applies to current 7.x-2.x HEAD.

+1 to the previous comment

+1 to implementing Patch #95 to Media 7.x-2.22 release

As version 2.x still considered as "Recommended" I think it's reasonable to say that it should be maintained and this kind of features should be commited and included to the next release.

RTBC +1

fixed in the dev branch dev release, not yet tagged.

I also pushed to 4.x

will let this simmer in dev branches for a while yet before tagging.

if I haven't tagged this by August, ping me and I will tag.

awesome, thanks for the quick response @joseph.olstad!

will let this simmer in dev branches for a while yet before tagging.

if I haven't tagged this by August, ping me and I will tag.

I created #3061455: Plan for Media 7.x-2.23 release to keep track of all issues going in the next 2.x release. Basically, we got two commits so far. once we have release worth of commits, we should go for next release?

Thanks Vijay
Ya a tagged release we could just go with what we have in a couple weeks

I am using core d7.91, media7. X-2.28. In the image list of the media browser, ALT of all < img > elements will not get a value. How to get the alt attribute of the IMG element. Thank you.