Patch from #6 doesn't apply so I had to re-roll this against the latest version.
Looks like I did add the wrong version. Newly attached patch is the correct one based on #57.
I got an error using the fieldformatter on a field within a block while using layout builder.
LogicException: A stray renderRoot() invocation is causing bubbling of attached assets to break.
Attached patch fixes this. Reviewed the initial functionality based on a address field and looks good.
I stumbled accross the exact same problem when a SOLR container kept on dropping out even after memory increase.
An image dropped within a body field, in combination with the index title and alt atrribute options, caused the HTML not to be stripped.
Turning off the option to index both title and alt attribute options resolved the issue.
This should be addressed to get a more pragmatic solution though.
I made an update to only allow non content type relevant fields (layout builder specific) to be indexed instead of all the fields coming from the index.
Because of this, you don't longer need to use the Layout Builder Search API → contrib module (sorry maintainer) in order to get the reference as a field onto the search index. The update makes sure that referenced fields that have a reference to a file/media entity within block types in layout builder are available as indexable fields to get possible attachments indexed from.
After fixing this, the machine name naming convention is no longer an issue.
økse → created an issue.
The patch is a first proposition to come to a solution but isn't perfect by any means hence why I didn't upload it so far.
Remaining room for improvement:
- All the fields on the index (also the content type based added fields) are available to get the attachments indexed from. This should be improved to only allow non content type relevant fields
- Changing the machine name of the search api attachments source field on the index does cause issues. This should definitly be improved to have a more flexible behaviour.
I did debug this a bit further.
It looks like the difference in sub formatter within the Pattern (one for all) field formatter doesn't matter because the Pattern (one for all) field formatter doesn't make use of any configured sub formatter.
Ideally this functionally could be integrated.