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)

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)

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)

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)

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)

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.

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)

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)

Here are the current contents of the ruleset. According to the commit history, the request to disable the ruleset by default was a little over two years old, and the site has been working well enough for a little over a year.

By "working well enough" I mean that there is no mixed active content (except possibly for ads/tracking which I have blocked) and that all user-created image content is already protocol-relative (there are sporadic mixed-content problems with emoticons and some other "static" images though, though they are securable and secured by the ruleset). --Eighty5cacao (talk) 22:18, 7 November 2013 (UTC) (+ 07:24, 21 November 2013 (UTC))

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)

Untergrund.net: HTTPS has been an official feature since September 2005, according to their homepage. This may be useful when linking to Shiru's projects. No HTTPS Everywhere ruleset exists yet, but it appears at least for Shiru's subdomain that internal links are relative and there is no mixed active content.

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)

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)

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)

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)

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)

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)

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)

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)