Extension talk:MobileFrontend/2012

useformat key-value pair

I installed the extension and tried to reach the mobile version by appending &useFormat=mobile to a given URL. Nothing different showed up

Then I tried &useformat=mobile (after having taken a peek at the source code, notice the non-capital "f" there). That worked to the degree that the formatting seemed "mobile-ish", but the Show/Hide Buttons still aren't there for the headings

Can anyone shed light on this?

Best,
Sandro 31.16.107.164 15:00, 13 January 2012 (UTC)

Hi Sandro

Are you still having problems? There were some issues at the start of the year with cookies not getting set.

The correct way to enable mobile is append useformat=mobile or mobileaction=toggle_view_mobile to the query string.

It is case sensitive as you discovered! Jdlrobson (talk) 11:27, 16 May 2012 (UTC)

Bad performance

I tried to install this extension on my wiki (MW 1.18) but it simply renders it too slow. I'm not even viewing pages while using it, just activating the extension and viewing pages normally Salready makes every page to load 5 times more slowly. Has anyone else experienced this? is there a way around this? 85.250.154.124 03:39, 4 February 2012 (UTC)

You must have object caching set up, or WURFL will keep reinitializing on every request. Max Semenik 17:58, 10 February 2012 (UTC)

Issues with MobileFrontend and possible rewrite

John Du Hart has embarked on a rewrite of MobileFrontend with the primary aim of reducing the extension's Wikimedia-specific dependencies (am I getting that right, John?). It's currently in the Subversion repository as "MobileFrontend2" -- see his recent work.

Patrick Reilly, the current maintainer of MobileFrontend, disagrees with John (and with other MediaWiki developers, including Chad Horohoe) on the need for a rewrite. Some conversation on the topic:

<preilly> ^demon: I just think we should refactor the current implementation not start fresh

<^demon> Well the current version gets deployed rather often.

<^demon> So forking it's not a bad idea.

<preilly> ^demon: I'm not sure I follow?

<JeroenDeDauw> wmf-cenrtic MediaWiki stuff is evil :/

<preilly> JeroenDeDauw: ha ha

<^demon> preilly: Well if it's getting majorly refactored to not be so wmf-centric, we don't want to make the current version unstable.

<^demon> So you can continue iterating & deploying.

<preilly> ^demon: yeah, that makes sense

<^demon> JeroenDeDauw: Agreed. And when possible, it should be configured.

<^demon> *configurable

<preilly> ^demon: yeah, totally

<^demon> Preferably not $wgIsWikimediaHack ;-)

<preilly> ^demon: yeah

Sumana asked:

other than making the extension less Wikimedia-specific, what other improvements are you planning, johnduhart, and what are (as you see it) the flaws in the current implementation?

Patrick agreed:

So we should put together a concrete list of what it's missing in its current form and start to work from there

What would you put in that list? Please comment. Sumana Harihareswara, Wikimedia Foundation Volunteer Development Coordinator 17:42, 10 February 2012 (UTC)

Wiki[pm]edia centric

This is a no-brainer, but specifically:

• Relying on X-Device headers
• Squid cache hacks
• Wikipedia mobile hacks
• Wikimedia templates (sopa)
• Domain handling

CSS is a mess

The current CSS setup is a huge mess. Lots of duplicate rules in device specific files.

Everything in one file

Until very recently 90% the code was in one file.

Login form and templates

These should be implemented as SpecialPages, really

That's just off the top of my head. Along with fixing the above issues, I intend to do the following

• Make use of anonymous squid cache for the main site when the parser cache isn't available (Requested by Tim)
• Take a structured, OOP approach to the extension
• Take steps for automatically configuring WURFL caching so it doesn't kill your wiki when you use the extension
• Add hooks for doing Wikimedia things
• More configuration for the post-parse output mangling
• Instead of doing a mobile front page by manipulating it, use a custom mobile page

That's most of, there'll be a few more tweaks and features. Johnduhart 18:49, 10 February 2012 (UTC)

I'd like to se the horrid output buffer based hack replaced with implementation via a custom skin. Daniel Friesen (Dantman) 19:01, 10 February 2012 (UTC)

Oh yeah, I forgot. I already am doing it as a skin. Johnduhart 19:48, 10 February 2012 (UTC)

As I understand it, a lot of thought and discussion went into the decision to use the 'output buffer based hack' rather than a custom skin. I'll let others more knowledgeable comment on this, but I believe using the 'hack' is way more performant (which is a major consideration particularly when dealing with mobile devices) as well as offers a lot more flexibility. Awjrichards 12:38, 11 February 2012 (UTC)

• This "hack" causes the extension to completely break when you have a wiki using a custom skin. This is absolutely unacceptable for implementation.
• There is absolutely no way that implementation as an output buffer can be more performant than implementation as a skin.
  • Either way MediaWiki still has to render a skin. So an output buffer only adds to the work, it doesn't reduce it.
  • Our normal skins end up doing work rendering things that only end up getting stripped away by the output buffer. Hence a custom skin would be more performant than an output buffer since it wouldn't be wasting time rendering things uselessly.
  • This "hack" we have actually lets MediaWiki execute the ENTIRE actions of whatever non-mobileaction url it's on when you're on a &mobileaction=, render the entire page, and then discard everything that's done, all the work, all the rendering, and then do more work replacing all of that with new content generated for the mobile action. There is no way that is code that is written to have good performance. Daniel Friesen (Dantman) 22:24, 12 February 2012 (UTC)

Is this an either/or question? If John is excited about a rewrite, why not have a go at it and then gradually make similar changes to the mainline code to the extent that the other devs agree they make sense? Replacing an extension in bulk is not really less scary than continuously refactoring/deploying an existing one, AFAICT. But I can see the lure of starting with more of a green field, so if that's what John wants to do, then obviously he should do it.

I agree that it would be preferable to rename the rewrite for now to avoid confusion (the current name suggests that it's the versioning of the MobileFrontend extension). Eloquence 19:13, 10 February 2012 (UTC)

Heads up that most of the Wiki[pm]edia centric bits are already getting taken care of by Arthur. He's removing a lot of the WMF related bits and you can keep track of his development updates by following the bugs in : http://lists.wikimedia.org/pipermail/wikitech-l/2012-February/057936.html . Any ideas/implementation bits are always appreciated.

The CSS bits are getting cleaned up by Jon (just joined) so feel free to message him on IRC to coordinate.

Eager to see your take on the other bits and please do join us and chat about it on IRC. We'd love to hear from you as you go rather then just when you have a release reader. Tfinc 20:16, 10 February 2012 (UTC)

Shouldn't things like the login form simply (re-)use core code? MZMcBride 23:08, 10 February 2012 (UTC)

I agree with that, though we might need to extend that special page if we need to make modifications to the form itself. Johnduhart 23:34, 10 February 2012 (UTC)

I don't really understand why this warrants a complete rewrite - the issues you outlined will need to be addressed in MobileFrontend anyway as we continue moving forward with it. Ultimately I think it would be more positive to continue refactoring and de-mediawiki-afying MobileFrontend - this is something we can totally do in cooperation together. I'm not against a rewrite per se, but if you really want to do a rewrite, I suggest creating a branch and make your changes there. Awjrichards 12:37, 11 February 2012 (UTC)

Just as a note I've made a reply on the mailing list on this. Johnduhart 14:11, 13 February 2012 (UTC)

Many thanks for working on this, John. We've worked incredibly hard on our independent wiki, and it is very exciting to hear that there may be a mobile frontend in the pipeline that is designed to be more general. Forest4Trees (talk) 01:30, 25 February 2012 (UTC)

class="noprint"

filed as Bug 36742: Elements with blacklisted class get removed only if it's their only class.

The extension on hides noprint sections when it's the only class specified

Compare

<span class="noprint">Test 1</span>

and

<span class="noprint plainlinks">Test 2</span>

Only Test 1 is hidden and Test 2 is still visible. WOSlinker (talk) 19:01, 27 February 2012 (UTC)

How Do we make to Mobile view stick?

We just got the .git version (rI9a349dbc) of the MobileFrontend on a clean MW 1.19 vanilla installation and we hoped for being able to use the MobileFrontend without doing a lot of ... (we tested the extension four month ago that is when we decided to wait ...) but it seems we are somehow unable to use the Frontend so that a devices such as Sony PRS-T1 (by standard using a Android browser) being automatically recognized. When using the switch at the bottom of an article one can enjoy the mobile version but as soon one changes the article the view will not stick and returns to the standard vector skin. From the documentation it is not clear what todo to elimiate this behaviour (and yes we don't wanne start using subdomains because in our layman view, the extension should be able to switch without having to go through redirects of a subdomain jungle etc.) and reviewed the comments from Jon (MobileFrontend2) and the mailings-list bugzilla from Arthur but it is still unclear what needs to be done.

One should be able to use this extension without much hustle and knowledge of any specific WMF setup (doing X-Device headers to simulate WMF behaviour etc.).

Comments, ideas, and links to resolve this elementary issue would be much appreciated. MWJames (talk) 23:52, 17 April 2012 (UTC)

Same here. I have just installed this extension here. The problem seems to be that the device detection via WURFL doesn't work, and there is no documentation on what to do when that happens.

In my case this is a small project hosted in a place where I have a restricted access. I wonder if I will have the permissions needed to get this up & running.

It would be nice to have a poor's man device detection for cases like this, like the one Extension:MobileDetect provides. A simple file populated with the most popular devices, leaving the completion to the MediaWiki instance owners based on whatever they miss. I though that was the reason for DeviceDetection.php to exist, but it seems not to be the case.

PS: I have filed a bug that I don't think it's related. Mentioning it here just i case. Qgil (talk) 06:52, 18 April 2012 (UTC)

Same issue here, since I just needed a very basic check for the most common devices, I simply changed the detection Routine in "MobileContext.php" to something like this:

public function isMobileDevice() {

if (preg_match("/(iphone|ipod|webos|opera mini|android|blackberry|windows\sce|palm|smartphone|iemobile)/i",

$_SERVER['HTTP_USER_AGENT'])) {

return true;

} else {

return false;

}

} Yokomaka (talk) 16:21, 11 June 2012 (UTC)

Try this out Extension talk:MobileFrontend/2012#c-EvanFabry-2012-06-27T16:17:00.000Z-Suggestion_for_more_stable_device_detection_using_Extension:MobileDetect. I changed the mobile detecting using a one file extension. It stuck when I tested it. EvanFabry (talk) 16:32, 27 June 2012 (UTC)

See bug 36894 - this is something we want to fix but it's complicated. Jdlrobson (talk) 17:56, 27 June 2012 (UTC)

After quite a few hours of alterations, I came up with a relatively simple fix (in addition to that simple device detection modification above) to make the changed views stick. All of these changes were done to MobileContext.php.

The reason that mobile views would not stick on a desktop device was that the cookie "[mf_mobileFormat]" controlled by function setUseFormatCookie was not being created. This can be fixed by taking this

public function setUseFormatCookie( $cookieFormat = 'true', $expiry = null, $force = false ) {
		global $wgCookiePath, $wgCookieSecure;
		// sanity check before setting the cookie
		if ( !$this->shouldSetUseFormatCookie() && !$force ) {
			return;
		}
		if ( is_null( $expiry ) ) {
			$expiry = $this->getUseFormatCookieExpiry();
		}
		setcookie( $this->getUseFormatCookieName(), $cookieFormat, $expiry, $wgCookiePath,		// End this line after $expiry
			$this->getRequest()->getHeader( 'Host' ), $wgCookieSecure );   	// Comment this line out
		wfIncrStats( 'mobile.useformat_' . $cookieFormat . '_cookie_set' );
	}

and changing the setcookie function call (lines 420-421 at the time of writing) to this

 		setcookie( $this->getUseFormatCookieName(), $cookieFormat, $expiry, $wgCookiePath);

The reason for this was that on my machine, the cookie domain was not properly set. As this is an unnecessary feature, I eliminated it.

Now to make desktop view stick on mobile devices, I changed function toggleVIew( ) to set UseFormatCookie to 'false' if toggled to desktop and changed shouldDisplayMobileView accordingly. Function toggleView( ) was changed to this (notice changed lines are followed by " // MODIFIED!!! " )

	public function toggleView( $view, $temporary = false ) {
		global $wgMobileUrlTemplate;
		$context = MobileContext::singleton();
		if ( $view == 'mobile' ) {
			// unset stopMobileRedirect cookie
			if ( !$temporary ) $context->unsetStopMobileRedirectCookie();
			// if no mobileurl template, set mobile cookie
			if ( !strlen( trim( $wgMobileUrlTemplate ) ) ) {
				if ( !$temporary ) $context->setUseFormatCookie();
				$context->setUseFormat( $view );
			} else {
				// else redirect to mobile domain
				$currentUrl = wfExpandUrl( $this->getRequest()->getRequestURL() );
				$currentUrl = $this->removeQueryStringParameter( $currentUrl, 'mobileaction' );
				$mobileUrl = $context->getMobileUrl( $currentUrl );
				$this->getOutput()->redirect( $mobileUrl, 301 );
			}
		} elseif ( $view == 'desktop' ) {
			// set stopMobileRedirect cookie
			if ( !$temporary ) {
				$this->logtext( "temporary = $temporary" );
				$context->setStopMobileRedirectCookie();
				// unset useformat cookie
				if ( $context->getUseFormatCookie() == "true" ) {
					$context->unsetUseFormatCookie();
					$this->setUseFormatCookie( 'false' ); //MODIFIED!!!
				}
				else if ( $context->getUseFormatCookie() == "" ) {
					$this->setUseFormatCookie( 'false' ); //MODIFIED!!!
				}
			}
			// if no mobileurl template, unset useformat cookie
			if ( !strlen( trim( $wgMobileUrlTemplate ) ) ) {
				$context->setUseFormat( $view );
			} else {
				// if mobileurl template, redirect to desktop domain
				$currentUrl = wfExpandUrl( $this->getRequest()->getRequestURL() );
				$currentUrl = $this->removeQueryStringParameter( $currentUrl, 'mobileaction' );
				$desktopUrl = $context->getDesktopUrl( $currentUrl );
				$this->getOutput()->redirect( $desktopUrl, 301 );
			}
		}
	}

This way there is something that can be specifically checked that should stick if the user toggles to desktop on a mobile device.

Now the final part is to change the function shouldDisplayMobileFormat in the following way.

	public function shouldDisplayMobileView() {
		// always display non-mobile view for edit/history/diff
		$action = $this->getAction();
		$req = $this->getRequest();
		$isDiff = $req->getText( 'diff' );
		if ( $action === 'edit' || $action === 'history' || $isDiff ) {
			return false;
		}
		// May be overridden programmatically
		if ( $this->forceMobileView ) {
			return true;
		}
		// always display desktop or mobile view if it's explicitly requested
		$useFormat = $this->getUseFormat();
		if ( $useFormat == 'desktop' ) {
			return false;
		} elseif ( $this->isFauxMobileDevice() ) {
			return true;
		}
		// check cookies for what to display
		$useMobileFormat = $this->getUseFormatCookie();
		if ( $useMobileFormat == 'true' ) {
			return true;
		}
		// Add the following
		else if ( $useMobileFormat == 'false' ) {
			return false;
		}
…

Notice the commented section shows the code to add. This works with our check for wether the user intends to toggle to desktop.

I hope this is helpful. EvanFabry (talk) 19:47, 20 July 2012 (UTC)

Add "edit" link

Can you either add an 'edit' link in the nav or make this an extension option? It's frustrating to have to switch to the non-mobile view just to see that url. Sj (talk) 22:29, 28 April 2012 (UTC)

Agreed! This does frustrate me sometimes as I tend to force myself to use the mobile site on my desktop.

This should become more possible once the new navigation is in as there will be more space to accomodate such a link (see above) - at the moment there is just no space.

The other problem with this is the edit site is currently desktop only and this might create problems with switching you back to the desktop view of the site after a save which is equally annoying. I'd rather see us do a mobile friendly edit page and link to that. Jdlrobson (talk) 11:25, 16 May 2012 (UTC)

Another problem : when using the desktop frontend on mobile, I have to zoom in while reading and editing. But on every page refresh, notably after saving an edit, the zoom level is reset to 0. (well, to desktop-standard - too small.) Preserving zoom level across saves is important! Sj (talk) 14:12, 17 November 2012 (UTC)

By the way mobile has an edit link if you are logged in to the beta - http://en.m.wikipedia.org/wiki/Special:MobileOptions Jdlrobson (talk) 17:47, 10 January 2013 (UTC)

Add "discuss" link

Can you add a link to the talk page fore each article? Even if one doesn't have time to edit, browsing the discussion is important.

This could just be a mobile-optimized version of the standard page for discussion. Also, on the main mobile page, you could filter up the time of the last comment. Sj (talk) 22:32, 28 April 2012 (UTC)

This should become more possible once the new navigation is in as there will be more space [1, 2] to accomodate such a link:

http://www.mediawiki.org/wiki/Mobile_design/Wikipedia_navigation

It's worth joining in on the talk page there.

[1] http://www.mediawiki.org/wiki/File:Design-comp-actions.png

[2] http://www.mediawiki.org/wiki/File:Design-comp-main-nav.png Jdlrobson (talk) 11:22, 16 May 2012 (UTC)

Looking forward to this. What's the timeline for it? Sj (talk) 16:04, 10 January 2013 (UTC)

No timeline as of yet.. Encouraging photo uploading from mobile is the focus for the next quarter. Feel free to start a discussion on the mobile-l mailing list though Jdlrobson (talk) 17:46, 10 January 2013 (UTC)

Add "history" link

This could go to a simpler version of history optimized for mobile; with just a short-timestamp, username, size-of-diff, short edit summary.

It should also be possible to review diffs, in fact. For a sample small-width UI for this, see the Javascript widget that previews articles and diffs on mouseover.

If it's hard to do diffs or make old revisons show up in a mobile-optimized way, that could come later. For now diffs might not be available, and following a history link could take you to the desktop view. Sj (talk) 22:35, 28 April 2012 (UTC)

The footer now has a link 'Article by contributors like you' that points to history so there is a link now.

However, the history page is currently desktop only as there are more pressing things to address however if you can find a developer who has the time to make this page mobile friendly that would be awesome! Jdlrobson (talk) 11:29, 16 May 2012 (UTC)

This still needs a "last edited" timestamp to indicate freshness. Perhaps "last edited <YYYY-MM-DD> by contributors like you" ? Sj (talk) 16:07, 10 January 2013 (UTC)

See the beta - http://en.m.wikipedia.org/wiki/Special:MobileOptions - we have this at the bottom of every article. Jdlrobson (talk) 17:48, 10 January 2013 (UTC)

Add dynamic context to the footer

Add a small-font "last edited on <date>, last comment on <date>" to the footer, linking to the history and talk pages respectively. It is good to remind people from time to time they are reading a living document. Sj (talk) 22:39, 28 April 2012 (UTC)

Completely agree. So much so that I've written some code to do it - https://gerrit.wikimedia.org/r/#/c/7790/

I've left out the reference the talk page date for the time being as I was worried that it would make the text in the footer too big and felt that the last edited date was much more important. Jdlrobson (talk) 14:00, 16 May 2012 (UTC)

Awesome :) Sj (talk) 16:00, 10 January 2013 (UTC)

It was decided this early patch required more design. We've since added a last modified date to the bottom of the article in the beta. This will soon be incorporated into the design and will probably link to the history page when we have adjusted it for mobile. Not sure when this will happen as it is not a high priority but things are moving there. Jdlrobson (talk) 17:45, 10 January 2013 (UTC)

Mobile Search Broken

Search on the mobile side of the extension is broken for me, but there appears to be a problem with MediaWiki's API. Below is an example that compares my API with the API on Wikipedia. Both API params are exactly the same.

http://wiki.kappakappagamma.org/api.php?action=opensearch&format=xml&search=kappa
http://en.m.wikipedia.org/w/api.php?action=opensearch&format=xml&search=kappa

As you can see the first URL returns back a JSON result rather than a xml result. Wikipedia has the correct result. I did not make any edits to the API of my installation so I am curious on why this is occuring. Does anyone else experience this? 216.29.96.198 19:54, 18 May 2012 (UTC)

You will need to enable OpenSearchXml extension (Extension:OpenSearchXml).

I have updated the Extension:MobileFrontend installation instructions to reflect this.

Sorry for the confusion. User:jdlrobson 17:29, 19 May 2012 (UTC)

Thanks for the quick reply, that extension helped fix the problem. 216.29.96.198 14:09, 23 May 2012 (UTC)

Device Detection broken

I am getting a

PHP Fatal error: Call to undefined method DeviceDetection::formatName() in /var/www/mediawiki2/extensions/Mobile-Frontend/MobileFrontend.body.php on line 414

which is weird, because the code should be properly loaded.

 $device = new DeviceDetection();
               if ( $xDevice ) {
                       $formatName = $xDevice;
               } else { 

/* THIS is line 414 */ $formatName = $device->formatName( $userAgent, $acceptHeader );

               }

DeviceDetection.php gets properly loaded. So what could be wrong here? 93.207.217.222 22:50, 27 May 2012 (UTC)

Looks like you're using MobileFrontend with MediaWiki from Git and MW is newer than MF so you need to update the latter too. Max Semenik (talk) 14:11, 2 June 2012 (UTC)

Suggestion for more stable device detection using Extension:MobileDetect

I may have found a more stable way to detect devices using Extension:MobileDetect instead of MobileFrontend's device detection. If not more stable in mw1.20, this does have the advantage of being compatible with MediaWiki 1.19.1 and possibly with earlier deployments.

I recommend that MF users download and install Extension:MobileDetect, comment out the contents of public function isMobileDevice() of MobileFrontend/MobileContext.php (lines 100-106), and change that to "return mobiledetect();"

So this... public function isMobileDevice() {

         $xDevice = $this->getXDevice();
         if ( empty( $xDevice ) ) {
              return false;
         }
         return true;

}

was changed to this...

   public function isMobileDevice() {
       return mobiledetect();
   }

} This might be a good addition to the Extension:MobileFrontend page. EvanFabry (talk) 16:17, 27 June 2012 (UTC)

Also see Extension talk:MobileFrontend/2012#c-EvanFabry-2012-07-20T19:47:00.000Z-Jdlrobson-2012-06-27T17:56:00.000Z to make changes stick appropriately from mobile to desktop view and desktop to mobile view. EvanFabry (talk) 20:03, 20 July 2012 (UTC)

MobileFrontend/MobileContext.php does not appear to even exist anymore. 209.156.151.237 16:54, 28 August 2012 (UTC)

When using MobileFrontend 0.5.77 (for Mediawiki 1.18), MobileContext.php doesn't exist. In this case, you can edit MobileFrontend.php : below

In the lines :

if ( self::$useFormat === 'mobile' ||

self::$useFormat === 'mobile-wap' ||

!empty( $xDevice ) ) {

Replace

!empty( $xDevice )

with

$mobile === true

You also need to declare $mobile in the global vars, at the beginning of the definition of the beforePageDisplayHTML function. Too bad it's necessary to use 2 extensions to do that... Varlin (talk) 23:16, 3 January 2013 (UTC)

Navbox

so many wikis have something like "Navbox" on enwiki.

basically, this is (mainly) a horizontal box, located at the bottom of article. it does not live under its own section - typically just below the last section (e.g., "references").

however, logically it does not belong in the last section: just one out of several million example, see en:Copata, and the "La Paz Department" box below the references.

using "mobile view", this template is swallowed by the "reference" section, even though it does not belong there, so the mobile user, who might not be interested in looking at the references, does not even know they might be missing a lot of things which are not really references. on the other hand, with mobile view, the navbox loses the "colapsibility" it has with desktop view.

methinks the right thing to do is to introduce a new css class that will tell mobile view how to deal with navbox, and add this class to the navbox. note that navbox has mucco interwiki links - this template, or something very similar, exists in most or even all wikis.

peace. קיפודנחש (talk) 20:00, 6 July 2012 (UTC)

This is a good point. Traditionally, there have been large groups of 'content' elements that have been below the last header, even though in terms of 'sections' they don't logically belong to that particular section. I have thought about this in the past and also for usability/accessibility purposes, it would be best if we added a special header between the last section and the 'footer' sections. Currently this is not the case however, and adding it would require huge amounts of edits in the wikitext, so short term, it's not really a good solution. I guess we could write some sort of 'detection' routine for the english wikipedia in the short term, but it doesn't really sound like a sustainable idea either.

Elements that fall into the 'content footer' section of a Wikipedia article are generally: Navbox, Stub templates and succession boxes. TheDJ (talk) 20:19, 6 July 2012 (UTC)

i think it makes sense to introduce a css class that would cause an element that contains it to behave "like a header" in the mobile view.

this will allow actual maintainers of each wiki to add this class to whatever element they want, without having any effect on desktop view.

doing it this way, it will suffice to add this class once to the "navbox" template - this is not, by any means, huge amount of edits.

peace. קיפודנחש (talk) 21:18, 6 July 2012 (UTC)

This is a good point. I've opened https://bugzilla.wikimedia.org/show_bug.cgi?id=38246

I'm not quite sure how to do this - adding a class would not really be feasible here as what is happening is the mobile extension is splitting the article into sections based on the headings it encounters.

I believe in the meantime a Wiki editor could add a hidden heading to separate these sections e.g.

<!-- references text here --> <h2 style="display:none;"></h2> <!-- navbar here --> Jdlrobson (talk) 16:38, 8 July 2012 (UTC)

of course, it goes without saying that just adding a css class will not suffice - obviously i was thinking "add a css class and teach the mobilview extension to treat an element with this class as if it resides in its own header" (we could, e.g., use the elemen's title or some other html attribute in lieu of the header text).

peace. קיפודנחש (talk) 19:49, 12 July 2012 (UTC)

Just give me the setup for the default wiki with an ipad

This extension is making my brain hurt.

Can someone just give me the setup for the ipad on a vanilla install of 1.19?

I installed this and it still looks like poop.

Thanks. 24.38.246.73 01:21, 25 August 2012 (UTC)

Howto switch to mobile Version

I have MW 1.20 installed with latest git version of MobileFrontend and OpenSearchXML Extension. Everythings works great. I can switch to mobile theme and back to desktop version by clicking the link at the footer. So here is my question:

Should the mobilefrontend extension switch automatically to the mobile version on mobile devices, or do I have to do that with rewrites on my apache webserver? I would like all mobile devices to get the mobile site by default.

I hope someone could help me.

If I have to use apache rewrites, feel free to post them :-)

--91.89.83.212 20:06, 15 November 2012 (UTC)

See Bug 36894 - Mobile browser autodetection doesn't work. Qgil (talk) 22:14, 15 November 2012 (UTC)

So I read the whole Bug Report and now I'm a little confused. If I understand it right, actually there is no way to have mobile detection made my the extension. You need your own mobile detection. For Example an apache webserver which rewrites URLs for mobile browser by adding the "?useformat=mobile". Or is there a better way to do this with an apache webserver. I don't want to install a Varnish Proxy.

Thanks for your help! Andreas 08:33, 17 November 2012 (UTC)

Is there a posibilty to use the apache mobile frontend with this extension. It uses the wurfl database, too. And there are header called DEVICE_IS_TABLET and DEVICE_IS_MOBILE which you can read with php. Andreas 18:12, 17 November 2012 (UTC)

I think it's possible to use a PHP script found on the web to autodetect if the device is mobile or not. Where can I put this? 88.162.102.72 16:33, 31 December 2012 (UTC)

Could you share the URL of that script, please? Qgil (talk) 16:36, 31 December 2012 (UTC)

I found: https://code.google.com/p/php-mobile-detect/.

It's not possible to use media queries? 88.162.102.72 16:47, 31 December 2012 (UTC)

In my case /var/www/index.php redirects users to /var/www/mediawiki/index.php. So, I modified the /var/www/index/index.php as following:

<?php
header("location: mediawiki/");
include('path/to/Mobile-Detect/Mobile_Detect.php');
$detect = new Mobile_Detect();
if ($detect->isMobile() && !$detect->isTablet()) {
        header("location: mediawiki/index.php?title=Main_title&mobileaction=toggle_view_mobile");
}
?>

As you can see this script includes the functions from mobile_detect.php and use them to determine the type of device. If mobile device is detected the users are redirected to the mobile mediawiki version.

Hope this helps. 95.84.190.156 12:11, 22 March 2013 (UTC)

When I use this I get an error of "too many redirects". Any other solution available, besides switching to the latest master version? 109.186.226.40 09:17, 16 April 2013 (UTC)

Have you tried a recent version of the extension? I haven't checked myself, but it's supposed to have mobile autodetection. Qgil (talk) 16:29, 22 March 2013 (UTC)

This seems to be causing a lot of confusion (even for me!) so I've started this document for people to flesh out with the ways they are currently doing this - http://www.mediawiki.org/wiki/Extension:MobileFrontend/Configuring_Browser_Auto-Detection - please contribute if you have this working! Jdlrobson (talk) 18:22, 16 April 2013 (UTC)

Are there any known weaknesses with ApiQueryExtracts::getFirstSentences (aka prop=extract&exsentences)?

I've been looking for some time for a function that could correctly figure out where sentences break off, so that I could produce automated "Did You Know?" blurbs. This one looks a little too simple to be a complete solution. I'm not a regex expert, but I know it's pretty hard to program a computer to figure out that "Mr." or "etc." or ". . ." is not the end of a sentence. Leucosticte (talk) 21:36, 18 November 2012 (UTC)

OpenSearchXml required?

The page says "Note that the current implementation of the javascript search on the mobile site requires Extension:OpenSearchXml to work."

However, I just upgraded espiral.org to 1.20.2 installing the current snapshot from master and it seems to work without installing Extension OpenSearchXml? I mean, I get suggestions of pages as I type in the search box. Is that what you mean or is there more you would get by installing also OpenSearchXml? Qgil (talk) 08:08, 29 December 2012 (UTC)

It used to however since https://gerrit.wikimedia.org/r/26576 doesn't so I'll update the docs! 86.166.92.33 10:06, 29 December 2012 (UTC)

Thanks. I guess the line about $wgMFExtendOpenSearchXml needs some editing as well? Is this still a setting? If it still exists it is not set to false by default. Qgil (talk) 05:26, 30 December 2012 (UTC)

Why don't you look it up yourself instead of theorizing? It's still there. Max Semenik (talk) 08:32, 30 December 2012 (UTC)