- Fix "before" search result term would print an integer instead of a human readable yyyy-mm-dd formatted string
- Change 'no results found' handling to display search terms on the relevent page
- If using ElasticSearch Essentials, recommend updating to v3.13.0+ as this change may impact some options which display on no results found.
- Fixes for search term on results page
- Add missing "With X thread" search term
- Fix "Users" search term could fail to render the list of usernames
- Add the 'content type' search term
- Remove usage of utf8_* function(s), and use native php multi-byte functions instead.
- Fix HTML markup error in svPushViewOtherCheckIntoXFES option description
- Fix bug where 'weight by content type' feature didn't work as expected in general search
- Thanks to @NamePros for sponsoring this update.
- Display various search term constraints on the search results form.
For developers to implement support in 3rd party add-ons:
- Each search constraint needs a svSearchConstraint. prefixed phrase.
Arrays are mapped to phrases by adding a _ for each sub-array/key as such; c[warning][points][lower] => svSearchConstraint.warning_points_lower- Each search order needs a svSearchOrder. prefixed phrase.
- Extend XF\Entity\Search::getSpecializedSearchConstraintPhrase(string $key, $value) to provide custom phrase handling (ie node names)
- Extend XF\Entity\Search::formatConstraintValue(string $key, $value) to provide custom formatting.
- Extend XF\Entity\Search::setupConstraintFields to populate $svDateConstraint/$svUserConstraint/$svIgnoreConstraint properties which control formatting
- Use the debug option "List all unphrased search constraints" which will dump unmapped contraints to search results page.
- Fix incorrectly adding a return type to XF\Search\Search::isValidContentType
- Fix typo in admincp options phrase
- Require php 7.2+
- Add ability to push "can view threads/tickets by other" permission(s) into ElasticSearch query, reducing php-side culling of matching content.
This improves searching forums/tickets where the user lacks these permissions.
This is gated behind the option Push "View X by others" check into XFES', as it requires a full reindex. (Default disabled)
Supports the following add-ons:For best results, use ElasticSearch Essentials add-on, as it simplifies this permission constraint compared to stock XenForo
- View Sticky Threads (free) add-on.
- Collaborative Threads (paid) add-on.
- @NixFifty's Tickets (paid) add-on.
- Fix "array_fill_keys() expects parameter 1 to be array, null given" error when content weighting has not been configured
This feature is powering tag autocomplete and username autocomplete which supports partial matches, and non-prefix lookups on SpaceBattles.
- Require XenForo 2.2+, removes xf2.0/xf2.1 support
- Add "Specialized index" support
- Specialized search index allows generating single-purpose elastic search indexes while re-using as much XF search infrastructure as possible.
- Elasticsearch index is more akin to an SQL table than an entire database, so for very specific tasks a single purpose search index works better.
- A separate index also allows changing indexing properties and re-indexing just that one index without impacting the main search index
- Implementation of a specialized index notes;
At the core, a XenForo search handler is used to drive the functionality.
- The search handler should implement the interface \SV\SearchImprovements\Search\Specialized\SpecializedData
- Use the types MetadataStructure::KEYWORD or MetadataStructure::STR fields in setupMetadataStructure.
These types will be rewritten to add .exact & [/icode].ngram[/icode] subfields. To skip this pass ['skip-rewrite' => true] to the MetadataStructure::addField's 3rd argument.
- MetadataStructure::KEYWORD - shortish text which is semi-structured such as tags or usernames
- MetadataStructure::STR - Arbitrary text which uses phrases of text
- Register the search handler with the following content type fields
- specialized_search_handler_class
- entity
- This handler really shouldn't be registered with search_handler_class content type field.
- Add the behavior SV\SearchImprovements:SpecializedIndexable to the entity.
Example of the 'indexes page'
This feature is powering tag autocomplete and username autocomplete which supports partial matches, and non-prefix lookups on SpaceBattles.
- Require XenForo 2.2+, removes xf2.0/xf2.1 support
- Add "Specialized index" support
- Specialized search index allows generating single-purpose elastic search indexes while re-using as much XF search infrastructure as possible.
- Elasticsearch index is more akin to an SQL table than an entire database, so for very specific tasks a single purpose search index works better.
- A separate index also allows changing indexing properties and re-indexing just that one index without impacting the main search index
- Implementation of a specialized index notes;
At the core, a XenForo search handler is used to drive the functionality.
- The search handler should implement the interface \SV\SearchImprovements\Search\Specialized\SpecializedData
- Use the types MetadataStructure::KEYWORD or MetadataStructure::STR fields in setupMetadataStructure.
These types will be rewritten to add .exact & [/icode].ngram[/icode] subfields. To skip this pass ['skip-rewrite' => true] to the MetadataStructure::addField's 3rd argument.
- MetadataStructure::KEYWORD - shortish text which is semi-structured such as tags or usernames
- MetadataStructure::STR - Arbitrary text which uses phrases of text
- Register the search handler with the following content type fields
- specialized_search_handler_class
- entity
- This handler really shouldn't be registered with search_handler_class content type field.
- Add the behavior SV\SearchImprovements:SpecializedIndexable to the entity.
Example of the 'indexes page'
- Fix the "Default search order" option would get reset when changing "Search options" under Enhanced Search Setup page