1023763 - Red links stay red even when the page is created

Status: RESOLVED WONTFIX

(developer.mozilla.org Graveyard :: Wiki pages, defect)

Description

[Jean-Yves Perrier [:teoli]]

What did you do?
================
Red links indicate pages that have not yet created.

What happened?
==============
Visited: https://developer.mozilla.org/en-US/docs/Web/API/URLUtils
The UrlUtils.searchParams was in red, though the page exists.

What should have happened?
==========================
The URLUtils.searchParams should have been in blue.

Is there anything else we should know?
======================================
- This is an important feature: red links mean no page on the other side.
- It is a regression, it was working a couple of months ago
- We got complaints from users
- Shift-reload cured it.

Comment 1

[Jean-Yves Perrier [:teoli]]

Attachment: Screen Shot 2014-06-11 at 10.57.32.png

Red link that should have been blue.

Comment 2

[Florian Scholz (Open Web Docs)]

I think this has been done for performance reasons.

I remember Les did some refactoring here a while ago
https://github.com/mozilla/kuma/commit/4e080097e38e7382b2d94b46e77e266d6a52863d

Les, can we have red links correctly all the time or only on rebuild? Does the former have performance impacts?

Comment 3

[Les Orchard [:lorchard]]

(In reply to Florian Scholz [:fscholz] (elchi3) from comment #2)

> Les, can we have red links correctly all the time or only on rebuild? Does
> the former have performance impacts?

Yeah, I think this is just part of the rendering & bleach chain, which only happens on rebuild. Most of that stuff has pretty horrible performance to let any of it run on normal views.

Comment 4

[ali spivak]

This should be prioritized and added to the op 10 list - we've received complaints from users.

Comment 5

[Les Orchard [:lorchard]]

Maybe we can look at rebuilding all the pages that link to a page when it's newly created? 

We might be able to add an elasticsearch index that tracks docs by the links they contain. (That could be also be interesting for building the kind of "backlinks" functionality most early wikis had, too.)

But, I don't think we can just move link annotation back into the critical path of every view. That was a lot of database activity & processing pulled out - I think it shaved as much as a full 100ms off our average response time, which is really significant.

Comment 6

[Florian Scholz (Open Web Docs)]

(In reply to Les Orchard [:lorchard] from comment #5)
> We might be able to add an elasticsearch index that tracks docs by the links
> they contain. (That could be also be interesting for building the kind of
> "backlinks" functionality most early wikis had, too.)

That said, I am adding bug 813484 as a dependency.

Comment 7

[Jean-Yves Perrier [:teoli]]

(In reply to Les Orchard [:lorchard] from comment #5)
> Maybe we can look at rebuilding all the pages that link to a page when it's
> newly created? 
Yep, I think this is a good idea.

> We might be able to add an elasticsearch index that tracks docs by the links
> they contain. (That could be also be interesting for building the kind of
> "backlinks" functionality most early wikis had, too.)
I'm feedbacking :jezdez for input on this (as the problem is fairly annoying).

> But, I don't think we can just move link annotation back into the critical
> path of every view. 
I do agree with Les again. This should be out of the critical path when displaying a page. 

We don't need to have the red links going away immediately, only "quickly" (ideally a few seconds/minutes, but we clearly can live with outdated red links for a few hours).

Comment 8

[BMO Automation]

MDN Web Docs' bug reporting has now moved to GitHub. From now on, please file content bugs at https://github.com/mdn/sprints/issues/ and platform bugs at https://github.com/mdn/kuma/issues/.