How does this work?
During the indexing process for an IPS Pages database record the field you have flagged as "Content" is processed by the IPS indexing method. After that is complete, this plugin checks that the overall item is indeed a Pages database record and looks for text, text area, and editor fields that are also a part of the record. If those fields have been flagged by you with this plugin to be included in the search index those areas are then collected, stripped of HTML elements to retain only the pure text content (Editor fields only), and then appended to the end of the initial indexed data (that field you have marked as "Content").
That field content is now in the search index and, naturally, searchable!
For example if a Pages database content element consists of "Today is a good day to die!", and you have an additional text field where you allow someone to enter a day of some kind, for example, "Penguin Awareness Day", if you flagged that extra field as searchable, the indexed text for this content item will be:
Today is a good day to die! Penguin Awareness Day
Without the ability to flag these extra fields as searchable and then append their contents on to the content item search data entry, searches for Penguin Awareness Day will return nothing at all, which makes the use of Pages databases much less useful when you can only search for the fields flagged Title and Content.
When does this actually apply?
When records are saved (initial creation) and when edited of course. Also during search index rebuilds.
What happens if I remove this plugin or disable it?
Those additional fields will no longer be indexed. Any of those fields previously indexed with records will remain in the index until the record is edited again or you rebuild the search index. On edit or re-index, that additional appended text will not be indexed.
I can't stop you or your other admins from doing... interesting things. This plugin does EXACTLY what it says, no more, no less. The plugin also is not psychic so when one of your admins decides to do some server work and disables this (and other plugins) but people are still making entries on the front end into a Pages database where you had extra fields marked as searchable the result will be pretty much what you expect...
What happens if IPS decides to finally include this functionality themselves?
Remove this plugin, do whatever is required of the new IPS functionality, rebuild the search index. This plugin only appends the additional text to the search index entry (which for Pages database records is whatever the content of the field flagged as "content" is, minus HTML code) and makes no actual changes to the record content itself.
Why hasn't this been included by IPS before?
Appending specifically? Permissions. Searchable fields in general? A structural challenge with the overall IPS content model.
Every database field can have custom permissions. For example, you can create a bug tracker where there are publicly viewable fields and then other fields that only staff can see. However, there is only a single search index content entity that is searched - not separate searchable entries for every field. That means that every field you append to the search index with this plugin MUST be a field you want everyone to be able to see and search. When viewing a record those field permissions will of course apply, but with this information appended to the single searchable index entry you risk the chance that a search result will display with that formerly staff-only field and now everyone will know your admins are calling other members "buttheads" or worse. Be careful!
For IPS to solve this, they would need to treat all additional text, editor, and text area fields as totally separate entities to be inserted into the search index. The management of that endeavor will require some engineering - it's doable but requires some choices to be made along with how to present the final search result. We didn't get additional searchable fields in the 3x line, not with the initial 4.0.x hotness, and with
4.3, 4.4, 4.5 now it still appears to be a distant dream. I got tired of waiting. For my use case I can write a custom app and deal with the problem my way, or I can just use Pages, append the two text fields I need searchable to the main content field with this plugin, and call it a day.
Looking at filtering out content from being indexed by entering a regex equation. If the content of the field matches your regex, this plugin will not append it to the search index entry. This will cut down on search index spam if the text fields you are appending often contain repetitive entries and you'd rather just index out the more unique ones. Maybe numbers?
August 2020 EDIT: Those are still on the table but with only four purchases all these years it's not a priority. If someone wants to throw some money at me to sponsor those features feel free. I actually use the regex tweak on one site but it's currently a simple hardcoded hack.
OK, great, but I already have a massive Pages database. I installed this and set the fields I wanted to be indexed in this database. I get that new records going forward will have the field values added to the search index but what about old records?
For Invision Community 4.4 and above, with PSTF 2 and above, you can now click on the plugin settings and fire off a re-index process for the database you select. 4.3 or lower users on an older version will need to manually edit and save (that's all, just open/close) each record to force the new indexing or rebuild your entire community via the search settings in the ACP.
PSTF version 2 is for Invision Community 4.4 exclusively - do not use on lower versions!
PSTF version 3 is for Invision Community 4.5, though it should work on 4.4 as well (untested)
$20 to buy, $5 every 6 months renew