https://bugzilla.wikimedia.org/show_bug.cgi?id=34144
--- Comment #3 from Daniel Friesen <mediawiki-b...@nadir-seen-fire.com> 2012-02-02 19:45:14 UTC --- (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 -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
