Repository navigation
Search this topic does not deliver any results #7870
Description
Description
Search This topic does not deliver any results.
Steps to reproduce
- Visit a topic.
- Select
This topicfrom drop-down menu. - Enter a search term in the search field.
- Click
SEARCHbutton.
Environment (complete as necessary)
- Version/Git revision: 2.1.3
- Database Type: ??
- Database Version: ??
- PHP Version: ??
As I am not the board (https://forum.fhem.de) owner, I cannot provide details about database and PHP, sorry.
Additional information/references
None
Activity
Oldiesmann commentedon Nov 12, 2023
Works fine for me on 2.1.4 at seniorsandfriends.org
Sesquipedalian commentedon Nov 27, 2023
Since no one else can reproduce the issue and @7wells gave a thumbs up to @Oldiesmann's reply, I am interpreting that to mean that the issue can be closed. If that is incorrect and the issue is still occurring for you, @7wells, please feel free to reply to this with more information about how we can reproduce the problem.
isaak654 commentedon Apr 8, 2024
Issue confirmed by @sbulen in https://www.simplemachines.org/community/index.php?msg=4172803
Oldiesmann commentedon Apr 12, 2024
This affects SMF 3.0 as well.
Oldiesmann commentedon Apr 18, 2024
Seems to be fixed for 3.0 now with the latest search improvements
isaak654 commentedon Sep 22, 2024
@Sesquipedalian Please consider removing the “Confirmation needed” label and assigning a milestone for 2.1.x.
sbulen commentedon Oct 20, 2024
From: https://www.simplemachines.org/community/index.php?msg=4181419
sbulen commentedon Oct 20, 2024
So... There are a number of different variants on this in the code, but search basically does a high level word search, stores the complete first-pass result set into log_search_results, then applies any filters if necessary.
I did two queries in a row, one from an admin (that works, id=130), and one from a user (that doesn't, id=131). In the first stage, they both return the same 9 results, so far, so good:
The problem occurs in one of the subsequent filtering steps. The admin, of course, is not filtered. But the user result gets filtered based on topic approval state here:
SMF/Sources/Search.php
Line 1855 in e0b5174
Which looks something like this at execution time:
Which looks harmless enough... But... Look carefully at the screenshot above... For some reason, for this particular path thru the logic, those aren't topic IDs in the topic ID column, they're message IDs... So this query effectively filters out most/all of the search results...
Still looking into this, but I think this is the culprit right here:
SMF/Sources/Search.php
Line 1320 in e0b5174
sbulen commentedon Oct 21, 2024
Note 3.0 has the same code:
SMF/Sources/Search/SearchApi.php
Line 1781 in 9fceb31
sbulen commentedon Oct 22, 2024
I suspect the quirky code above (stuffing msg IDs into the topic ID column...) is a bit of a red herring.... Mainly because the comment above that code ("Outrageous!!!") is a clue they knew they were doing something weird... I sure wish there were a better clue in the comments than that, tho...
(Great job on the 3.0 refactor, @Sesquipedalian ... It seems to have ironed out several quirks....)
sbulen commentedon Oct 25, 2024
This has been bugging me like a sore tooth... I have started getting complaints on my 2.1 forum... Once they noticed, they noticed...
I have confirmed the problem exists in 3.0, 2.1, and even 2.0. (edited my comments above...)
Here is what I think is going on:
SMF/Sources/Search.php
Line 1836 in 1468660
So, to reproduce in 3.0, you must enable post moderation. For some reason, post moderation is NOT enabled by default in 3.0, but it is enabled by default in 2.1. (This is why I initially thought 3.0 was OK.)
With post moderation ON, any message ID that doesn't point to a valid topic, when joined on id_msg = topic_id, is excluded from search results. Which happens a lot, actually, because you tend to have a lot more messages than topics. It will get much worse on more recent messages & topics on mature forums. Or forums with lots of replies.
The problem happens for any search engine, as this particular logic (post moderation check) is independent of the API.
Admins are not affected as they can see unapproved topics.
sbulen commentedon Oct 25, 2024
In 3.x, I think the structure should change. Get rid of the workarounds. Instead of relying on INSERT IGNORE to lop off dupes, fix the GROUP BYs instead. There is so much inscrutable logic in there, with dynamically built queries that are quite difficult to read... But I think the reality is it would simplify things a lot. It is much more convoluted than it needs to be. At its core, these are just approval & permissions checks... No need to get so complicated.
...And don't stuff id_msg into an id_topic column.
live627 commentedon Oct 25, 2024
I'd like to see the end result. The search area is one place I could never really figure out what all was going on.
Sesquipedalian commentedon Feb 11, 2025
Picking this up some months later:
First, thanks for all your sleuthing on this, @sbulen! Your assessments of what is going on are all correct, as far as I can tell.
Second, the root of the problem is, as you correctly identified, that "The structure for log_search_results has topic ID as part of its primary key." More specifically, the problem is that the primary key includes
id_searchandid_topic, but notid_msg. Because of that,log_search_resultscannot contain a row for each message within a topic for a given search. Stuffing the message ID into the topic ID field looks like it was a nasty hack introduced long, long ago in order to try to bypass the problem.The better solution is also a simpler solution: change the primary key so that it includes
id_search,id_topic, andid_msg. That gets rid of any need for nasty hacks to fake theid_topicvalue in order to bypass the primary key constraints, which means we can stop stuffingid_msginto theid_topicfield and instead just letid_topicbe what it is supposed to be.I will submit a couple of PRs shortly.