Talk:Mobile support in MediaWiki core

About this board

Add meta viewport width=device-width tag to each page right away

Jidanni (talkcontribs)

Wouldn't a simple <meta name = "viewport" content = "width=device-width"> added to the header of each page make all Mediawiki sites look better on mobile right away? It wouldn't affect non mobile browsers too. Currently one must go to Manual:FAQ#How do I add meta tags? lengths or add extensions to do that. No simple LocalSetting.php way either.

Dantman (talkcontribs)

Current skins aren't built to handle mobile device widths. Doing that would cover tabs in some skins and make sidebars cramp the content.

For viewport to work a skin has to be custom developed to be responsive.

FreedomFighterSparrow (talkcontribs)
Jidanni (talkcontribs)

OK I have installed MobileFrontend. (talkcontribs)

In case anyone is still looking, here is one solution:

$out->addHeadItem('viewport', '<meta name="viewport" content="width=device-width">');

Reply to "Add meta viewport width=device-width tag to each page right away"

Here's what Google Webmaster Tools has to say

Jidanni (talkcontribs)
From: Google Webmaster Tools Team <>
Subject: Fix mobile usability issues found on
To: webmaster of

Google systems have tested 231 pages from your site and found that
100% of them have critical mobile usability errors. The errors on
these 231 pages severely affect how mobile users are able to
experience your website. These pages will not be seen as
mobile-friendly by Google Search, and will therefore be displayed and
ranked appropriately for smartphone users.

Fix this now:

1. Find problematic pages					
View a report of the non-mobile-friendly pages found on your site, and
the issues discovered:

2. Learn about mobile-friendly design			
There are a variety of techniques you can use to make your site
mobile-friendly. Specifically, look for information about the issues
brought up in Webmaster Tools:

3. Fix mobile usability issues on your site
Fix the issues preventing your site from being mobile-friendly.

Not sure how to proceed?

* If your site is built with software like Wordpress or Joomla (also
known as "Content Management System" or CMS), read the easy steps to
make a CMS mobile-friendly:

* Read more about building mobile-friendly websites on our Developer site:

* Ask a question in our forum for more help - mention message type

Therefore please make MediaWiki ready for mobile. Yes I tried the extensions and they weren't up to par.

Ckoerner (talkcontribs)

What was your experience using MobileFrontend? Does using something like that or a responsive MediaWiki skin change your report?

What didn't work for you with what you tried? I'd love to know more about this report and think that a little more information would be helpful for everyone.

Jidanni (talkcontribs)

Thanks. I recall that at least last year whatever convenience MobileFrontend provided was offset by ... well I forgot the details, but I ended up getting rid of it. Also if it was so good then why isn't it standard (built-in) yet? Which leads to the question of why can't what WikiPedia is using for mobile just allow not hardwiring and allow one to use it for any MediaWiki wiki. I bet it would work 99% OK. But alas, my idea was not accepted. Not for even trial purposes.

Anyway I'm just saying that Google proves that MediaWiki sites look terrible and thus get their rankings chopped too, and there's still no OFFICIAL solution that MediaWiki dares distribute because those solutions are not ready for prime time... (OK if they are then why aren't they built in yet?) and there is no heat on MediaWiki's neck because WikiMedia sites all have their own fix so MediaWiki wiki users are left out in the cold.

Also here's an idea for how you can test how my site would look with MobileFrontend etc. stuff installed, without "imperiling" my other users: Start putting MobileFrontend in trunk, so my svn updates would pick it up. However -- only have it kick in when a browser with User-Agent: "MediaWiki MobileFrontend etc. test team browser/0.1" was browsing! Then you could check every nook an cranny (and sidebar!), to see if mobile users would still get the most out of my site. Thanks!

I might finally even help out again in that case.

Anyway, take Google's word for it, you've got a BIG problem. Can't just stay back in year 2006...

Dantman (talkcontribs)

Jidanni, MobileFontend isn't part of core because a good portion of the development community is trying to move away from shoving everything in core bloating it more and more and is even attempting to move various features out of core. Installing extensions for key features is nothing new, MediaWiki has been that way ever since ParserFunctions was created.

You tried MobileFrontend a whole year ago when and decided to rant now without bothering to consider that in that entire year MobileFrontend has been developed further?

MobileFrontend's old hardcoding issues should already be gone. It worked fine when I installed it on a staging wiki for a client project.

Also, wtf are you trolling about svn and trunk for. We ditched the outmoded subversion over 2 years ago. All MediaWiki's development is done using Git.

Jidanni (talkcontribs)

Oops I meant git. I'm not talking about MobileFrontend's hardcoding, I'm taking about WikiPedia's frontend hardcoding.

Dantman (talkcontribs)

Could you be more specific about what you mean by frontend hardcoding. Talking in abstract and vague terms doesn't help others find the answer you need, developers understand what could be fixed, or help improve anything for anyone else.

Jidanni (talkcontribs)
Dantman (talkcontribs)

So you're talking about the Wikipedia/etc... apps, not MobileFrontend or any part of core.

That doesn't sound like a good idea. Pointing the Wikipedia app to a wiki other than Wikipedia doesn't sound like a good idea.

And making a generic "MediaWiki" app to point to any wiki is also a bad idea.

  • Configuring it to point to various wiki to view will be too advanced a task for most users.
  • It won't fit in well with the app oriented setup of current mobile operating systems. Searching for a "MediaWiki" app or accessing multiple wikis from one app will not make sense to the average user.

It'll essentially become a glorified web browser that can't even browse the web and is too confusing for most users to use.

If you want an app for your wiki you're just going to have to fork the iOS/Android Wikipedia apps, modify them to point to your wiki and use your branding, then publish them to the app networks yourself.

The Android and iOS app ecosystems just aren't going to make it any easier than that. They're not designed for this.

Jidanni (talkcontribs)

Hurmf... radio apps can listen to many channels... so there should be a wiki app that can tune in to many wikis. --- or something else on the drawing board appwise for all mediawiki wikis. Indeed, I can see the app's name already: MediaWiki.

Dantman (talkcontribs)

Wikis are not radios, the user experience does not translate. And the mass majority of users reading the many wiki around the internet don't even know what MediaWiki is.

Jidanni (talkcontribs)
Dantman (talkcontribs)

That's because the sidebar is an antique method of handling navigation that doesn't work well on mobile.

If search isn't a good method of doing navigation on your site it's better to configure a custom main page for mobile which has an optimized site navigation.

Jidanni (talkcontribs)

OK, I have now installed MobileFrontend again and now all that is remaining is "Eliminate render-blocking JavaScript and CSS in above-the-fold content" which is good progress.

I had better set $wgMFNoindexPages=true; else my site's rankings won't see the benefit of me adding MobileFrontend?

Dantman (talkcontribs)

It looks like the default is already true.

That setting looks like a workaround to an indexing issue. One that theoretically could be fixed by adding a mobile rel=alternative the way Google describes.

((I reported this as T91183))

I'd recommend you leave that setting out of your config. That way if MobileFrontend fixes the issue things will just start working and get even better for your site, instead of your config overriding the improvement and downgrading your indexing.

Reply to "Here's what Google Webmaster Tools has to say"
Dantman (talkcontribs)

On making MediaWiki aware, how about WebRequest::isMobile()?

Reply to "Etc"
Dantman (talkcontribs)

Mobile and desktop skins are unfortunately two completely different beasts in terms of body output needs. Some people would advocate a mobile-first approach where you develop things for mobile and them layer desktop improvements on top of that. But we've got too much desktop legacy for that.

I suggest this:

  • We leave SkinVector, SkinMonoBook, etc... as-is.
  • We add a SkinMobile introducing the standard mobile skin.
    • SkinMobile very liberally introduces methods that can be hooked into to extend the skin with whatever types of branding a wiki may want on their mobile view
  • We add a $wgMobileDefaultSkin or $wgDefaultMobileSkin which defaults to 'mobile'
  • We introduce some sort of flag that marks a skin as mobile vs. desktop.
    • For now it'll probably have to be a $wg variable like: $wgSkinModes['mobile'] = array( 'desktop' => false, 'mobile' => true );
    • ((I think I already have an idea how I can fit that into the config setup for my skin rewrite))
  • Special:Preferences gets keyed into skin modes and we add a new preference:
    • Our current 'skin' preference only lists skins that are desktop=>true
    • We add a new 'mobileskin' preference which lists skins that are mobile=>true allowing users to choose different mobile skins.
Reply to "Skinning"
There are no older topics