Allow fieldtypes to manipulate values before inserting to search indexes

[jackmcdade]

I wonder if we should augment the data before inserting it into the search index so you can search on what you would expect as output. Thoughts, @jasonvarga?

Originally posted by @jackmcdade in statamic/cms#550 (comment)

[jasonvarga]

I don't necessarily agree that everything should be augmented before putting in the index, but definitely some.

eg. Bard fields store prosemirror structure that looks like this:

[
  0 => array:2 [
    "type" => "paragraph"
      "content" => array:1 [
        0 => array:2 [
          "type" => "text"
            "text" => "Foo bar"
          ]
        ]
      ]
    ]
  ]
]

If you were to search for paragraph or text, this entry would match. So we'd want Bard fields to get augmented, for sure.

But maybe another field converts to html or something. Use that photo gallery fieldtype example.

images:
  - one.jpg
  - two.jpg

if it augmented to <div class="gallery"><img src="one.jpg" /><img src="two.jpg" /></div> then div, src, class, etc would all match. No bueno.

So whatever the solution is, it should be up to the fieldtype to decide.

Probably just duplicate the Augmentable behavior and make an Indexable one.

[HellPat]

Mhh, I'd love to have the index configurable and let the user decide.

What about allowing a closure as fields in the index-configuration?

'default' => [
    'driver' => 'algolia',
     'searchables' => 'all',
     'fields' => ['title'],
],

could look like: (pseudo-code)

'default' => [
    'driver' => 'algolia',
     'searchables' => 'all',
     'fields' => function($entry) {
         return [
             'locale' => $entry->locale(),
             'searchable_content' => $entry->values()->get('content')->raw(),
             'content' => $entry->values()->get('content'),
         ];
     },
],