((Not only dependent on the .m., it also breaks on domains like en.m.wiki.example.com or en.m.example.co.uk))

I think the best option would be a $wgMobileServer.
$wgServer = "en.wikipedia.org";
$wgMobileServer = "en.m.wikipedia.org";

Do domain detection for the mobile site by extracting the host portion of $wgMobileServer, and use it instead of $wgServer as the server starting.

Also include a hook into the mobile url detection code. Let the hook potentially force a true. For example WikiMedia could use the hook to say that if someone accidentally ends up at m.en.wikipedia.org it IS a mobile domain.
Also consider the possibility of /m/ paths. Like http://wiki.example.com/m/Foo http://wiki.example.com/mobile/index.php for mobile site. eg: For those on hosts who can't alias a subdomain.

Actually given that fact, we may want to setup MobileFront end so that by default every url ends up as a ?useformat=mobile url as the default. And switch to path or subdomain style setups when configured to. That way it'll work out of the box without any path or domain aliasing. Just like MediaWiki works out of the box with /index.php?title=Foo urls.

preilly wrote:

(In reply to comment #1)

((Not only dependent on the .m., it also breaks on domains like
en.m.wiki.example.com or en.m.example.co.uk))

I think the best option would be a $wgMobileServer.
$wgServer = "en.wikipedia.org";
$wgMobileServer = "en.m.wikipedia.org";

Do domain detection for the mobile site by extracting the host portion of
$wgMobileServer, and use it instead of $wgServer as the server starting.

I don't think this would work that well. One installation of this extension could possibly serve many wikis as is the case on our production cluster. I think it would be best to support a domain format string.
This way we could support not only domain parts, but paths and query string values as well.

Also include a hook into the mobile url detection code. Let the hook
potentially force a true. For example WikiMedia could use the hook to say that
if someone accidentally ends up at m.en.wikipedia.org it IS a mobile domain.

This is a good idea. We would need to make sure that the hook system will work in the context of an output buffer handler (e.g., after shutdown, etc.)

Also consider the possibility of /m/ paths. Like http://wiki.example.com/m/Foo
http://wiki.example.com/mobile/index.php for mobile site. eg: For those on
hosts who can't alias a subdomain.

This is one of our current goals.

Actually given that fact, we may want to setup MobileFront end so that by
default every url ends up as a ?useformat=mobile url as the default.

This unfortunately will not work for us. It would possibly have caching implementation issues.
But, we might be able to work around that longer term.

And switch to path or subdomain style setups when configured to. That way it'll work out
of the box without any path or domain aliasing. Just like MediaWiki works out
of the box with /index.php?title=Foo urls.

It would work out of the box if we implemented something like:
https://raw.github.com/gist/1590648/86abdf93a99876c609862b28f8dae1b488bded03/MobileFrontend.php

(In reply to comment #2)

(In reply to comment #1)

((Not only dependent on the .m., it also breaks on domains like
en.m.wiki.example.com or en.m.example.co.uk))

I think the best option would be a $wgMobileServer.
$wgServer = "en.wikipedia.org";
$wgMobileServer = "en.m.wikipedia.org";

Do domain detection for the mobile site by extracting the host portion of
$wgMobileServer, and use it instead of $wgServer as the server starting.

I don't think this would work that well. One installation of this extension
could possibly serve many wikis as is the case on our production cluster. I
think it would be best to support a domain format string.
This way we could support not only domain parts, but paths and query string
values as well.

Why would it not? $wgServer already needs to be set to a proper absolute domain. ie: "//en.wikipedia.org", you can't set $wgServer = "//*.wikipedia.org"; in config. And likewise we have $wgCanonicalServer. So I see no reason why we can't also set a $wgMobileServer.

Also include a hook into the mobile url detection code. Let the hook
potentially force a true. For example WikiMedia could use the hook to say that
if someone accidentally ends up at m.en.wikipedia.org it IS a mobile domain.

This is a good idea. We would need to make sure that the hook system will work
in the context of an output buffer handler (e.g., after shutdown, etc.)

Preferably we would actually eliminate the use of an after-shutdown buffer handler hook. This is an ugly hack used by MobileFrontend, it's a bad way forward. MobileFrontend should in the future instead implement it's own skin and use the new 1.19 hook to override the skin. This way MobileFrontend has complete control over the output without any bugs due to custom site skins and has no need to do any output hooking since it is the one creating the output itself.

Actually given that fact, we may want to setup MobileFront end so that by
default every url ends up as a ?useformat=mobile url as the default.

This unfortunately will not work for us. It would possibly have caching
implementation issues.
But, we might be able to work around that longer term.

No it wouldn't have cache implementation issues. This is a 'default setting', just like how $wgArticlePath defaults to "$wgScript?title=$1". WikiMedia would have a mobile domain set so MobileFrontend wouldn't be outputting ?useformat=mobile urls. This setting would just be a default so that it works out of the box and you can configure it to work cleaner.

And switch to path or subdomain style setups when configured to. That way it'll work out
of the box without any path or domain aliasing. Just like MediaWiki works out
of the box with /index.php?title=Foo urls.

It would work out of the box if we implemented something like:
https://raw.github.com/gist/1590648/86abdf93a99876c609862b28f8dae1b488bded03/MobileFrontend.php

The hostname configurability has been added to MobileFrontend. Path handling, however, will be much more difficult to implement as it will require changes to core. I'm marking this issue as resolved and have opened bug #35178 for supporting customizable paths for the MobileFrontned view. Incidentally, I have added support to MobileFrontend to maintain the mobile view from page to page when using "useformat=mobile" in the query string.