775590 - kumascript: wiki.pageExists is not working

Status: RESOLVED WONTFIX

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

Description

[Jeremie Patonnier :Jeremie]

I tried to use wiki.pageExists on this template : https://developer-new.mozilla.org/en-US/docs/Template:SVGAttr

if wiki.pageExists is true, SVGAttr should produce a link with no class (the link will be blue).
if wiki.pageExists is false, SVGAttr should produce a link with the class "new" (that make the link to be red)

I use SVGAttr extensively on that page : https://developer-new.mozilla.org/en-US/docs/SVG/Attribute


Actual result :

All the link produce with SVGAttr are blue because wiki.pageExists always return true (I had to make some dirty test to be sure of that)

Expected result :

wiki.pageExists should return true or false depending on each page real status.

For example, {{SVGAttr("onbegin")}} should produce a link with the class "new" because the page https://developer-new.mozilla.org/en-US/docs/SVG/Attribute/onbegin does not exist yet.

Comment 1

[Eric Shepherd [:sheppy]]

This seems to work in at least some cases. Are we certain that the SVGAttr doesn't have some kind of bug?

Comment 2

[Les Orchard [:lorchard]]

I *think* this has been fixed by bug 776618, reopen if not.

Comment 3

[Eric Shepherd [:sheppy]]

Not fixed. See https://developer-new.mozilla.org/en-US/docs/SVG/Attribute and click "overline-position", which doesn't exist even though the link seems to indicate that it does given the link color.

Comment 4

[Les Orchard [:lorchard]]

Crap. No idea why this is still not working.

Is there any chance we could disable the use of wiki.pageExists in templates, if only temporarily? It's one of the most expensive things templates do right now, second only maybe to including content from other pages.

Each call of wiki.pageExists makes an HTTP HEAD request from KumaScript to Kuma to determine whether a page exists. And, on a page like SVG/Attribute or CSS/CSS_Reference, this translates to hundreds of HTTP requests to build a page at around 100-200ms a piece with only limited parallelization of requests. 

Probably need to rethink how wiki.pageExists works in general, but don't have any good ideas at the moment

Comment 5

[David Walsh :davidwalsh]

Looking at this now...

Comment 6

[Les Orchard [:lorchard]]

More thinking, since I'm really struggling with this performance issue: Is wiki.pageExists mainly used in templates to decide whether to generate a link to a page (true) or a link to create a page (false)?

If so, then:

1) The wiki will send a user to create a page on 404 automatically, so we don't need to construct page-creation links in templates.

2) If link color is the main concern here, to indicate pages in need of creation, we could look into replacing this with a Kuma-side thing rather than doing it with expensive things in KumaScript templates.

A Kuma-side solution would look like:

* Build a content filter in Kuma which looks for links with class="wiki"; 
* check the DB for existence of those links; 
* add a class of "new" or "needs-creation" for links not matching documents;
* add CSS styles to change "new" link colors.

I bet doing it all on the Kuma side rather than in templates would improve performance by several orders of magnitude.

Comment 7

[Les Orchard [:lorchard]]

(In reply to Les Orchard [:lorchard] from comment #6)
 
> * Build a content filter in Kuma which looks for links with class="wiki"; 

(Or even any links whose URLs start with "/", to cover anything anywhere on the local site)

Comment 8

[Eric Shepherd [:sheppy]]

This is always or almost always used to make sure the right link color is used. MindTouch was not good at getting this right, and right now, neither is Kuma. If we can fix it in Kuma without having to script it, that would be even better.

Comment 9

[Les Orchard [:lorchard]]

Adding this to the sprint. Moving this out of kumascript should be a huge performance gain and ideally done before launch.

Comment 10

[Les Orchard [:lorchard]]

https://github.com/mozilla/kuma/pull/458

If/when this is merged, Kuma will automatically scan every link on a page just before displaying it. 

If a link looks like "/{locale}/docs/{path}", it will check for existence of a corresponding document. If the document is not found, a class="new" will be added. If the link is an absolute URL to the site, the same applies

As a bonus feature, if the URL looks like an external link, class="external" will be added.

Comment 11

[Les Orchard [:lorchard]]

(Ironically, it occurs to me that this is what :sheppy thought Kuma was already doing when he started tearing out template code using wiki.pageExists a week or so ago)

Comment 12

[Eric Shepherd [:sheppy]]

Yeah, that's true. :)

Comment 13

[[github robot]]

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

https://github.com/mozilla/kuma/commit/fc5fc3eba396f509e9a847b5dc23ef1b17b5eda8
bug 775590: Annotate links for "new" or "external" pages on document view

https://github.com/mozilla/kuma/commit/c7528ce87893233a236c17644239926c01129a29
Merge pull request #458 from lmorchard/annotate-links-775590

bug 775590: Annotate links for "new" or "external" on document view

Comment 14

[Les Orchard [:lorchard]]

I'll call this fixed: 

* wiki.pageExists always returns true, at least for now: https://developer-new.mozilla.org/en-US/docs/Template:Dekiscript:Wiki

* But, that's okay, because the Kuma-side link filter is working. "overline-position" has class="new" (and is colored red) on https://developer-new.mozilla.org/en-US/docs/SVG/Attribute

Comment 15

[Les Orchard [:lorchard]]

(Oh yeah, and that SVG/Attribute page renders SO much faster, now)

Comment 16

[Jean-Yves Perrier [:teoli]]

That's working very well. Thanks Les. Our poor-man dashboards are working again.

And we will be able to simplify some templates.

Made my day!

Comment 17

[Jeremie Patonnier :Jeremie]

Thanks, this exactly what was really needed :D

However, because this solution does not fix the original issue and because the cost of such a functionality is high, maybe a WONTFIX would be more appropriate for this specific bug?

Comment 18

[Jean-Yves Perrier [:teoli]]

I agree with Jeremie. And we can reopen it if, one day, we find a real use case for it.

Any way to have the complete list of kumascripts using it, so that we can fix them?