joomla-cms
joomla-cms copied to clipboard
joomla
[4.2] Finder: Add modifier to influence search ordering
Summary of Changes
A customer of mine gave me feedback that they would like to be able to influence the ordering of search results in Smart Search. Specifically, they have content that doesn't contain the key words very often, but is nearly always more relevant to the searching user than other, more keyword-dense content. They would like a feature to push that content further up in the search results.
I've been thinking about ways to do this and there would be several options. We could introduce a "featured" flag and then sort by "featured" and then by relevance or we could add a modifier/multiplier to the contexts for the content of such featured content. Both proposals have their downsides, quite a few being the complexity to implement in the current structure.
This implementation allows to set an integer modifier per content item in the index, which the weight for the relevance is multiplied with for the right ordering. There is no direct GUI to modify this, but this is supposed to be handled by the developer of the finder plugin. As an example, featured articles and contacts get a modifier of 5 and thus a higher relevance than non-featured items. You could expose this in the GUI of your extension directly or you could use a ridiculously high modifier to sort by type before relevance. (For example in a site with a shop, you might want to give all products a modifier of a million, so that in the search results products always come first.)
NOTICE: Since we are adding a new column to the #__finder_links table and a new attribute to the Result object, we unfortunately invalidate all serialised objects in that table from earlier indexing and will get errors in the frontend when we want to use this old data. Thus we need to reindex the content. We DON'T need to clear the index first. By setting the md5sum column to an empty string, we are forcing a reindexing without clearing the index first and with that clearing all of the filters and their IDs.
Testing Instructions
- Setup a site with Smart Search
- Mark an article as featured.
- Search for something and remember the ordering. The featured article shouldn't be at the top of the results.
- Apply the patch including the database changes.
- Click the Index button in the backend.
- Search for the term from 3. again
Actual result BEFORE applying this Pull Request
You get the same result as in 3.
Expected result AFTER applying this Pull Request
The featured article shows up a lot further up than in 3.
Shouldnt this be done by using the already existing multiplier functionality and building upon that
No, mainly because it is very difficult to implement nicely. We could do this with these multipliers as well, but it would be a code mess and far less flexible than this proposal.
If I have read this correctly it is essential that the user rebuilds the index after updating to this code or their site will produce errors.
Assuming that is correct this is a big problem.
- Updates performed by a SaaS or host will break the site
- Post-installation messages have only ever been informational - I doubt many people read them immediately - and they wont be seen by anyone using a SaaS/host update.
- Telling people AFTER an update that you just broke their site and they have more work to do will discourage people from updating in the future.
In summary - the update process should be self contained - especially if it breaks something
That is why I mentioned this, to discuss the impact this has. Or maybe someone else has a better idea how to solve this. The problem is, that the Result object is serialised upon indexing and then unserialised for the search results. Since the class would get modified with the update, this would throw errors.
However, we also can't simply trigger a reindex upon update, since that can potentially take a very long time.
So from my perspective this is not acceptable - especially as it is to enable a "hidden" feature
This pull requests has been automatically converted to the PSR-12 coding standard.
