Search results in MDN completely broken. Relevance and useless redirects.

RESOLVED FIXED

Status

RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: soswow, Unassigned)

Tracking

Details

(Whiteboard: [specification][type:bug])

(Reporter)

Description

5 years ago
What did you do?
================
So, it is not the first time when I found something very strange in a first place in my search result.

Here is simple example:
I type "createElement" and I found this as a first result

https://developer.mozilla.org/en-US/docs/Talk:DOM/document.createElement - have now Idea what is this?

What are other results ?
developer.mozilla.org/en-US/docs/DOM:document.createElement
developer.mozilla.org/en-US/docs/DOM/document.createElement
developer.mozilla.org/en-US/docs/document.createElement
developer.mozilla.org/en-US/docs/Web/API/document.createElement
developer.mozilla.org/en-US/docs/Document_Object_Model_(DOM)/document.createElement

Four of them redirect to the same page - https://developer.mozilla.org/en-US/docs/Web/API/document.createElement

I think it shouldn't be like this anyway.



What happened?
==============
-

What should have happened?
==========================
-

Is there anything else we should know?
======================================
(Reporter)

Updated

5 years ago
Component: General → Site search
Aleksandr, are you testing the redesign beta? Do you see a banner starting with "Welcome to the new MDN beta!" at the top of the page?
(Reporter)

Comment 2

5 years ago
Sorry, for not mentioning this. Yes, I'm testing beta. (And Also I assumed search result should be the same, because it's only "design")
Blocks: 910513
I think Groovecoder reindexed the search, excluding a lot of pages. This may have solved all or part of this problem.

Groovecoder: can you confirm that the reindexation is in prod and we can retest?
Flags: needinfo?(lcrouch)
Reindex helps, but there's still a bug where those pages are added back to the index if they're updated/edit/re-created. I'm still working on that one.
Flags: needinfo?(lcrouch)
Much of this is contingent on https://github.com/mozilla/kuma/pull/1583 landing - it refactors a bunch of search code.
Cool, I think we should block on this (likely mostly a duplicate of other blockers anyway) and revisit this once PR 1583 is in prod.

Feedback from Ali requested for the blocking decision.
Flags: needinfo?(aspivak)
Agreed, we should re-check the quality of the search results after the PR in 
comment 5 lands.
Blocks: 925144, 930047
No longer blocks: 910513
Status: UNCONFIRMED → NEW
Ever confirmed: true
Confirmed with Ali that this should block the launch.
Flags: needinfo?(aspivak)

Comment 9

5 years ago
Commits pushed to master at https://github.com/mozilla/kuma

https://github.com/mozilla/kuma/commit/d8ce6fc87c3cd82c3cfa8a0173e22fecee989433
fix bug 928302, 929373, 931412 - Check if the search index entry of a wiki document should really be updated during saving or deleting.

This fixes the problem of accidentally indexing wiki documents which  
aren't supposed to be index when saving or deleting them.

https://github.com/mozilla/kuma/commit/334a8cee56d8947fab213ce2a02424f7c346fb1d
Merge pull request #1631 from jezdez/improved-indexables-928302

fix bug 928302, 929373, 931412 - Check if the search index entry of a wiki document should really be updated during saving or deleting.

Updated

5 years ago
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
(Reporter)

Comment 10

5 years ago
When the latest index will be available in production? I don't see any changes right now.
You need to log in before you can comment on or make changes to this bug.