Pin Eight talk:Manual of Style/Links

From Pin Eight
Jump to: navigation, search

Suggestions for non-Main TV Tropes namespaces[edit]

The inconsistent use of trope: and tvtropes: interwiki prefixes is due to trope migration. --Eighty5cacao (talk) 03:24, 8 October 2014 (UTC)

Would it be possible to write a redirection script on your server and retarget the trope: interwiki prefix there, similar to http://pineight.com/redirector.php?site=trope&title=$1? The script should be able to handle [[trope:DarthWiki/UnpublishedWorks]] and [[trope:DarthWiki.UnpublishedWorks]] or (obviously) default to the Main namespace if none is explicitly specified.

Or does your GoDaddy hosting plan not allow such things, in which case we might want to create a template that contains something like <includeonly>[http://tvtropes.org/pmwiki/pmwiki.php/{{{1|Main}}}/{{{2}}} {{{3}}}]</includeonly><noinclude>documentation here</noinclude>? Eighty5cacao 11:24, 17 July 2011 (MST)

Please disregard the first part of this suggestion, as that is probably too much trouble. I remembered that <span class="plainlinks"> can be used to hide the external-link icon, which would achieve the desired effect for readers but wouldn't save keystrokes for editors. Should this be mentioned in the context of non-Main TV Tropes linking? Eighty5cacao 12:07, 17 July 2011 (MST)
For the record, this has been implemented at User:Eighty5cacao/sandbox/Template:Trope. Eighty5cacao 16:16, 31 January 2012 (MST)
My hosting plan certainly allows such things; otherwise, #REDIRECT wouldn't work. --Tepples 11:57, 31 August 2012 (MST)
But #REDIRECT is a feature of the MediaWiki software, and my original proposal involved a script separate from MediaWiki. What part of it do you need me to clarify, if any? I acknowledge that some MediaWiki extensions might turn #REDIRECT into HTTP 3xx, but that doesn't apply to us. (I may as well revert the relevant part of the strikethrough.) Eighty5cacao 23:30, 1 September 2012 (MST)
Anything the MediaWiki software can do, software that I write myself can do too. A redirect script is just a short PHP program that calls header("Location: $url");. (stretches for an edge case) The only way it'd theoretically have a problem is if MediaWiki were run in some sort of sandbox with enhanced privileges within the sandbox that customer-written web applications lack. Mostly it's a matter of getting around to writing and testing such a script that converts whitespace to a following capital letter (so that [[trope:we are as mayflies]] becomes the same as [[trope:WeAreAsMayflies]]) and checks whether the page title needs Main/ prepended. --Tepples 07:26, 2 September 2012 (MST)
Done, I think. Try tvtropes:we are as mayflies and tvtropes:Laconic/mayfly-December romance. --Tepples 12:51, 24 October 2012 (MST)
Yes, I am reasonably sure that things are working as intended. Eighty5cacao 17:53, 24 October 2012 (MST)

Requested move[edit]

Pin Eight:LinksPin Eight:Manual of Style/Links

To match the convention established at Pin Eight:Manual of Style/RFC 2119, as well as Wikipedia's MOS

I could have done the move myself, but I wanted to know if you have objections. Eighty5cacao 13:56, 30 January 2012 (MST)

If I do not receive objections within 24 hours of this edit, I will assume there are none, and I will move the page myself. I am aware that Pin Eight:Linking will become a double redirect and will need fixing. Eighty5cacao 16:16, 31 January 2012 (MST)

Cracked Photoplasty: Slideshow view suggested[edit]

was: Cracked Photoplasty no longer supports article view

See title. I first noticed this when looking at 23 Painfully Honest Valentine's Day Cards. Observe that the link to enable article view is not present. I tried manually adding ?view=article to the URL and noticed that it had no effect.

The point is, the MoS should instruct users that they SHOULD link to the specific image page that they want. A quick check of Special:LinkSearch/www.cracked.com shows that the only noncomplying page is my TODO list; I'll fix that ASAP. Eighty5cacao 12:59, 13 February 2012 (MST)

Some comments to the article speculate that only this specific Valentine's Day Photoplasty has disabled Article View because Article View would have been incompatible with the way "send it to your loved one" was implemented. --Tepples 14:15, 13 February 2012 (MST)
Oh, ok. I did read some comments, just not carefully enough. As Bugzilla would call it, RESOLVED NOTABUG for the specific Photoplasty in question.
Also, I spot-checked some other Photoplasties from February 2012, and I glanced at the wrong spot in my attempt to look for the "Article View" link. Hence VERIFIED INVALID for the material redacted from the first paragraph of the OP. Eighty5cacao 14:35, 13 February 2012 (MST)
As of right now, the suggestion looks like instruction creep. But I'll keep it in mind should I introduce guidelines about linking to specific sites. --Tepples 15:00, 13 February 2012 (MST)

Yeah, I had some nagging doubts about that but should have acted upon them sooner. This means User:Eighty5cacao/TODO or its talk page would probably have been a better venue, and even there it would probably have been WONTFIX at best. Eighty5cacao 15:15, 13 February 2012 (MST)

That comment ended up being right. The latest Photoplasty has Article View right where I expected it. --Tepples 12:13, 15 February 2012 (MST)

HTTPS for YouTube[edit]

Regarding this edit:

Should we change all YouTube links to use HTTPS, or should we change the link you just added to be unencrypted HTTP (for consistency)?

While I understand the importance of "HTTPS everywhere," YouTube video pages almost always have mixed content. At least the video bitstream itself is unencrypted* (the fact that Firefox doesn't complain about this when the Flash player is used is a bug), though other issues crop up occasionally. We want to avoid unnecessarily panicking readers, right?

*...though, I see that YouTube has recently changed their CDN domains from foo.bar.baz.c.youtube.com to foo---bar---baz.c.youtube.com, possibly to facilitate future HTTPS support? Eighty5cacao 13:08, 1 August 2012 (MST)

Do Chrome and IE complain? --Tepples 13:52, 1 August 2012 (MST)
A previous version of Chrome appears to have had the same behavior that Firefox does now. However, there are reasons I don't currently have Chrome handy for testing, and I haven't yet bothered with IE.
My important point, though, was that "other issues crop up occasionally." Specifically, on some monetized music content, there are obligately unencrypted images near the "Buy this song from..." links. (This includes some Linkin Park songs already mentioned on this wiki.) Informational pages and all_comments pages do seem to have a better chance of being fully encrypted. Eighty5cacao 23:20, 5 August 2012 (MST) (last edit 23:01, 7 August 2012 (MST))
The reason my recent links to YouTube are HTTPS in the first place is that I use the HTTPS Everywhere extension in Firefox on my laptop, which means any YouTube link that I copy out of the location bar will use HTTPS. Perhaps HTTPS Everywhere has a rule for YouTube only on those browsers with the bug 369503 misbehavior, so that it can have as much of the connection be HTTPS as possible. --Tepples 05:26, 6 August 2012 (MST)
I use HTTPS Everywhere too, but I've always put in the work to unsecure the links on the way into the wiki, for the reason discussed here. I edit only from desktop platforms, so I don't have keyboard form factor as an excuse for laziness.
Rulesets can have a platform field, of which firefox and chrome are among the valid values, but there is no mechanism to detect specific browser versions. The YouTube ruleset has no such field.
The "obligately unencrypted images" are from third-party servers not covered by said ruleset.
I guess we should drop the issue until we get around to investigating the behavior of those other browsers. Eighty5cacao 22:50, 7 August 2012 (MST) (last edit 14:22, 10 August 2012 (MST))

For what it's worth, some of the aforementioned *.c.youtube.com servers started supporting HTTPS. HTML5 videos on channel (user) pages use this by default (edit: no longer true as of 21:26, 3 October 2013 (UTC)), but my attempt to write an HTTPS Everywhere rule broke videos in all other situations. (It could be an issue with CSP, CORS, and/or the special meaning of some query parameter.) Also, Firefox's current mixed-content blocking system seems to detect the Flash requests fine; the bug in question is being repurposed to deal specifically with POST requests made by plugins. --Eighty5cacao (talk) 04:37, 26 September 2013 (UTC) (+ 01:09, 1 February 2014 (UTC))

For the record, the *.c.youtube.com domains have moved to *.googlevideo.com. No new HTTPS support. --Eighty5cacao (talk) 22:18, 7 November 2013 (UTC)
If HTTPS support for *.googlevideo.com remains in place for a week (a couple days from now, i.e. 01:09, 8 February 2014 (UTC)), we can probably start hard-coding YouTube links to https. --Eighty5cacao (talk) 01:42, 7 February 2014 (UTC)
Resolved, I guess (but don't make edits solely to secure existing links). --Eighty5cacao (talk) 18:11, 9 February 2014 (UTC)

For the record: Nothing has changed about HTTPS support on pages, but some recent tickets on the Tor Project bug tracker (following the release of HTTPS Everywhere 3.5 and 4.0development.16) suggest that the video streams officially support HTTPS only for the HTML5 player and not Flash. I have not personally used the Flash player in quite a while, so I have not verified what exactly is causing the breakage. --Eighty5cacao (talk) 18:59, 19 April 2014 (UTC)

HTTPS for DeviantART[edit]

Do not revert any existing edits without a good reason. For new edits:

HTTPS is fine for hotlinking individual images, but for pages, wait until there is an official statement from the webmaster or the HTTPS-E ruleset is enabled by default.

Although it's still true that everything works, some images on some user pages aren't secured by default for some reason. --Eighty5cacao (talk) 21:51, 22 January 2016 (UTC)

HTTPS support on other sites[edit]

--Eighty5cacao (talk) 22:38, 20 March 2014 (UTC) (+ 00:45, 16 February 2015 (UTC))

All the Tropes[edit]

I'm thinking of eventually porting trope: from TV Tropes to All the Tropes. TV Tropes switched from a license for free cultural works (Creative Commons BY-SA, the same license as Wikipedia and Uncyclopedia) to a non-free license (Creative Commons BY-NC-SA) in July 2012. This by itself was an infringement of the copyright of all contributors prior to July 2012, including my copyright. But it has come to my attention that to hide this infringement, TV Tropes has been requiring copyright assignments for all contributions over the past six months. All the Tropes is a TV Tropes fork starting from the last free site dump. (Source: Irregular Express, via Slashdot) And it supports HTTPS. But the transition will require editing every page that includes a trope: interwiki link because of different article naming conventions between PmWiki and MediaWiki. --Tepples (talk) 21:07, 29 May 2014 (UTC)

Can the mass editing wait until we both have time to review All the Tropes to determine how up-to-date it is with respect to namespace policy and other matters of article titling? A cursory glance at AtT's RC reveals the following issues: Works are not namespaced by media categories; YMMV and Headscratchers are subpages instead of namespaces. MediaWiki's category system makes both of these nonissues for human browsing, but they would impede a simple automated conversion of titles.
Could you migrate tvtropes:WMG/TheTimeMachine to AtT, as a temporary userspace copy if necessary, to demonstrate your understanding of their best practices?
If necessary, we may need to move the old "trope:" prefix to something like oldtrope, instead of discarding it entirely, once we move allthetropes to trope. --Eighty5cacao (talk) 21:45, 29 May 2014 (UTC)
Works with ambiguous titles appear to be namespaced in Wikipedia fashion. See, for example, allthetropes:Blur, which links to Blur (video game) and Blur (band). The present licenses are incompatible, so you can't migrate an entire page unless all post-July 2012 contributors explicitly consent, but you can migrate your own edits, as I did at allthetropes:The Time Machine/WMG. In any case, I'd move the existing trope: interwiki to tvtropes:. --Tepples (talk) 01:31, 30 May 2014 (UTC)
Again, sorry for not thinking hard enough about licensing (and several other things).
Should trope.php (the target of tvtropes:) be changed to show a user-visible warning (with META REFRESH at your discretion) rather than returning 3xx? --Eighty5cacao (talk) 02:46, 30 May 2014 (UTC)
In other words, the opposite of the "no_outbounds" interstitial on TV Tropes, I take it. I'll think over what sort of wording I could use on the interstitial. --Tepples (talk) 03:15, 30 May 2014 (UTC)
As of two minutes ago, trope.php is an interstitial explaining the ongoing infringement, the alternative, and the migration. --Tepples (talk) 16:28, 30 May 2014 (UTC)

Digression: Orain's MediaWiki configuration[edit]

It appears that the search box on All the Tropes always brings up the full search results instead of going directly to an exact match when one is present. This differs from the Wikipedia and Uncyclopedia behavior. Do registered users have a preference to change this? --Eighty5cacao (talk) 02:46, 30 May 2014 (UTC)

I couldn't find one. Perhaps it's an attempt to approximate the TV Tropes search behavior of using Google Site Search without any sort of "I'm Feeling Lucky" functionality. --Tepples (talk) 03:15, 30 May 2014 (UTC)

Stack Exchange short URLs[edit]

To clarify "do not use shortened URL, as server tries to redirect to http even though the target supports https":

The redirect location the server sends for https://worldbuilding.stackexchange.com/q/542/601 is http://worldbuilding.stackexchange.com/questions/542/how-would-society-be-different-in-a-sentient-species-that-does-not-care-for-its, but https://worldbuilding.stackexchange.com/questions/542/how-would-society-be-different-in-a-sentient-species-that-does-not-care-for-its loads fine.

There is no intermediate redirect to http://worldbuilding.stackexchange.com/q/542/601 and therefore no redirect loop with HTTPS Everywhere.

My guideline is intended mainly to preserve security for readers without HTTPS Everywhere, for whom protocol-relative or hardcoded-https URLs matter in the first place.

I have not verified whether the behavior is different for logged-in users, which would explain any failure on your part to reproduce this. (As usual, it may help to examine with Live HTTP Headers if you are using Firefox.) --Eighty5cacao (talk) 03:13, 8 October 2014 (UTC)

If I copy the URL out of the address bar, I get the question, not an individual answer. Do I need to click through before copying the URL, as I already need to do for Google? --Tepples (talk) 23:55, 12 July 2015 (UTC)
I have discovered that this issue has already been reported and seen by Stack Exchange developer Adam Lear♦, but with no (public) timeline to fix. --Tepples (talk) 00:13, 13 July 2015 (UTC)
I can reproduce the lack-of-specific-answer problem with the test case mentioned above, but I'm not yet sure why "copy[ing] the URL out of the address bar" would make a difference. Perhaps the specific answer to the question above was deleted? All other links I've encountered recently (e.g. https://linguistics.stackexchange.com/a/6998/2712) do successfully redirect to an anchor; the anchor is included in the server's 3xx target and is not added by JavaScript after the fact. --Eighty5cacao (talk) 05:34, 13 July 2015 (UTC)
The difference is that there's no way for me to get the long URL for an answer without copying and pasting the URL from the "share" box to the URL bar. When I click "share", the site gives me the short URL, which (as the bug report states) redirects from HTTPS to HTTP. In addition, only short URLs contribute to the Announcer, Booster, and Publicist badges. Or are these badges considered harmful in the same way as affiliate links? --Tepples (talk) 19:47, 13 July 2015 (UTC)
Again, I'm not familiar enough with Stack Exchange in general to make an informed comment on any of that.
Do I need to start reverting any of my edits now, or should that wait for the bug to be fixed? --Eighty5cacao (talk) 20:31, 13 July 2015 (UTC)
No reverts are needed. --Tepples (talk) 22:48, 13 July 2015 (UTC)

HTTPS status on external sites (since 2017)[edit]

No reply needed except for urgent questions (maybe this should have gone on a user subpage...)

Additions (working)[edit]

Ars Technica[edit]

(Existing links)

Ars Technica used to redirect most pages to http for non-logged-in users. This is no longer the case. --Eighty5cacao (talk) 00:09, 31 January 2017 (UTC)

The Verge[edit]

(Existing links)

It appears that they no longer redirect to http. All of our existing linked articles seem fine, except that the oldest one has some mixed images and blocked YouTube embeds. --Eighty5cacao (talk) 05:00, 22 March 2017 (UTC)

Polygon[edit]

(Existing links – only one)

See above notes for The Verge, not including the part about older articles using a different layout. I haven't checked any other Vox Media properties yet. --Eighty5cacao (talk) 04:27, 30 March 2017 (UTC)

The Daily WTF[edit]

(Existing links)

Related domains known to be broken, with explanation of why they are not major issues:

  • live.thedailywtf.com - cert mismatch (Amazon S3 alias) - used in some articles for embedded audio
  • please-support.thedailywtf.com - certificate mismatch - used in some older articles for advertising content
  • img.worsethanfailure.com - cert mismatch - used in some older articles; content equivalent to img.thedailywtf.com

There may be mixed-content images in some older articles. --Eighty5cacao (talk) 20:21, 9 July 2017 (UTC) (+ 15:22, 12 July 2017 (UTC))

DeviantArt[edit]

The previous webmaster request to disable HTTPS Everywhere coverage appears to have been rescinded (ticket #11834, citing this blog post by DeviantArt staff). --Eighty5cacao (talk) 19:10, 13 August 2017 (UTC)

Blogger[edit]

(Existing links)

Everything in *.blogspot.com seems to have working HTTPS, but I stopped my previous cleanup effort when I encountered a blog that had become private. --Eighty5cacao (talk) 06:54, 24 May 2018 (UTC)

Know Your Meme[edit]

(Existing links)

Further evaluation and comments to come soon.

Most links to resources are absolute-https, so no obvious mixed-content problems. --Eighty5cacao (talk) 19:30, 10 July 2018 (UTC)

No action needed[edit]

Fox News[edit]

(Existing links)

www.foxnews.com nominally responds fine over https, but no HTTPS Everywhere coverage is enabled yet, link rel="canonical" still says http, and there are probably quite a few mixed-content issues I haven't noticed because I usually inject an upgrade-insecure-requests CSP and can't be bothered to finish digging through View Source. --Eighty5cacao (talk) 01:26, 7 January 2018 (UTC)

Hardcore Gaming 101 (old)[edit]

This site, along with the rest of Konfiskated Teknologies Network, now enforces HTTPS at least via 3xx. However, it contains many outdated absolute references to http://www.hardcoregaming101.net for images, scripts, and stylesheets; these are erroneous because the new Hardcore Gaming 101 doesn't yet support HTTPS and lacks cool-URI redirection for the files in question anyway. --Eighty5cacao (talk) 06:54, 24 May 2018 (UTC)

BBC[edit]

This discussion is specifically about www.bbc.com; although the same is presumably true for www.bbc.co.uk, I have not tested it extensively because most pages redirect to www.bbc.com for US viewers.

Most articles currently seem to enforce HTTPS at least via 3xx, but implementation mistakes seem to cause redirect loops on the domain's homepage as well as articles in the "future" section. --Eighty5cacao (talk) 22:29, 17 June 2018 (UTC)

The above appears not to be true for all users; it is possible that cookies are used to randomly flag some users for an HTTPS trial. --Eighty5cacao (talk) 16:15, 24 June 2018 (UTC)
The homepage still redirects to HTTP, but it no longer loops. HTTPS support is supposedly considered official for articles, though. I haven't retested articles in the "future" department. --Eighty5cacao (talk) 23:31, 13 August 2018 (UTC)

Removals (broken)[edit]

MAME xtal.h and xtal.cpp[edit]

I am aware of most of the crystal-oscillator values being moved to xtal.cpp while xtal.h still exists for other reasons - still need to look into the details - but it will be a day or two before I can finish dealing with the links here. --Eighty5cacao (talk) 14:46, 23 January 2018 (UTC)