@Hackwar

This is com_search. If you really want this, add it.

File is
plugins/finder/content/content.php not com_search afaik

@vitotafuni Are you trying to add this to Smart Search or to com_search?

Sorry
I'm using smart search and so I've just edited the finder plugin
but for the sake of completeness I would modify both

Ok, I'm not really 100% convinced, but it wont also be an issue, so we can simply add this. However, I would avise you to make a copy of the plugin. Then it doesn't get overwritten by updates.

However, I would avise you to make a copy of the plugin. Then it doesn't get overwritten by updates.

Not sure I get it. If the Pr works and is merged, why keep a copy and where? Next Joomla release would include it.

I've made a patch for the plugin on my sites... but it's a kind of simple and "no problem" change, that I think it could be applyed without thinking.
Why are you not convinced??
If you want a blog section on your site, from an adv point of view, images make 90% of communication!

I have tested your patch
One of my articles contains an intro and a full article image.
Using smartsearch for the name of the image does NOT display any result

@vitotafuni I'm not 100% convinced because this is a com_content specific field and thus could not be contained in the default layouts of com_finder. But in the end, adding this to the index is no big deal and wont hurt anyone.

@infograf768 If we accept this patch, you don't have to make that copy, but there might be other data that you want included in the index, for example the custom fields, and to prevent you from having to do that fix every update again and again, you would want to copy that plugin simply. A finder plugin does not have to be named the same as the component.

Also, we are just adding this data to the index, we are not displaying it in the frontend. That is something that you would have to do via a template override. We also don't add it to the list of terms connected to the content item. This is purely to improve the rendering of the results if you want to.

Therefore, if I understand well, it means one has to add a specific code in a template override.
To test, I would need to know what and where.

ok it's a specific field but If you search on google you will find a lot of users editing that file or looking for a way to get images available... and a lot of them are not delevoper and they make mess with the code!
However I access custom fields with the getElement method of the result variable directly in the template override so... hey it's just there!
"This is purely to improve the rendering of the results if you want to." designers could burn you for this sentence! ;-P
A web site is 90% rendering and 10% technology from a final user point of view.
As a developer I understand you but I think it's not about how good is the improvement but how many people could benefit from it... in particular ME... no need to patch the code every time there's a Joomla update anymore! ;-DDD

adding the images json object to the index makes in my opinion no sense.

@Hackwar can the index decode json or at lease split the text string?

Also adding this would result in adding every word from this json object:

{"image_intro":"","float_intro":"","image_intro_alt":"","image_intro_caption":"","image_fulltext":"","float_fulltext":"","image_fulltext_alt":"","image_fulltext_caption":""}

In my opinion indexing the alt of the image is questionable.
But making X queries to get the image field for each article (just because is not there in the results) is the real "no sense".
https://www.google.com/search?client=firefox-b-d&q=joomla+image+com_finder+search+result

@infograf768

I have tested your patch
One of my articles contains an intro and a full article image.
Using smartsearch for the name of the image does NOT display any result

I've read your comment just now. Simply you need to reindex or edit that article because the extracted fields are cached.

Indexing the alt attribute would be ok, but for this you have to change a bit more code then just adding the image field to the query.

If you can change it to only index the alt attribute I consider to merge it.

Adding the images field to the query does NOT add any of the content to the index. It just adds this into the IndexerQueryResult object, which is serialised and stored as a copy in the #__finder_links table. This is purely to have the images data available when rendering the search results.

ok so the way to get the image information into the search result is correct, but this will not add the alt attribute to the index.

No, this will not add anything to the terms, which are searched for the search results, correct. And from my perspective they shouldn't be added.

@HLeithner is this a new Feature (> J4)?

I will merge it in 3.9.7 if we get 2 tests.

@vitotafuni please give clear test instructions in opening comment so we can get 2 (successfully) Tests.

@HLeithner this is a new feature. New features can not be added in a patch release

@vitotafuni please give clear test instructions in opening comment so we can get 2 (successfully) Tests.

@franz-wohlkoenig What kind of tests do you need?
The patch add just 1 field to the select of a query... 0 impact in my opinion!
Just give me details if I can help.

@vitotafuni its about People who can't read files, they need Instructions what to test (iE. using Patchtester).

thx

@HLeithner this is a new feature. New features can not be added in a patch release