When I choose the IRichText behavior:text, it creates a field called "text" automatically. I noticed that when I use this field, the content inside this field is not searchable. I know I am to use collective.dexteritytextindexer but for this field that is automatically produced by Dexterity, I don't know where I can add indexer:searchable="true".
Seems like for the Page content type, the "text" field is searchable. Should this field that is added automatically when one checks the IRichText behavior be also a part of Searchable Text in portal_catalog?
I guess I don't know enough about Dexterity... but why do you need the IRichText behavior?
I was able to create on a test site a similar Policy with just two fields, Policy Content (Rich Text field) and Policy File (uploaded file), and it displays fine in my folder_contents view.
I also enabled the behavior "Dynamic SearchableText indexer behavior".
Then when I searched for text that appeared only in my one Policy item's Policy Content field, it worked (you might have to edit and save your policy items to force them to be reindexed).
Yes, when the field has indexer:searchable="true" in it, it is searchable. However for the RichText behavior:text there is no place whereby I can put indexer:searchable="true". The RichText behavior:text field is not searchable. It really should have been pulled into Searchable Text in portal_catalog by default but it is not functioning as it should. I believe there may be a bug between Dexterity RichText behavior:text and portal_catalog. They are not not talking to each other.
In my form, the RichText behavior:text behavior is not necessary. I thought it would help in the folder_contents listing issue. I have since remove it from my form. There really is no point using the RichText behavior:text since it is not searchable nor would it help with the folder_contents listing issue. As long as there is a value in this field, it will bomb the folder_contents listing feature. Could there be a bug affecting the interaction between Dexterity and Plone?
@angelawong I must be missing something. I've tested locally and my tests work, probably because I did not start by enabling the behavior. This seems to me a way for you to proceed without having to code anything nor having to wait for Jens to get that feature into core. I think I've reached the end of my ability to help you, without having access to your site. If you'd like to hire someone to help you, you know where to look
Kim, thank you so much for testing the issue with me. I really appreciate your time and effort on this. Yes, if I need to hire someone, I know where to look .
Jens, thank you for looking at my codes and for coming up with a solution. I look forward to the feature getting into the core. Thank you for working your magic. You are awesome.
By following @jensens solution I successfully make my custom type searchable for the text field. For the record, in Plone5, you might want to import _unicode_save_string_concat from plone.app.contenttypes.indexers.
according to Python's naming styles, any name starting with an underscore is supposed to be private (weak "internal use" indicator); so, you should not depend on anything like that for your own code:
if this piece of code is intended to be reused, it should be renamed: