Weird wiki link result when missing [\quote]

Original seen here: Mike Tyson to fight YouTuber Jake Paul this July. Yeah, you read that correctly - #106 by Smapti

[quote=“Smapti, post:106, topic:998580, full:true”]

The “child” in question is 27 and his record is 9-1 with six TKOs.

What specifically are you observing as weird?

If you’re talking about the computer mumbojumbo in the Discourse preview box instead of the usual lede paragraph, that happens a lot. Wiki has a few templates for articles that Discourse misunderstands. With the result that Discourse grabs a bunch of CSS and interprets that as the lede and shows it to us. Oops.

I’ve never tried to debug whether it’s Discourse following the standard and wiki is emitting non-conforming junk, or wiki is standard-compliant, but Discourse has a bug. Or both.

This started a couple years ago. Only some articles do it, but that article will always do it.

Here’s the same link, without the misformatted quote:

Looks like it’s just as messed up.

This behaves differently when I quote the original post in the other thread. The link displays correctly when the [quote] is closed. Other things go wrong when editing a reply with the quote in it. Perhaps other problems in the original post.

That is still an extremely vague description of what you’re doing and what results.

It is normal that the url preview box does not render in a quote. That’s true on every site and every post. So if you quote the OP entirely in your post, you’ll see his url cite as just a link to wiki, not a url preview box at that spot in the OP’s post inside your own.

I also do not see any malformed quote tag in @smapti’s post.

It’s also normal that if you have an open [quote] tag with no corresponding closing [/quote], the quote body isn’t formatted as a quote (not indented, not shaded, etc.) until the corresponding closing [/quote] is entered and has its terminating carriage return. Then the preview updates to format the body content between the two tags as a quote. Whether a url’s preview box is rendered in the editor preview is part of that formatting.

Go to the original page. Hit ‘Reply’, then the quote symbol in the upper left that looks like a cartoon dialogue balloon. Notice the ‘[/quote]’ is included and the preview page shows the link correctly. Remove the ‘[/quote]’ and the link is messed up in the preview page. Put the ‘[/quote]’ back and add some text after it and save it. The link will display correctly. Edit your reply and remove the ‘[/quote]’ and the text you added, hit ‘Save Edit’ and the link is messed up again (see code box below). Play around with it and you might get the 402 error I did on some tests.

[quote=“Smapti, post:106, topic:998580, full:true”]

[quote="ColdBrew50, post:103, topic:998580"]
In what world is a child with no experience at boxing such a favorite?

The “child” in question is 27 and his record is 9-1 with six TKOs.


### [Jake Paul | Boxing record](

1.Paul, Jake. You Gotta Want It, .mw-parser-output cite.citation{font-style:inherit;word-wrap:break-word}.mw-parser-output .citation q{quotes:"\"""\"""'""'"}.mw-parser-output .citation:target{background-color:rgba(0,127,255,0.133)}.mw-parser-output a{background:url("//")right 0.1em center/9px no-repeat}body:not(.skin-timeless):not(.skin-minerva) .mw-parser-output .id-lock-free a{background-size:contain}.mw-parser...

testing 1 2 3

Does it happen if you use a normal Wikipedia link, leaving out the .m ? That should at least fix the broken preview box.

There are some interlocking issues here. The first is as I said here:

I’ll try the explanation again this time in more detail with examples …

If you have an incomplete quote tag-pair, so a quote in process like
blah blah
[whatever page preview box appears here]

and that’s all, then the url is not yet inside a quote and Discourse will attempt to build a target page preview box showing that page’s lede. Whether from wiki or any other site.

Conversely, once the quote tag pair is complete
blah blah
(no preview box appears here)
Discourse will NEVER try to create a url preview box containing the lede of the target page when the url is inside a quote tag pair. Whether the target page is at wiki or any other site.

That happens on every link to any page on any site that is within a completed quote tag pair. So there is nothing surprising about the target preview box appearing and disappearing when you add or remove the closing [/quote] tag.

Next point, and this one is independent from my earlier point. …

Yes, when a target page preview box is displayed, AND the target url is a wiki page sometimes you will see the content of the target preview box is mostly computer mumbo-jumbo like:

.mw-parser-output cite.citation{font-style:inherit;word-wrap:break-word}.mw-parser-output .citation q{quotes:“"”“"”“'”“'”}.mw-parser-output .citation:target{background-color:rgba(0,127,255,0.133)}.mw-parser-output a{background:url(“//”)right 0.1em center/9px no-repeat}body:not(.skin-timeless):not(.skin-minerva) .mw-parser-output .id-lock-free a{background-size:contain}.mw-parser…

instead of the content you expect to see, something like:

Jake Joseph Paul (born January 17, 1997) is an American YouTuber and professional boxer. He began his career posting videos on Vine in September 2013 and had amassed 5.3 million followers and 2 billion views before the app discontinued. He played Dirk Mann on the Disney Channel series Bizaardvark for two seasons. Paul launched his YouTube channel in May 2014, and has ranked on the Forbes list as one of the highest paid YouTube creators in 2017, 2018, 2021, and 2023. He also ranked His boxing…

The issue there is simple too. The complete wiki url that @Smapti posted was actually
The #Boxing_record part on the end is an intrapage link to the section of that page labeled “Boxing Record”

That intrapage link fools Discourse most of the time. So it grabs some stuff just after that point in the page thinking it’s the lede. It’s not. With the result that we get a useless preview box. This doesn’t happen on every wiki intrapage link, but it happens on most of them.

Had @Smapti just posted the bare page link
then the wiki lede preview box in @Smapti’s post would have been fine.

But even that would only show as a bare link in your post quoting @Smapti’s post. as explained in my first point.

Hope that is clear. Neither of these things are one-offs. The former item is by design, and the latter one has been a frequent-but-not-every-time irritant for about 2 years now since something changed either at wiki or at Discourse.

IME the .m. for mobile version of the url does not seem to matter. With or without the .m., the preview box is usually messed up if the url ends with an intrapage link and is always fine when the url does not end in an intrapage link.

If the issue already exists then this is another report. The link can be displayed correctly. Whether it’s worth the effort to fix the problem is someone else’s problem.

In that case, I may have workaround. Let’s see:

Yep. That gets a proper preview, but still links to the correct section (in Chrome, at least).

How did I get it? I went to the main page (without the # part at the end) and just highlighted the headline in Chrome. I then right clicked and chose “Copy Link to Highlight.”

Yeah. That’s an abuse of notation. And not much of a solution, unfortunately.

The result is a link to the page and only the page, with a separate Chrome-only instruction to highlight the text you had highlighted. Which highlighted area Chrome will scroll into view. So you get to the right result, with side effects, but for mostly the wrong reason. Welcome to much of web development. Which I know you already know.

In MS Edge, which is also Chromium based, that highlight instruction does nothing.