780324 - Kuma: domxref template links have class="external" instead of class="internal"

Status: RESOLVED FIXED

(developer.mozilla.org Graveyard :: Editing, defect)

Description

[Dan Callahan [:callahad]]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Firefox/17.0
Build ID: 20120727030508

Steps to reproduce:

Attempted to use {{ domxref("navigator.id.watch()") }} in a page, https://developer.mozilla.org/en-US/docs/BrowserID/Quick_Setup


Actual results:

The reference was rendered as:

<code><a class="external" href="http://developer.mozilla.org/en-US/docs/DOM/navigator.id.watch">watch()</a></code>


Expected results:

The reference should have been rendered as:

<code><a class="external" href="http://developer.mozilla.org/en-US/docs/DOM/navigator.id.watch">watch()</a></code>

(Note the differing class: "internal" vs. "external")

Comment 1

[Dan Callahan [:callahad]]

And in my copying and pasting I totally botched the expected results. Let's try this again:


Expected results:

The reference should have been rendered as:

<code><a class="internal" href="http://developer.mozilla.org/en-US/docs/DOM/navigator.id.watch">watch()</a></code>

(Note the differing class: "internal" vs. "external")

Comment 2

[Matthew N. [:MattN]]

A force refresh (holding shift while refreshing) on that page seems to have fixed the issue.  It probably wasn't picking up Sheppy's fix to that template for some reason.  I noticed this on other pages as well where it seems like editing the page doesn't update the cache of the templates for that page.  Sheppy's change to Template:domxref was two days ago so any cache of the template probably should have updated by now.

Comment 3

[Dan Callahan [:callahad]]

Huh, you're right. Yet I completely rewrote the entire contents of that page just moments before filing this bug, so the client-side cache should have been completely fresh.

Weird.

Marking as resolved.

Comment 4

[Matthew N. [:MattN]]

Doing a force refresh sends appropriate HTTP headers so the server side cache is also invalidated.  I think there is a bug here or at least the problem should be investigated.  After editing some more pages it actually seems like the links are marked as external right after an edit and then doing a force refresh afterwards fixes it.

Comment 5

[John Karahalis [:openjck]]

Glad to hear everything worked out. In fact, right after launch we started invalidating the cache of every article on the MDN. From what I understand this could take a while, so you probably got to that page before our process did.

We do have a few bugs about caching. I have a lot of bugmail at the moment, but I will get around to finding and linking to those shortly.

Comment 6

[Yu-Tang]

I'm not sure if these templates have the same issue or separate one.
It seems to me that they maybe resemble each other.

https://developer.mozilla.org/en-US/docs/XUL/Findbar
Last updated by: Wladimir_Palant, Aug 15, 2012 1:39:47 AM
{{ XULPropInheritedWide() }}
{{ XULMethInheritedWide() }}

https://developer.mozilla.org/en-US/docs/XUL/Textbox_%28Toolkit_autocomplete%29
Last updated by: Imphil, Aug 6, 2012 6:07:59 AM
{{ XULMethInherited() }}

Both pages were updated after Kuma launch.

Comment 7

[John Karahalis [:openjck]]

Marking this one as closed, since the domxref template issue has been fixed. Opened bug ... for the underlying issue mentioned in comment 4.

Yu-Tang: Do you mean that those templates should be merged?

Comment 8

[John Karahalis [:openjck]]

Bug 787084, that is.

Comment 9

[Yu-Tang]

(In reply to John Karahalis [:openjck] from comment #7)
> Yu-Tang: Do you mean that those templates should be merged?

I meant that those templates generates inter-wiki links with "external" class too.
I looked them again and found out they fixed.
Thank you.