Red links stay red even when the page is created

NEW
Unassigned

Status

developer.mozilla.org
Wiki pages
--
major
4 years ago
4 years ago

People

(Reporter: teoli, Unassigned)

Tracking

(Depends on: 1 bug)

Details

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

Attachments

(1 attachment)

(Reporter)

Description

4 years ago
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.
(Reporter)

Updated

4 years ago
Severity: normal → major
Component: General → Wiki pages
(Reporter)

Comment 1

4 years ago
Created attachment 8438294 [details]
Screen Shot 2014-06-11 at 10.57.32.png

Red link that should have been blue.
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?
Flags: needinfo?(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.
Flags: needinfo?(lorchard)

Comment 4

4 years ago
This should be prioritized and added to the op 10 list - we've received complaints from users.
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.
(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.
Depends on: 813484
(Reporter)

Comment 7

4 years ago
(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).
You need to log in before you can comment on or make changes to this bug.