The 2026 Drupal Business Survey is open. Your response will help shape the future of the Drupal business ecosystem.After running my module updates last week, I noted two particular fields in my data dropped out of the Index. That is, they no longer appear in the regular list of fields to be indexed, but appear below in the "Add Related Fields" section. This caused other issues with Facets, etc. I tried to do a workaround and re-index the fields from "Add Related Fields", but I got a sorting error saying one of the fields was missing.
The two affected fields are of type "text_formatted" and "struct", which is actually a date field. There seems to be no way to recreate a text area field into a "text" type, and a custom date field will always come out as a "struct" type and not a "date" type. It seems logical to add these two field types to the list of allowed field types and add whatever functionality is required.
| Comment | File | Size | Author |
|---|---|---|---|
| #12 | SEARCH_API-index_formatted_text_fields.patch | 1.53 KB | netw3rker |
| #7 | new_field_types-1528806-7.patch | 7.69 KB | tomogden |
| #2 | new_field_types-1528806-2.patch | 7.69 KB | tomogden |
Comments
Comment #1
tomogden commentedUPDATE: Testing on an older test site, I found the date-to-struct issue seems to be from an update in the Date module. That's good for them, but complicates things somewhat for indexing.
Comment #2
tomogden commentedPlease see the enclosed patch.
To add the 'text_formatted' field type, rather than trying to introduce a new field type, I followed the pattern of treating it as a "text" field type.
The 'struct' field type was quite more complicated. Even though this application of 'struct' is a of type 'date', it's possible for a struct to be something else. Again, I chose to avoid introducing a new (and nebulous) field type and elected to extract the inner field type and values from within the struct array.
It could all use a good philosophical review
Comment #4
tomogden commentedThis patch likewise requires a patch in the Search API Solr Search project. See #1537046: Work with 'struct' Field Type.
Comment #5
tomogden commented#2: new_field_types-1528806-2.patch queued for re-testing.
Comment #7
tomogden commentedComment spaces and spaces introduced by Git have been removed from the patch.
Comment #9
tomogden commentedI'd like a second opinion on the patch. I'm not sure I follow the veracity of the project Test class results.
Comment #10
drunken monkeyHi there!
First off, thanks for the code cleanups in your patch! I committed them and was a bit taken aback by some of them …
However, in general, please only include the bits that actual pertain to the issue at hand!
Regarding the main purpose of the patch, this won't happen. We can't randomly include special cases for contrib modules or we'll never stop. If the field's child properties don't include one that fits your purposes, add one yourself using Entity API property alteration hooks or Search API data alterations; if you can't add a related property in the "Fields" tab, please file a seperate bug report.
Comment #11
tomogden commentedThanks, @drunken monkey.
I'm not sure what happened, but the indexing issue with the Date and Body fields has gone away using the most recent core and modules. I am now running without the above patch.
Comment #12
netw3rker commented@drunken_monkey,
I'm going to have to both agree and disagree with your reasoning for closing this. I totally agree that the road to disaster is paved with contrib handlers. Adding the handler for Struct/Date fields definitely doesn't make sense. That being said however, the 'text_formatted' handler is special because the Entity API provides it, and converts fields that are rich text formatted into text_formatted fields. This means that if you have a field you are using that is an ordinary text field, you can index it just fine. If you then later on switch that field to allow formatting, it will suddenly not be available to your index because it has been removed for the 'normal fields' list, and you'll lose any index settings you might have applied to it.
The reason this should be supported is that the index_entity.inc file has a hard dependency on the entity api, so it would make sense for it to support the special field types that it provides.
I've attached a patch that allows for text_formatted to be used. This is based on @tomogden's work which guided me to the points to apply this to.
Hope this helps!
Comment #14
drunken monkeyAnd just changing the type in these two places makes the field index normally, even though the real value is in a different place now?
That's pretty impressive, actually, and would point to us being able to generally offer a simplified UI for those fields.
Comment #16
webcultist commentedSorry if I ask something in this context, but it fits here very well.
I have a date field with an end date - and therefore it seems to have the date type "struct".
You said that it makes no sense to create a patch for this, but how is the correct way to handle this?
The field is not normally indexable.
If I use the related fields select and index it via this field, I get always double entries (one of them is an empty div) and double counts in the facets .
Do I do something wrong? Is there a custom way to fix this. Sorry If I'm wrong asking here...
Comment #17
drunken monkeyI guess the question is fine here.
What field(s) are you exactly indexing, and what do you mean with the double counts in facets? Screenshots would be nice.
(Come to think of it, maybe better create a new issue for this after all. Just link to it here afterwards.)
@ netw3rker: One more question: with your patch, is it still possible to index
body:value? Otherwise, an immense amount of sites would break.