[#47719] - Fix delay of com_finder search
- Pending
- Medium
- Build: 5.4-dev
- # 47719
- Diff
- devesht-ML:fix-finder-delay-47625
User tests: Successful: Unsuccessful:
Fixes #47625
- I read the Generative AI policy and my contribution is either not created with the help of AI or is compatible with the policy and GNU/GPL 2 or later.
Summary of Changes
This PR fixes a delay in Smart Search (com_finder) where newly created content is not immediately searchable.
The issue was caused by truncating seconds from the current timestamp (nowDate) using:
substr_replace(Factory::getDate()->toSql(), '00', -2)
This caused newly created content within the same minute to be treated as "future content", resulting in a delay of up to one minute before appearing in search results.
The fix removes this truncation and uses the full timestamp including seconds:
Factory::getDate()->toSql()
This ensures accurate time comparison and immediate visibility of new content in Smart Search.
Testing Instructions
- Go to Components → Smart Search
- Click "Index" to build the search index
- Create a new article (e.g., Test123)
- Immediately go to the frontend
- Search for the article using Smart Search
Actual result BEFORE applying this Pull Request
- Newly created content is not found in search immediately
- It appears only after the next minute
🎥 Before Fix (Video)
com_finder.1.mp4
Expected result AFTER applying this Pull Request
- Newly created content appears instantly in search results
- No delay is observed
🎥 After Fix (Video)
after-fix-com_finder.1.mp4
Link to documentations
Please select:
-
Documentation link for guide.joomla.org:
-
No documentation changes for guide.joomla.org needed
-
Pull Request link for manual.joomla.org:
-
No documentation changes for manual.joomla.org needed
| Status | New | ⇒ | Pending |
joomla-cms-bot
- | Category | ⇒ | Front End com_finder |
Besides that, this PR changes the code but leaves the comment one line above unchanged:
// Get the current date, minus seconds.
So the comment becomes wrong.
Finally, I do not even think that the referenced issue #47625 which this PR tries to solve is an issue. It should be closed as expected behaviour. But that's just my personal opinion.
Indeed, this is intended behavior. We want to prevent the query cache of MySQL to always miss, just because the seconds of that part of the query change. com_content does the same afaik.
@devesht-ML Thank you for your PR.
However, as the developers are of the opinion that this behaviour is intended, I will close the issue.
Indeed, this is intended behavior. We want to prevent the query cache of MySQL to always miss, just because the seconds of that part of the query change. com_content does the same afaik.
just at note, mysql has no query cache since 8.0, but still valid for mariadb and postgres afaik
i assume that the seconds were removed for a reason and not just for fun