Last modified: 2014-03-14 19:55:31 UTC
When using {{fullurl:{{FULLPAGENAME}}|action=x}}, even when visiting commons.m.wikimedia.org, the link generated points to commons.wikimedia.org. Expected behavior: Link pointing to commons.m.wikimedia.org
Could I ask why this is the expected behaviour? It is generating a link to the canonical url. On a mobile phone this will redirect to the mobile site. On a desktop it would redirect to desktop. I don't see why expect different behaviour - am I misunderstanding something? In what cases would it be useful to generate a link that takes you to mobile rather than desktop? If this is useful I could imagine (although not sure how complicated this would be) a new wiki syntax - but that should be a new feature request. {{mobileurl:{{FULLPAGENAME}}|action=x}}
(In reply to comment #1) > On a mobile phone this will redirect to the mobile site. So using protocol relative URLs and fullurl has the same effect? Is this expected behaviour? > On a desktop it would redirect to desktop. It doesn't "redirect". The generated URL points directly to the "desktop" version. > In what cases would it be useful to generate a link that takes you to mobile > rather than desktop? If someone found the mobile version very pleasant and want to use it with a desktop device. If this doesn't fit in your philosophy just close this.
This would essentially meaning changing the content that renders for mobile on desktop and would thus effect our caching infrastructure and performance of mobile. Currently {{fullurl has no idea if you are invoking it from mobile or desktop so always creates a desktop link). The desktop link should be protocol relative. e link to the desktop site should redirect to mobile if and only if the user is on a mobile device. If you think such a feature would be useful please do raise an enhancement bug for the creation of a {{mobileurl: shortcut to do so. However this would fit into a feature request for the MediaWiki parser - not much we can do here in the mobile team - You can raise a bug for this suggestion here: https://bugzilla.wikimedia.org/enter_bug.cgi?product=MediaWiki&component=Parser Thanks for raising this
Formerly, Wikimedia had secure.wikimedia.org and {{fullurl: was aware if the visitor was on that domain, as far as I can remember, thus I thought it can't be that hard. I apologize for my naive thinking.
*** Bug 53180 has been marked as a duplicate of this bug. ***
The problem here is one of the oldest in MediaWiki linking. You can't use a local url to create an 'external' link and you can't use an internal link if you want/need to add query elements: This is not possible: [[Special:UserLogin?returnto=anotherpage]] This would be ideal, but is not possible [{{localurl:Special:UserLogin|returnto=anotherpage}} linkname] So we use this: [{{fullurl:Special:UserLogin|returnto=anotherpage}} linkname] So yes indeed, we used to have to fragment the cache for exactly this problem when we used secure.wikimedia.org I don't think we want to repeat that, but it is something that needs solving in core in order to sustainably avoid that we redirect users left and right. (Note that the fullurl links are frequent in many UI messages for instance. I can't find the ticket for this right now, but I'm sure there is one out there for this problem.
Reopening. Here's an example of how this can be an actual issue for a mobile user: 1. Go to en.m.wikipedia.org/wiki/NoExisto (on either a mobile device or desktop) 2. Click "Start the NoExisto article" Expected result: You get the mobile editing interface. Actual result: You get the desktop editing interface. Yes, the cache would be fragmented, but only in the rare cases that a page is using fullurl to work around the problem described by Derk-Jan.
*** Bug 62640 has been marked as a duplicate of this bug. ***
