kumascript: wiki.pageExists is not working

RESOLVED WONTFIX

Status

developer.mozilla.org
Wiki pages
RESOLVED WONTFIX
6 years ago
5 years ago

People

(Reporter: Jeremie, Assigned: lorchard)

Tracking

Details

(Whiteboard: s=2012-08-01 p=3)

(Reporter)

Description

6 years ago
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.
This seems to work in at least some cases. Are we certain that the SVGAttr doesn't have some kind of bug?
Blocks: 773295
(Assignee)

Comment 2

6 years ago
I *think* this has been fixed by bug 776618, reopen if not.
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
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.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(Assignee)

Comment 4

6 years ago
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
Looking at this now...
(Assignee)

Comment 6

6 years ago
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.
(Assignee)

Comment 7

6 years ago
(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)
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.
(Assignee)

Comment 9

6 years ago
Adding this to the sprint. Moving this out of kumascript should be a huge performance gain and ideally done before launch.
Whiteboard: s=2012-08-01 p=3
(Assignee)

Comment 10

6 years ago
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.
(Assignee)

Comment 11

6 years ago
(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)
Yeah, that's true. :)

Comment 13

6 years ago
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
(Assignee)

Comment 14

6 years ago
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
Status: REOPENED → RESOLVED
Last Resolved: 6 years ago6 years ago
Resolution: --- → FIXED
(Assignee)

Comment 15

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

Updated

6 years ago
Assignee: nobody → lorchard
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!
(Reporter)

Comment 17

6 years ago
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?
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?
Resolution: FIXED → WONTFIX
Version: Kuma → unspecified
Component: Website → Landing pages
Product: Mozilla Developer Network → Mozilla Developer Network
You need to log in before you can comment on or make changes to this bug.