Allow setting a default value for Alt and Title text in image fields

[klonos]

This is basically the same issue as https://www.drupal.org/node/807126 that was filed against the D6 branch of ImageField. That issue was closed as "fixed" by @quicksketch by pointing to the ImageField Tokens module:

Now with Tokens in core, it makes sense to take advantage of them and use them where possible.

PS: should support transliteration once in core (#904)

---

PR by @BWPanda: https://github.com/backdrop/backdrop/pull/3068

[klonos]

...the UI shouldn't be as complicated in Backdrop with the token browser opening in a separate dialog and we can leave the synchronization between alt and title and the "Update every edit" checkbox in the screenshot above for contrib if you think it's too much. ...though I personally think they are very useful features. Hidden in an "advanced" fieldset that's collapsed by default perhaps?

[klonos]

...while this issue here is about adding support for tokens to be used in the "Default value" field of the alt and title properties, I also filed the related #1440 that would expose the alt and title fields as tokens themselves so that they can be used elsewhere.

[ghost]

I'd love to see this as a feature in core. So annoying not being able to specify a default/token value for 'alt' and 'title' fields...

[webmetod]

+1. Alt is a required attribute, but writing it with hands every time, especially when a lot of work, is a mockery.

[ghost]

Here's a basic PR: https://github.com/backdrop/backdrop/pull/3068

I don't think the synchronise options are needed (perhaps contrib?) and as for the 'update every edit' options, isn't that how token work in general...?

[ghost]

PR updated to fix indentation.

[ghost]

Few more updates and now tests are passing!

[klonos]

Thanks @BWPanda ...code looks good, and I have also tested in the PR sandbox. Works as advertised 👍

PS: I didn't wanna delay this feature, so I have filed a separate issue for a generic UX problem related to the way the token browser works: #4316

[klonos]

@BWPanda wondering if you would wanna make the effort to implement something similar to https://github.com/backdrop/backdrop/pull/1463/files for the "Browse available tokens" links for the alt and title fields. ...or wait till we solve this in a "global" way in #4316.

[ghost]

@klonos I like the idea, but I think a global fix is better than individual ones... Thanks for the review!

[quicksketch]

The terminology and functionality is confusing to me. Taking a look at @BWPanda's screenshot:

These aren't default values. When you're creating a piece of content, the body field might not even be filled out yet, so how would it be used as the default after uploading an image? I expect the default to populate the field when editing. What this actually does though is provide a value if the field was left blank.

The only other field that does this that I know of is Image Fields. Though I think that is both a more complicated situation and the word "default" isn't right in that situation either.

I'm also not 100% sure this is really a good idea in the first place. Sure you're making it so the alt and title have values, but bad values could be worse than none at all. I'm ambivalent whether this should be out-of-box functionality.

[ghost]

@quicksketch They are default values, since whatever you enter in the configuration form for an image field, is what appears by default in the entity form when uploading an image:

Image field configuration:

Entity form:

So you can either set a hard-coded value as the default, or you can set a token that'll (most likely) use a value from the entity itself (or you can leave the default value fields empty and keep Backdrop's OOTB functionality). As with all other token-enabled fields, tokens are substituted only when viewing the entity, so you have to save first, then view to see the tokens replaced:

I'm also not 100% sure this is really a good idea in the first place. Sure you're making it so the alt and title have values, but bad values could be worse than none at all. I'm ambivalent whether this should be out-of-box functionality.

The only out-of-the-box functionality is the ability to set default values for Alt and Title fields. We don't provide those defaults (maybe my screenshot was confusing in that regard). Here's how a brand-new image field looks after enabling Alt and Title text:

Before this PR, the OOTB functionality was that you'd enable Alt and/or Title text, then you'd go to the entity form and have to enter values manually. With this PR, the OOTB functionality is the same, since the default value fields are empty to start with. Only if you set default values will you get this ability to upload an image on the entity form and then Save without needing to manually enter Alt/Title text each time.

I hope that explains it better...

[quicksketch]

Oh... I see. I thought that the token would get populated immediately after the file was uploaded. But instead this is allowing a content creator to use a token while also providing default values (whether tokens or hard-coded) for alt and title. Hmm.

I think of tokens as a necessary requirement for site builders (e.g. path aliases) but something that is rarely passed along to content creators. I found we do support tokens in Link URLs when that module was ported wholesale into core. We don't support tokens in any other fields that I'm aware of (text, date, number, options, etc).

Implementation looks good to me. However we do still need test coverage that the tokens get replaced as expected, so I'm moving to needs work.

Considerations of how it works aside, I think this is likely to result in poor alt text because it may remove editorial consideration of what should actually be in that field. However I can see some situations where this makes sense, like if the content type is for a single photo or a slide, where the node title is literally a description of the image, then a token would be accurate. Conversely, a hard-coded value would hardly ever be appropriate for alt text.

I think this is more contrib than core feature because using it responsibly would be riddled with caveats, but that's only my opinion. I'd love to get a few additional agreements that this makes sense for core if possible.

[stpaultim]

A desire for this feature was brought up in the forum in the 1.17 Feedback thread. https://forum.backdropcms.org/forum/feedback-version-117?page=0%2C0#comment-2197

[ghost]

There seems to be some confusion here as to what this issue is about. I've changed the issue title to hopefully explain it better.

Basically, Backdrop core currently allows Admins to enable Alt/Title field(s) for images. Editors then have blank Alt/Title field(s) they can fill in when adding images to content. This issue is requesting the ability for Admins to optionally provide default values when they enable Alt/Titles field(s) for images. That would mean that when an Editor adds an image to some content, the Alt/Title field(s) already have a value (which can be left as-is, deleted, or changed).

An example use-case for this might be a blogger who writes articles. Each article needs a hero image attached to it (for display in teasers, etc.). Since the hero image is representative of the article as a whole, the blogger has to manually copy & paste the article title into the Alt/Title field each time.

With this issue/PR, the blogger could specify something like [node:title] as the default value for their Alt/Title text in the Image field settings. Then, they just need to add an image to their articles and save, and the image's Alt/Title text is automatically populated with the article's title. Additionally, if the title of the article ever changes, the Alt/Title text will too because of the token.

Now, to clarify a few things:

• This might not be best practice (to use generic text for an image's Alt/Title text), but I'm not aware that Backdrop is in the habit of forcing users to adhere to best practices. We provide the tools, and then it's up to individual developers to use them as they will.
• Editors may see tokens when uploading images if the Admin has specified a token as the default value of the Alt/Title field, however I don't see this as a necessarily bad thing, since WordPress uses 'shortcodes' which I understand are quite popular (and Editors are generally the ones using WordPress).
• This issue/PR doesn't seek to change Backdrop's out-of-the-box behaviour/experience - Alt/Title fields (if enabled) will still default to empty fields. This issue/PR simply provides the opportunity for Admins to add default values if they wish to do so.

I hope that better explains things.

[olafgrabienski]

should the ability to add default values to alt/title text for image fields be in core or contrib (from Zulip)

I'm a bit skeptical re core integration. You mentioned a valid use-case, agreed! I think it's not very common, but I could certainly be wrong. Regarding best practices: Backdrop definitely shouldn't force users to adhere to them. This PR could however be seen as an encouragement to ignore best practices (even if the defaults stay the same).

Counter question: would it be difficult to build the feature in contrib, or are there particular disadvantages when only provided in contrib?

(PR is still working, btw.)

[klonos]

My thoughts on this:

D8 forces alt titles on images (alt title is always a required field). Not sure how I feel about this, but I often see people adding gibberish or a dot, just to "bypass" validation. So the way I see it, forcing people to adhere to best practices in this case may as well result in forcing them to be "creative", and try to circumvent things. At the end of the day, it is up to the good/thoughtful nature of the editor, and how well-informed they are re what the purpose of alt titles is. That is a separate issue though (#4809).

Using tokens for alt fields may be problematic, since the automatically-generated text may not accurately describe images, or you may end up having the same alt text for all images on a page (think multi-value image fields, set to have [node:title] as alt text). Some say that this is preferable to having empty alt text. In any case, we shouldn't be making that decision on behalf of the site owner/builder. I say we should be providing the tools they need to be automating things, and leave the decision up to them.

In other words, I am in favor of implementing this in core 👍

[ghost]

Just to point out... Even if an Admin sets a default value for alt text, it's up to the Editor whether they leave it as default or change it to something more meaningful per image.

[ghost]

PR updated for latest test suite.

[ghost]

With the hesitation of this feature request getting into core, I've made a contrib module that provides the same functionality: https://github.com/backdrop-contrib/alt_default