Garbage collection deletes files if they are inserted where filter can't find them.

This issue has spun off from https://github.com/backdrop/backdrop-issues/issues/3552

A client had loaded about 16 images into 16 text fields via the rich-text editor, and when he came back a day later, all the embedded images had been deleted from disk. The node was not published.

I just confirmed that publishing my node did not mark the fields as permanent. This particular node has a multifield on it, and I was trying to save the images in a text area that was part of the multifield.

It appears that embedded images are not saved on multifields, no matter what. See backdrop-contrib/multifield#29

I think we should find a way to abstract the file usage recording so that contrib modules can add additional data sources.

Right now all the parsing is done in filter_entity_insert() and filter_entity_update() but _filter_get_processed_text_fields() only checks for text_processing in a field setting to trigger the file usage recording.

Even if I were to add a (hidden) setting for text_processing on multifields to trigger the replacements, it still wouldn't work for multifield, because the data to be parsed does not live on the entity at $entity->$processed_text_field which is what filter module assumes.

I would like to propose a new hook where a contrib module could define strings of text that filter module could parse for file IDs. Naming things is hard. How about hook_parse_text_ids()?

This hook could replace _filter_get_processed_text_fields() and would return the text that needed to be parsed.

Text module could provide the value part of the field for textareas and textareas with summaries, so that we wouldn't need to rely on the text_processing setting.