Pull Request for Issue #12829 .

Summary of Changes

This doesn't fully fix the issue, but hopefully it's a step in the right direction.

I've added an $extension argument to the onPrepareFinderContent handler and the FinderIndexerHelper::getContentExtras method because FieldsHelper::getFields needs to know the extension name in order to retrieve the correct fields. Perhaps there's a better way? There's also an implied equivalence between the finder layout name and the second part of the field context variable. Is that assumption always valid? I'm not sure.

I've added a prefix of "jfield_" to the field name saved in the index so as to avoid possible collisions between user-defined custom field aliases and existing fields in the content item.

The code assumes that all custom fields have values that are searchable strings (I don't know whether that's true) and that the terms will have the same weight as body text. I think it would be advisable to allow the user to determine whether a particular field is searchable and perhaps for some field types not to be searchable at all. At the moment, even numeric fields are going to be indexed. If a field is searchable, it would also be good to have the option of determining which weight multiplier group it belongs to.

As far as I can tell, the only reason this doesn't work right now is that the FieldsHelper::getFields call in the onPrepareFinderContent method is returning the old custom field values rather than the new ones. Consequently, you need to save changes to content items twice before the index will correctly reflect the new field values. I thought at first that this might be because of the order in which the plugins fire, but that doesn't appear to be case as PlgSystemFields::onContentAfterSave is called before PlgContentFinder::onContentAfterSave (which cascades down to the onPrepareFinderContent handler).

Note: The CLI indexer will not currently work with the onPrepareFinderContent handler in a system plugin because system plugins are not loaded by the CLI indexer. Personally, I would suggest moving onPrepareFinderContent into a finder plugin so all the finder events are handled within the same plugin group and I'll happily provide a PR to do that if folks agree. Otherwise, I'll do a PR to load the system plugins in the CLI indexer.

Testing Instructions

See #12829

Documentation Changes Required

None.