About This File
4.2.x , 4.3.x, and now 4.4 Compatible!
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!
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. 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 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" contains, 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.
What do you mean?
Every database field can have custom permissions. For example, you can create a bug tracker where there are publicly view-able 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. 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. We didn't get additional searchable fields in the 3x line, not with the initial 4.0.x hotness, and with 4.3 now it still appears to be a distant dream. I got tired of waiting. For my use case I can write a totally custom app, with separate databases for every "field" I want to be searchable and then handle everything with joins and all that on the back-end, or I can just append the two text fields I need searchable to the main content field with this plugin and call it a day. It might be possible to swing this by using the relational functions in Pages but I've never gotten them to work all that well to be honest.
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 repetitious entries and you'd rather just index out the more unique ones.
Maybe numbers? Both the above and this are totally doable, but let's just get this out the door first shall we?
OK, great, but I already have a massive 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, with PSTF 2, 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!
$20 to buy, $6 year renew but honestly consider the renew a tip jar as this is more or less "done" as it is.
What's New in Version 2 See changelog
- 4.4 Compatible - Do not use with 4.3.x or lower!
- Added feature to manually re-index a database.