Add alt_text field to image content type

[jackahl]

This PR is for issue #700. Most of the code is taken from #518, as it was easier to copy out the relevant code than to fix the merge conflicts.

The related issue in volto is plone/volto#6302

[mister-roboto]

@jackahl thanks for creating this Pull Request and helping to improve Plone!

TL;DR: Finish pushing changes, pass all other checks, then paste a comment:

@jenkins-plone-org please run jobs

To ensure that these changes do not break other parts of Plone, the Plone test suite matrix needs to pass, but it takes 30-60 min. Other CI checks are usually much faster and the Plone Jenkins resources are limited, so when done pushing changes and all other checks pass either start all Jenkins PR jobs yourself, or simply add the comment above in this PR to start all the jobs automatically.

Happy hacking!

[davisagli]

Couple minor comments, but basically looks good to me.

[davisagli]

Uh, there are failing tests though

[jensens]

I like this long needed addition - but: this needs more work to get it into all places where tags are generated, esp this are the scales. Merging this without consistent output also in Classic UI does not help.

[jackahl]

Uh, there are failing tests though

trying to fix them, but I am very unfamiliar with Classic Plone templates (I think those should be the cause for the test failures), would appreciate some help from someone at the @plone/classicui-team here then

[jackahl]

I like this long needed addition - but: this needs more work to get it into all places where tags are generated, esp this are the scales. Merging this without consistent output also in Classic UI does not help.

Agreed. Though I'd say this should be better done and evaluated by the classic UI team. Would someone at the @plone/classicui-team be willing to champion this effort?

[petschki]

Since most of the images are created with the @@images view this needs to be implemented here too https://github.com/plone/plone.namedfile/blob/master/plone/namedfile/scaling.py#L158

Another place is the resolve_uid_and_caption transform which also tries to set the alt parameter, but I could not quickly find where its defined.

And there are maybe some more places wich have to be updated ... pandoras box has opened 😉

[MrTango]

resolve_uid_and_caption

used to do it, but this is wrong, as images inside of TinyMCE should get the correct ALT text by the Editor.
This generated ALT text should only be used in listings, not everywhere where images are used. Only the Editor can know if an ALT text is needed and what it has to contain. Sometime an empty one is what you need.

[yurj]

The value of alt_text should be the default of the input when adding the image. Then the editor can choose to keep it or change or remove it. Win win, very few changes all backward compatible.

Also @davisagli suggested to implement it as a behaviour, so this would happen only when the behaviour is applied.

[jackahl]

The value of alt_text should be the default of the input when adding the image. Then the editor can choose to keep it or change or remove it. Win win, very few changes all backward compatible.

Also @davisagli suggested to implement it as a behaviour, so this would happen only when the behaviour is applied.

@yurj seems like a decent idea as well. I am quite agnostic about whats the best solution. But I think gathering some more opinions might help, coming to a decision.

[jackahl]

@plone/classicui-team cold one of you maybe take care of fixing the listing templates properly. I tried my best for quite while but 0a3fb93 was the best I could do with my limited knowledge of the templating syntax. But that broke all tests, where no alt tag was provided :/

[yurj]

item is a contentlisting and does not have an alt_image attribute, I suppose, until you add it to the catalog as metadata.

[jackahl]

item is a contentlisting and does not have an alt_image attribute, I suppose, until you add it to the catalog as metadata.

@yurj from what I could test by just checking the alt tag in my local build it did show up in the listing

[yurj]

item is a contentlisting and does not have an alt_image attribute, I suppose, until you add it to the catalog as metadata.

@yurj from what I could test by just checking the alt tag in my local build it did show up in the listing

you're right. contentlisting do a getObject if there's no metadata. but from Jenkins I can see:

File "/home/runner/work/plone.app.contenttypes/plone.app.contenttypes/.tox/test/lib/python3.11/site-packages/plone/app/contentlisting/catalog.py", line 52, in __getattr__
    raise AttributeError(name)
AttributeError: alt_text

here:
https://github.com/plone/plone.app.contentlisting/blob/abbeb13d7e2550c148aead3645d02e4514cbb828/plone/app/contentlisting/catalog.py#L39C1-L52C35

Maybe you miss some upgrade step here?

e5004cf

you add the field but you need to run the types upgrade step to get the change in the types.xml file.

[jackahl]

@mauritsvanrees I did how you advised and there are now at least fewer tests failing. Though I dont get why those are failing at all as they should be unrelated. I was also not able to provoke any errors on the local build anymore.

[jackahl]

EDIT: I think I finally fixed it

I was able to reproduce and fix few more error by locally replicating the robot test setup. But there are still 4 robot tests failing. I just can't reproduce them locally. Test feedback is also very lacking with:

AssertionError: Element 'id=content' should have contained text 'Test Document' but its text was 'We’re sorry, but there seems to be an error…
If you are certain you have the correct web address but are encountering an error, please contact the site administration.'.

Any ideas on how to reproduce, inspect or even fix this?

[jackahl]

@jenkins-plone-org please run jobs

[jackahl]

@jenkins-plone-org please run jobs

[jackahl]

So locally all test pass now. Annoyingly there are still some test failures on Jenkins. My guess would be that those are flaky? Locally I cannot run those, as I have an error building buildout.coredev

[jackahl]

Lets try another @jenkins-plone-org please run jobs to make sure they are not flaky

[jackahl]

@plone/classicui-team could one of you maybe give fixing the remaining tests a try. For me they pass locally. So cannot really reproduce the CI test failures

[petschki]

Those flaky robottests should get fixed by plone/Products.CMFPlone#4019 but Jenkins currently has problems setting up robotframework browser ... and there's a fix for the latest py3.12 here plone/Products.CMFPlone#4023 ... all in all I'd say if the tests pass on 6.1-py3.10 I'd merge it.

[mauritsvanrees]

@jenkins-plone-org please run jobs

[mauritsvanrees]

LGTM.

We should make more changes in other packages, like probably plone.outputfilters or maybe integration in the image plugin in TinyMCE. But this is the basis for making that possible. So let's merge.

One test failure on one of the Jenkins jobs, but it is unrelated.

[mauritsvanrees]

Merged. Thanks @jackahl !

[davisagli]

@mauritsvanrees Hang on, I was assuming this change will target Plone 6.2 or later. It is pretty late to add this new feature to 6.1, and more work is needed to use the new field everywhere, especially in Volto.

[davisagli]

@mauritsvanrees I especially object to adding the new field directly to the image content type schema in Plone 6.1, because it makes it quite difficult to remove it in projects that already have a custom alt text field. It should be a behavior so it can be added in a more controlled way.

[mauritsvanrees]

I may have been too trigger happy, trying to get some open stuff merged before it lingers too long.
Let me see if I can undo something.

[mauritsvanrees]

I have undone the change.

[davisagli]

@mauritsvanrees Thanks. I do want to come back to this one, I just think it needs a bit more work to make sure we can roll it out smoothly to existing sites.

[mauritsvanrees]

I have created a new PR as starting point, with the same code as was in here:
#705

@davisagli Thanks for keeping an eye out for what gets into core! :-)