Jump to content

Extension talk:MobileFrontend/2014

Add topic
From mediawiki.org
Latest comment: 3 years ago by Jdlrobson in topic Larger site logo

Note: This page is not actively watched right now due to LiquidThreads not being mobile friendly (how ironic :-)). If you have a feature request just request it here you'll get a much quicker reply :-) We are also around in #wikimedia-mobile just say hi and someone is bound to reply.

Maps and MobileFrontend

[edit]

I am using MediaWiki 1.22.1 with the appropriate MobileFrontend, and Maps extension 2.0.1. Whenever the mobile frontend is loaded, this breaks Maps so that the map "canvas" remains grey with a "Loading map.." message. Turning on or off Beta or Experimental mode seems to make no difference.

Before I upgraded from MW 1.20, and MobileFrontend with it, the behavior was slightly different. With MobileFrontend on normal mode, I got the same results, but on Beta mode, the message went from "Loading map.." to a message about my web browser being incompatible with maps.

The problem is consistent between devices.

Debugging this is a bit difficult, as the debug console does not appear in mobile view. Does anyone have an idea on what might be causing this? 80.202.18.41 19:24, 15 January 2014 (UTC)Reply

I have the same problem, and I got to show maps in mobile devices, but in that case desktop maps doesnt run.
Do anybody have a solution? Thank you in advance! 217.111.219.237 10:20, 13 February 2014 (UTC)Reply
Same here, endless "Loading map...". MediaWiki 1.22.2, Maps (Versio 3.0) and MobileFrontend. Any help? 62.183.153.40 18:19, 21 March 2014 (UTC)Reply
The extension has not been optimised for mobile usage. You'll need to submit a bug against the Maps extension. cc me and I can help with the required changes. Jdlrobson (talk) 19:24, 21 March 2014 (UTC)Reply
The map was only Loading stage. Map not started even after some time also. they are loadning and only Loading. Please give me if any map extension available working with mobile frontend. 210.89.56.38 11:55, 24 April 2014 (UTC)Reply
In the file of /includes/ResouceLoader/ResourceLoaderFileModule.php ,add $targets = array( 'desktop', 'mobile' ); in Line number 116. so map extension in mobile view is working. 210.89.56.38 12:05, 29 April 2014 (UTC)Reply
This worked for me. Just a few note to clarify:
  • The folder include is in the mediawiki root folder.
  • $targets = array( 'desktop', 'mobile' ); is not the line 116 for me, you can look for $targets = array( 'desktop' ); and add the , 'mobile'. Gborgonovo (talk) 10:42, 25 May 2015 (UTC)Reply

Installation ploblem (mobile domain)

[edit]

Sorry to be not good at English...

I installed MobileFrontend to MediaWiki 1.22.1. I have two problems.

http://wikimatome.com/wiki/メインページ?useformat=mobile works, but In LocalSetting.php, I customized as follows. $wgMobileUrlTemplate = 'm.%h0.%h1';

http://m.wikimatome.com/wiki/メインページ doesn't work.

Moreover, mobileview link is incorrect. http://m.wikimatome.com/index.php?title=メインページ&title=メインページ (It should be "http://m.wikimatome.com/wiki/メインページ)

Is there another setting point? If you succeed in setting mobile domain, please show the procedure.

Thank you. 114.176.219.228 16:02, 21 January 2014 (UTC)Reply

Yep, i'm having same trouble UksusoFF (talk) 06:34, 28 January 2014 (UTC)Reply
I abandoned the installation of MobileFrontend.
I adopt to Responsible skin. 153.177.124.178 13:18, 14 February 2014 (UTC)Reply
Very sorry you have been encountering problems. Two things:
1) It sounds like you may not have the m.wikimatome.com subdomain set up. Wikipedia and the other projects use the $wgMobileUrlTemplate, and we know that definitely works :)
2) The mobileview link issue you identified is an old issue that has been resolved. Are you able to use a newer version of MobileFrontend? Arthur Richards (talk) 21:03, 14 February 2014 (UTC)Reply
I had a same problem at mediawiki 1.22.2 and mobilefrontend updated. With $wgMobileUrlTemplate setting, the mobile url had additional title instead of adding "mobileaction=toggle_view_mobile" at the end of url.
Furthermore, I have several problems with my mobile page. 1) I can change beta mode but it does not saved. 2) I can not edit pages. The edit icon is a locked image and nothing happen when I clicked this. 3) folding a paragraph does not work.
I think all of this have a same reason but I could not find what it is. Let me know what to do. 115.91.55.219 02:36, 17 February 2014 (UTC)Reply

Conflict with CentralNotice extension

[edit]

CentralNotice extension stopped working, after installing MobileFrontend extension.

Any idea, would be appreciated... 78.43.43.98 18:56, 27 January 2014 (UTC)Reply

Mobile view of Category Page

[edit]

The default "Category" mobile view is three Column/Row, including Subcategories and Pages in category, view this kind of information is very inconvenient in a handheld device, I propose that one row only display one column. Steven-zhongyi (talk) 01:00, 28 January 2014 (UTC)Reply

I agree, furthermore the sections should be 'uncollapsed' by default in the Category namespace, is there anyway to achieve this? Stuartbman (talk) 11:45, 4 March 2014 (UTC)Reply
The Category tree is generated by the CategoryTree extension. It builds a 3-column table to display the tree, and it's not very mobile friendly. There's not much MobileFrontend can do about that.
Uncollapsing a category tree by default can result in very long pages, so that would not be a good idea. Edokter (talk) — 13:25, 4 March 2014 (UTC)Reply

How to get Piwik code into MobileFrontend?

[edit]

I use the Piwik Integration extension, but the Piwik code doesn't make its way into mobile view of the site.

What can I change to accomplish this? MadenssContinued (talk) 23:24, 3 February 2014 (UTC)Reply

Mobile Upload Fails if comment has a period.

[edit]

I'm just testing out new 1.23wmf14 and the latest mobile front end.

Upload fails if the file description has a period in it. It works fine if I put a comment of any size with no period.

This is a boat <-- fine This is a boat. <-- upload fails

The progress bar seems to load, and then finishes, and the page stays where it is.

Hope that helps! MarkJurgens (talk) 14:08, 20 February 2014 (UTC)Reply

Ah, I understand, that field becomes the file name + time/date information.
This should be made much clearer for users (text on that page).
And a period in the description still crashes it.
Mark MarkJurgens (talk) 03:23, 21 February 2014 (UTC)Reply
Now that you have clear steps to reproduce I suggest to file a bug, crashes/fatal errors should always be filed. Nemo 08:28, 24 February 2014 (UTC)Reply
I'm unable to replicate this on latest master.. which browser are you using and which page name are you attempting to upload to? Jdlrobson (talk) 19:38, 26 February 2014 (UTC)Reply
I'm trying to reproduce it again and can't. Apologies. If I come across it again I'll make sure it's reproducible beforehand.
I was on an iPhone 4, safari. MarkJurgens (talk) 18:22, 27 February 2014 (UTC)Reply
Okay, I am seeing this error, I'm just not able to reproduce it again. I see it on iPad and iPhone so far. Upload just doesn't work sometimes and reverts back to the upload page. It seems to happen more frequently when I write longer file descriptions using two sentences with periods, or exclamation marks. Removing the second period let me upload the file. But with the next photo there was no error.
If I do get clear steps to reproduce it I'll post them. MarkJurgens (talk) 20:50, 28 February 2014 (UTC)Reply
There are definitely some file name issues here. May be related to https://bugzilla.wikimedia.org/show_bug.cgi?id=62241 Jdlrobson (talk) 20:05, 7 March 2014 (UTC)Reply
Ahha. I got the error consistently with this text:
Jellyfish. Taken at Ripley's Aquarium in Toronto.
Possibly the quote, or the second period messing with the file naming.
Or maybe it has something against Jellyfish. ;) MarkJurgens (talk) 03:24, 8 March 2014 (UTC)Reply

Mobile default on Ipads?

[edit]

For my site, I'd like to make it default to mobile on ipads, is this possible?

Thanks! MarkJurgens (talk) 14:10, 20 February 2014 (UTC)Reply

$wgMFShowMobileViewToTablets = true; Max Semenik (talk) 15:16, 20 February 2014 (UTC)Reply
Great! That works.
How do I set mobile as the default on desktops?
In other words, as the default viewing option on all platforms?
And if i might ask, can i set beta features as on by default?
Is there a list or variables? I dont ses these newer ones the extension wiki page. MarkJurgens (talk) 20:45, 27 February 2014 (UTC)Reply
Try the following:
$wgValidSkinNames['minerva'] = "Minerva";
$wgDefaultSkin = "minerva";

function efMyFunction2() {
$context = MobileContext::singleton();
$context->setMobileMode('beta');
}
$wgExtensionFunctions[] = 'efMyFunction2';
Jdlrobson (talk) 21:51, 27 February 2014 (UTC)Reply
That works well.
- However the footer shows the 'mobile' link, so it hasn't toggled over completely to the mobile view by default.
It looks like the mobile view, but some of the styling isn't applied (ie. the text is aligned all the way left, and clicking "show history for this page" gives you the detailed desktop view of the diff's not the mobile one.
... But, I've decided not to force mobile on all platforms. Too much functionality still in the desktop site that's not available on mobile. MarkJurgens (talk) 06:32, 28 February 2014 (UTC)Reply

Bug? ConfirmtoEdit Variable does not change mobile signup text.

[edit]

Not sure if this is a bug to report, or a feature request..

If $wgEmailConfirmToEdit = true; then the signup text should indicate an email address as required. Changing this variable to true does this on the desktop site, where the text saying email (optional) is replaced with Email address:

This should happen in the mobile version as well.

Also, the text after signing up should modify, and say "You will need to confirm your email address before you can edit pages and start participating" MarkJurgens (talk) 04:23, 21 February 2014 (UTC)Reply

I suggest to file a bug for this. Rewriting core interfaces such as user registration and login from scratch means that it's easy for many errors to slip in, it's more useful to have them tracked. Nemo 08:26, 24 February 2014 (UTC)Reply
[edit]

I'd like to a very simple skin on the mobile app, just so it doesn't look exactly like Wikipedia's.

1. I'd like to change the background colour of the header (and adjust the searchbox & icons 2. Put a background image in the width of the footer (change the background colour as well)

Where can I @import a style sheet, and I'm having trouble finding the corresponding css/less elements to adjust.

Thanks, Maybe I could write a skinning document somewhere to help others? MarkJurgens (talk) 14:35, 28 February 2014 (UTC)Reply

So there are some a lovely variables called $wgResourceLoaderLESSVars and $wgResourceLoaderLESSImportPaths....
If you swap out the MobileFrontend minerva.less file you can substitute this for anything you want and gain a huge amount of control about how you tweak your style. If there is something you want to style submit a patch turning it into a variable.
If you can code and are willing to write a patch for this this would be super useful :) Jdlrobson (talk) 20:04, 7 March 2014 (UTC)Reply

$wgMobileUrlTemplate isn't working

[edit]

Extension installed. At default settings, works. Have subdomains properly set up so an m. version arrives as it should. BUT try to make things work with a mobile subdomain and it seems to fall apart.

Without $wgMobileUrlTemplate defined, at the bottom of the page the link to the mobile version will be something like "http://wiki.domain.tld/index.php?title=1989&mobileaction=toggle_view_mobile", which when clicked shows the mobile version. If I do $wgMobileUrlTemplate = "m.wiki.domain.tld";, though, I end up with a link like "http://m.wiki.domain.tld/index.php?title=1989&title=1989". Superfluous second title, and when clicked just shows the desktop version again anyway. I've tried various things for $wgMobileUrlTemplate, but it makes no functional difference whether I instead give it something like "m.%h0.%h1.%h2". Using MediaWiki 1.22.3 and the current version of MobileFrontend. 97.73.64.150 18:45, 10 March 2014 (UTC)Reply

Same here. Unikum (talk) 05:45, 17 May 2014 (UTC)Reply
For me too. I don't understand how to put the mobile version on a separate sub-domain. Shumz (talk) 20:38, 16 June 2014 (UTC)Reply
Same here, anybody got it working? SJWiki (talk) 15:04, 16 August 2014 (UTC)Reply

X-Analytics/mobile tracking?

[edit]

We're using Piwik and Google Analytics, and currently the only way we can determine whether a visitor used our wiki on a mobile device is via the browser model, since we don't have a mobile URL -- and even then it's not 100% accurate, since some people prefer to use the desktop version of the site instead of the mobile version.

I did a search and saw this article on X-Analytics. I'm not a MW expert so I'm not 100% clear on what X-A does, and from the code linked it seems to only track whether a user is in alpha or beta mode.

We're currently running MW 1.21 so the X-Analytics doesn't seem to be included in that MobileFrontend version. Hopefully we'll upgrade ASAP, but I wanted to see if this was a way to get better data on mobile usage of our wiki.

Thanks all! Kchurch05 (talk) 16:35, 13 March 2014 (UTC)Reply

The X-Analytics header was introduced to unify some WMF-specific analytics-related data that we've been passing around in HTTP headers. You can read a little more about it on wikitech (https://wikitech.wikimedia.org/wiki/X-Analytics), but I dont know how much that info will help for your situation. For WMF purposes, this header can get set by Varnish, MobileFrontend, and/or ZeroRatedMobileAccess (for Wikipedia Zero). This was introduced in 1.21wmf11. You could conceivably use this header for your own purposes, although it would require some hacking. MobileFrontend/includes/MobileContext.php has some methods that would allow you to manipulate the contents of that header.
Are you trying to determine the numbers of users accessing your site on a mobile device, the number of users of the mobile version of your site, or the number of requests for mobile versions of your site? If you feel confident with PHP, it would be fairly straightforward to whip up a custom Mediawiki extension to either overload the X-Analytics header or return some other custom header when a request was made for the mobile version of your site. If you want to track number of unique users, that gets a little trickier but should be doable as well. Arthur Richards (talk) 21:35, 13 March 2014 (UTC)Reply
[edit]

Is it possible to hide the "Mobile View" link when a Wiki isn't being viewed on a mobile device? That is, when browsing the Wiki on a mobile device, the option will be there in the footer, but when browsing on a desktop/laptop, the "Mobile View" link won't appear. 119.15.78.143 10:17, 24 March 2014 (UTC)Reply

Use CSS3 Media Queries, as:
@media only screen and (max-device-width:768px) {
    #footer-places-mobileview {
        display: none;
    }
}
Of course it needs to be adjusted to match the devices you're trying to target. Ricordisamoa 03:51, 25 March 2014 (UTC)Reply
Many thanks! 119.15.78.143 05:35, 31 March 2014 (UTC)Reply

upstream not working with MW 1.22.4

[edit]

Hello,

because of the HTTPs-Error (forceHttps) I tried the upstream version from git. Result: the wiki doesn't work anymore. Message displayed is: "This version of MobileFrontend requires MediaWiki 1.22, you have 1.22.4. You can download a more appropriate version from https://www.mediawiki.org/wiki/Special:ExtensionDistributor/MobileFrontend"

Karsten Koemski (talk) 11:51, 28 March 2014 (UTC)Reply

See MobileFrontend.php:
// Too many people are trying to use master MF with stable MediaWiki releases
if ( version_compare( $wgVersion, '1.23c', '<' ) ) {
	echo "This version of MobileFrontend requires MediaWiki 1.22, you have $wgVersion.
You can download a more appropriate version from
https://www.mediawiki.org/wiki/Special:ExtensionDistributor/MobileFrontend\n";
	die( -1 );
}
Shirayuki (talk) 11:36, 29 March 2014 (UTC)Reply
Yes Done. Fixed with gerrit:121931 Shirayuki (talk) 12:06, 29 March 2014 (UTC)Reply
Good, after I remove the paragraph at MobileFrontEnd.php newest version of MobileFrontEnd works.
Now I have several messages when I open My wiki at phone. I think these have something to do with the issues I had, Unable to edit at mobile format, unable to folding paragraphs, etc. If anybody have an idea, let me know what to do to fix my issues?
  • Notice: Undefined index: banners in MinervaTemplate.php on line 217
  • Warning: Invalid argument supplied for foreach() in MinervaTemplate.php on line 217
  • Notice: Undefined index: menuButton in SkinTemplate.php on line 1387
  • Notice: Undefined index: disableSearchAndFooter in MinervaTemplate.php on line 224
  • Notice: Undefined index: searchBox in MinervaTemplate.php on line 230
  • Warning: array_merge(): Argument #3 is not an array in SkinTemplate.php on line 1871
  • Notice: Undefined index: secondaryButton in MinervaTemplate.php on line 239
  • Notice: Undefined index: internalBanner in MinervaTemplate.php on line 146
  • Notice: Undefined index: unstyledContent in MinervaTemplate.php on line 122
  • Notice: Undefined index: pageLang in MinervaTemplate.php on line 126
  • Notice: Undefined index: pageDir in MinervaTemplate.php on line 127 01:24, 31 March 2014 (UTC)
That usually happens when you try to circumvent a message requiring you to use the current master release instead of the latest stable release. Ciencia Al Poder (talk) 15:08, 4 April 2014 (UTC)Reply

By default, the Main Page on the mobile site is disabled.

[edit]

We see "By default, the Main Page on the mobile site is disabled." Maybe he is only talking about WikiMedia sites? Jidanni (talk) 00:52, 2 April 2014 (UTC)Reply

mobileaction=beta explain more

[edit]

Perhaps explain "If you would like to view a page in the beta without enabling it across the entire site you can append to the query string of any page ?mobileaction=beta" more please! Jidanni (talk) 01:02, 2 April 2014 (UTC)Reply

Mention how to update from git too

[edit]

Mention how to update from git. The information I found elsewhere does not work. Jidanni (talk) 00:39, 7 April 2014 (UTC)Reply

change Background on Mobile View Only

[edit]

Hello, I am having some issues with our private wiki with our custom background. On the desktop site i have a really dark background that is fine because the pages themselves are white. On the mobile view however, everything is transparent and the background shows through, causing everything to become unreadable. I can work around this by enabling the experimental mode on the mobile version, however i do not want to have each user do this on every mobile device. Can someone point me in the direction I need to set a static background on the mobile view or exclude the background on it somehow? Ringnutz 04:59, 13 April 2014 (UTC)

Selfish bump 198.228.200.38 22:38, 21 April 2014 (UTC)Reply
You can set custom site-wide CSS for mobile view in MediaWiki:Mobile.css. Edokter (talk) — 11:06, 22 April 2014 (UTC)Reply
Thanks but that does not work, I can apply a transparency that shows through when i enable expirimental mode again, but it does not work in beta or normal. I think it may have something to do with BlueSpice overriding the background somehow as originally it is white but is replaced by a background image 71.199.124.94 23:02, 22 April 2014 (UTC)Reply
Also, I would be fine if I could just set it globally to use the experimental mode on all mobile view pages, I just do not want each user to fumble around trying to change the settings when they can't see the buttons 50.203.245.242 12:24, 23 April 2014 (UTC)Reply
Anyone? 71.199.124.94 22:35, 7 May 2014 (UTC)Reply
Anyone yet? GamepadUniverse (talk) 19:20, 23 March 2015 (UTC)Reply
What css rule are you using in MediaWiki:Mobile.css ? Jdlrobson (talk) 04:10, 10 June 2015 (UTC)Reply

The separate world of Mobile?

[edit]

FYI. Nemo 10:12, 3 May 2014 (UTC)Reply

How to enable tag extensions (Gists for example)

[edit]

I really like the mobile front end, but I can't figure out how to enable Manual:Tag_extensions.

In my case I use the Extension:Gists on my wiki to be able to embed github's gists. It works fine on the desktop version of the wiki, but nothing shows up in the mobile version.

I'm not very good in PHP, I didn't manage to find how to do that.

Thanks! 109.11.168.233 18:48, 19 May 2014 (UTC)Reply

MobileFrontend filters out JavaScript and CSS for all foreign extensions. Please file a bug against the extension requesting it be enabled for mobile. See ResourceLoader/Writing_a_MobileFrontend_friendly_ResourceLoader_module Jdlrobson (talk) 18:56, 19 May 2014 (UTC)Reply
I searched for a while but didn't find this page, thanks! 109.8.72.218 19:24, 20 May 2014 (UTC)Reply

mobile Login, keep me logged in checkbox?

[edit]

Hi all,

is there a way to have the checkbox "Keep me logged in" even on mobile view login? Raid (talk) 20:11, 1 June 2014 (UTC)Reply

Hello,
not for now, no. If you want, you can open a feature request: https://bugzilla.wikimedia.org/enter_bug.cgi?product=MobileFrontend&component=Feature%20requests Florianschmidtwelzow (talk) 21:15, 1 June 2014 (UTC)Reply
But before, please read this bug: https://bugzilla.wikimedia.org/show_bug.cgi?id=46241 Florianschmidtwelzow (talk) 21:33, 1 June 2014 (UTC)Reply
thx, already reported Raid (talk) 05:35, 2 June 2014 (UTC)Reply

Not able to save changes to existing pages in MobileFront end

[edit]

Not able to save changes to existing pages in MobileFront end by an anonymous user. When he saves it says "Error - edit not saved". I have set the directive of anonymous editing to YES in mobilefrontend settings. Deepak343 (talk) 17:13, 5 June 2014 (UTC)Reply

See talk in mobile-l list:
http://lists.wikimedia.org/pipermail/mobile-l/2014-June/007268.html
and following Florianschmidtwelzow (talk) 20:56, 5 June 2014 (UTC)Reply

Windows Phone jumps to end of text after I have pressed enter

[edit]

Also sometimes I get extra characters at end of text. I have mainly added wikipedia links to text. This seems to be a Mediawiki problem, I don't remember getting this behaviour with other sites Pasixxxx (talk) 17:42, 10 June 2014 (UTC)Reply

Can you please open a bug for this with exact description of the problem? :)
https://bugzilla.wikimedia.org/enter_bug.cgi
Thanks! Florianschmidtwelzow (talk) 17:54, 10 June 2014 (UTC)Reply

Watchlist should not contradict long-established conventions

[edit]

I'm not sure why it was decided that the mobile watchlist view needs to be so different from the desktop one, but it was a poor one, frankly. It defaults on first load to an alphabetical view, meaning a wasted click in getting away from that. Then for some reason it shows multiple (how many? Who knows) edits to individual pages, instead of the most recent edit to each page. Maybe some people want that; fine. Make it an option. I just want a watchlist that matches the functionality of the one I've been using for the last 12 years. Is that so hard?

I'll keep switching back to desktop mode until this is fixed. — Scott talk 11:07, 12 June 2014 (UTC)Reply

Hello Scott? Maybe the right place for this is bugzilla? ;)
https://bugzilla.wikimedia.org/enter_bug.cgi?product=MobileFrontend&component=Feature%20requests
Thanks! Florianschmidtwelzow (talk) 12:37, 12 June 2014 (UTC)Reply

Fix issues please

[edit]

Hi there is an issue with mobilefrontend because you carnt edit the page in mobile view and you have to be log in to edited the page even if it is unprotected. Please fix the background colour. if you visit extension:MobileFrontend in mobile view and look at the infobox for extension it looks really different to desktop Because it doesent have collapse and there's no colour. 86.135.249.133 12:35, 17 June 2014 (UTC)Reply

Hello! To the point with edit to unprotected pages if you logged out:
For now, anonymous editing isn't enabled by default (you can use $wgMFAnonymousEditing in LocalSettings to set to true to enable anonymous editing). Currently we are working on to enable anonymous editing in alpha mode:
https://gerrit.wikimedia.org/r/#/c/138802/5
So, this isn't really a bug, more an enhancement, but actual there are more things to do, before anonymous editing can moved to stable as enabled by default: https://bugzilla.wikimedia.org/show_bug.cgi?id=53069
Currently there can be curious errors :)
TO the second problem with "color of infobox":
What you mean exactly? That the infobox isn't green? I haven't looked into it deeply, but the class givng the color is ext-status-infobox-header which currently seems to be has only the target desktop, so not really a problem of MobileFrontend i think. But for this, it's better to open a bug on bugzilla https://bugzilla.wikimedia.org/enter_bug.cgi?product=MobileFrontend&component=stable then we can investigate and see what we can do :D Florianschmidtwelzow (talk) 12:47, 17 June 2014 (UTC)Reply
Oh ok. But it looks really bad on tablet because when viewing a page that is ment to have colour. It does not show. 86.135.249.133 19:44, 18 June 2014 (UTC)Reply

How to show TOC on MobileFrontend?

[edit]

I read "Configuration settings" section on this page, but there is no settings about table of contents. How do I configure MediaWiki to show TOC on MobileFrontend?

Or, should I edit some extension script files to do so? 202.162.155.93 18:39, 23 June 2014 (UTC)Reply

Hello! On mobile device (except tablets) the TOC is never shown, because the collapsible sections take the function of TOC. Mobile devices are much smaller as desktop, so the thought was: no waste place for a toc, show the sections instead :)
On tablet mode the TOC is shown, bc there is much more place ;) Florianschmidtwelzow (talk) 19:47, 23 June 2014 (UTC)Reply

Why "read in another language" button changed its color randomly?

[edit]

I've seen lots of changes about "read in another language" recently but this one (starts from 2 days ago? on wikipedia) is the most questionable. The new color is too bright and doesn't match others well, IMO. And I even wonder why we need this change in the first place? fireattack (talk) 09:07, 28 June 2014 (UTC)Reply

Hmm, what you mean? I haven't see any changes in desktop site (left navigation "Languages") and in mobile (bottom of site -> button "languages") :) Florianschmidtwelzow (talk) 14:01, 28 June 2014 (UTC)Reply
It was darker blue, now it becomes brighter. I use mobile site everyday so I can instantly find this change. I don't know which part of source code controls it though. fireattack (talk) 22:34, 28 June 2014 (UTC)Reply
Ah, now i know, what you mean :)
The new button now follows the new mediawiki-ui design (see the styleguide for example: https://tools.wmflabs.org/styleguide/). The change was first longer time ago in alpha (Experimental) and beta mode of MobileFrontend and now changed into stable for all users.
The reason for this change is: UX standardization :) The goal is to provide a standardised user interface for desktop and mobile site with the needed customization (font size, action elements and so on), but the basic elements are the same.
Hope that answers your questions :) Florianschmidtwelzow (talk) 01:31, 29 June 2014 (UTC)Reply

mobilefrontend is used to edit the document content without logging way?

[edit]

Hello. It is a new developer wiki.
Log in to edit the document without the desktop environment are possible, the log should document mobilefrontend editing.
I do not have to log in to the wiki article I would like to enable editing.
175.210.67.219 02:03, 6 July 2014 (UTC)Reply

Hello! I don't understand, what you want, sorry :/ Do you mean, that you want to enable anonymous editing in MobileFrontend? Florianschmidtwelzow (talk) 14:39, 6 July 2014 (UTC)Reply
yes. that's right. but i this problem solved.
adjust value $wgMFAnonymousEditing in MobileFrontend.php.
I am sorry. Because it is a foreigner, English can not be good. :( 175.210.67.219 17:32, 10 July 2014 (UTC)Reply
Hello,
better is to set $wgMFAnonymousEditing to true in LocalSettings.php, so you don't need to adjust the value every time you update MobileFrontend :) Florianschmidtwelzow (talk) 17:59, 10 July 2014 (UTC)Reply
[edit]

Hi, I have a problem with the link "mobile version". On my site, if I access via mobile device, everything works fine, but if I click on "Desktop" and then try to go back to the mobile version I get an error.

It seems to load for about 30-40 seconds with the text "Creating a secure connection" and then I get the message "The webpage is not available".

On the local server, however, everything works perfectly and I get no errors... Any fix for this?

I have Mediawiki 1.22.6 37.77.117.146 03:31, 14 July 2014 (UTC)Reply

Hello,
can you provide the link to your wiki website as an example? I think, that your server doesn't support secure connection over https, and that there is the problem. Can you give us your configuration settings you set for MobileFrontend in your LocalSettings.php? Florianschmidtwelzow (talk) 06:09, 14 July 2014 (UTC)Reply
Thank you for your reply, I found the solution!
I had not activated the "SSL", a careless mistake, now everything works! 37.77.117.146 15:50, 14 July 2014 (UTC)Reply

Create a new Wikipage after searching?

[edit]

Hi guys,

I'm running 1.23.1 w/the newest mobile front end, and I'd like to customize it a bit..

First question: When searching for a page that doesn't exist, at this point it says: "No page with this title."

Is there an easy way to add a prompt: Be bold: "Create a new page" with a link to do that? MarkJurgens (talk) 01:19, 18 July 2014 (UTC)Reply

Hello, the "no page with this title" is only an information. Normally a user can click "search within pages" to find maybe a page containing the query. But there is no other "easy" way to create a page in mobile frontend. Maybe you can open a feature request for MobileFrontend on bugzilla, so we can discuss the use case and maybe implement a cool solution for that problem :)
https://bugzilla.wikimedia.org/enter_bug.cgi?product=MobileFrontend&component=Feature%20requests Florianschmidtwelzow (talk) 07:38, 18 July 2014 (UTC)Reply
https://bugzilla.wikimedia.org/show_bug.cgi?id=68289
Just did! Hope that helps and it's not a duplicate. MarkJurgens (talk) 02:22, 20 July 2014 (UTC)Reply
See a workaround here: Show red link to create a new page Suanfazu (talk) 04:31, 27 July 2014 (UTC)Reply
[edit]
I'd like to add a logo using $wgMobileFrontendLogo
but this path (noted in the docs) doesn't exist.
/MobileFrontend/stylesheets/images/mw.png
Is there a new path?
Where do I drop my logo.png file?
I only have a vague understanding of how $wgExtensionAssetsPath might be used to fix this.
Thanks! MarkJurgens (talk) 01:29, 18 July 2014 (UTC)Reply
Hello! For the $wgExtensionAssetsPath variable you can see the manual page: Manual:$wgExtensionAssetsPath It's "simply" the extension folder :) The standard value of $wgMobileFrontendLogo is false and with false no image will be used (i have changed that in the table). So, if you want to use an image, copy the 35 × 22 px image to an known location, e.g. images/ in root of your mediawiki installation and set following path: "{$wgScriptPath}/images/image_for_mf.png". This is all :) Florianschmidtwelzow (talk) 07:34, 18 July 2014 (UTC)Reply
Sorry Florian, I don't understand. You need to say it more simply step by step.
I did the following
1. Made an image - mw.png
2. Uploaded it to the /extensions directory
3. Then set this in my local settings:
$wgMobileFrontendLogo = "{$wgScriptPath}/mw.png";
And nothing changed.
Update:
Ah ha!
$wgMobileFrontendLogo = "{$wgScriptPath}/mw.png";
And then drop the image in the ROOT of your mediawiki installation (same spot as your local settings)
Just a note: Simple examples with the entire line of code are really helpful for the some (like me) who are in a little over their heads. ;) Mark Jurgens 01:06, 20 July 2014 (UTC)
Just to clarify, what you have tried :)
The First try ($wgMobileFrontendLogo = "{$wgScriptPath}/mw.png";) will try to load the image from your wiki's script path (there, where the inedx.php is, probably the wiki root). That won't work, because you uploaded the image to extensions/ not into the wiki root :)
-> Solution for this way: Change in LocalSettings.php to: $wgMobileFrontendLogo = "{$wgScriptPath}extensions/mw.png";
The second ($wgMobileFrontendLogo = "/images/mw.png";) tries to load the image from the absolute server path (important is: absolute path). So, if your wiki installation is at /var/www/wiki/ the server tries to load from /images which is an directory at the same position as /var. This is impossible, too, because you uploaded the image not to this absolute dir.
-> Solution for this: Change the value to the solution of first one, or (if you want to upload the image to images/ of your wiki) then do:
  1. Move mw.png from extensions/mw.png to images/mw.png
  2. Change in LocalSettings.php: $wgMobileFrontendLogo = "{$wgScriptPath}images/mw.png";
The third ($wgMobileFrontendLogo = "$IP/extensions/mw.png";) is the most false way :) $IP is the absolute path to your wiki installation, e.g. /var/www/wiki/. The Browser will try to include the image using an relative path which results in an construct like: http://example.com/wiki/var/www/wiki/extensions/mw.img. This can't work :)
-> Solution: Use the solution of the first one ;) $IP is, simply said, only for installation of extensions or skins.
Hope that helps you! Florianschmidtwelzow (talk) 01:53, 20 July 2014 (UTC)Reply
Thanks Florian, I updated the above comment minutes before you replied. :)
I figured it out using option one.
Now, any way to make that image look good on a retina (iphone) display? It sure looks fuzzy. MarkJurgens (talk) 02:19, 20 July 2014 (UTC)Reply
I added this code to the localsettings.php file to no effect:
$wgMobileFrontendLogo = "{$wgScriptPath}/konjo.png";
Has anyone come up with a solution to add a logo image header?
https://www.mediawiki.org/wiki/Extension%20talk%3AMobileFrontend/2014#c-Iantresman-2014-11-09T13%3A40%3A00.000Z-Larger_site_logo 173.73.158.163 (talk) 00:53, 3 January 2017 (UTC)Reply
I have done the same and no effect either. 111.220.142.238 (talk) 05:16, 25 June 2021 (UTC)Reply

Retina resolution icons?

[edit]

Is there capability for HD icons? (Retina on iPhones/iPads)

The Home, Random, Watchlist, Settings, and LogIn buttons just look too fuzzy, even on an old iphone4.

I didn't see it in the feature requests, I can make feature request in bugzilla but I wanted to check here first. MarkJurgens (talk) 02:26, 20 July 2014 (UTC)Reply

Actually there is no feature request for it. Can you create one? Florianschmidtwelzow (talk) 15:01, 22 August 2014 (UTC)Reply

Blank pages for mobiles

[edit]

Hi. Even updating to the latest Mediawiki 1.23.1 I am getting blank pages when I try to view my wiki in a mobile device using the Mobile frontend extension. Help! 1.9.185.104 07:21, 20 July 2014 (UTC)Reply

Whoops. Sorry, updated the latest version of the extension and it seems ok now. 1.9.185.104 07:36, 20 July 2014 (UTC)Reply

Where to find older versions

[edit]

Hello, i am running WikiMedia 1.15.0 and i wanna install MobileFrontend to it, and i dont know where older versions are stored at? Where to download? ArsenArsen1 (talk) 10:38, 21 July 2014 (UTC)Reply

Hello,
you can find older versions on github e.g.:
https://github.com/wikimedia/mediawiki-extensions-MobileFrontend
Just click on "branch: master" and select the version you want. MF has no own version numbering, so you can only choose between the MW version numbers.
But please consider to update your MediaWiki version. MW 1.15 isn't supported anymore and MobileFrontend has maybe some bugs in the older versions which are fixed in newer versions. Florianschmidtwelzow (talk) 12:19, 21 July 2014 (UTC)Reply
0 relases, or in branches, or ... ArsenArsen1 (talk) 12:23, 21 July 2014 (UTC)Reply
Then you did something wrong :D This is, e.g. the Link for the version 1.19:
https://github.com/wikimedia/mediawiki-extensions-MobileFrontend/archive/REL1_19.zip
Earlier there does not exist some release. Florianschmidtwelzow (talk) 12:40, 21 July 2014 (UTC)Reply

Mobile Frontend with Universal Language Selector extension problem

[edit]

I 've been using the Universal Language Selector extension for input as well as for webfont it probides. However, installing and enabling Mobile Frontend prevents the ULS extension webfont functionality. Is this a known issue or is there a fix for it.

MediaWiki 1.23.1 PHP 5.3.10- MySQL 5.5.38- Lua 5.1.5 Elasticsearch 1.2.3 Using latest MobileFrontend and ULS extensions from Git. Wikimanz (talk) 06:07, 28 July 2014 (UTC)Reply

Webfonts and inputmethods are not available for MobileFrontend. We did not test and deploy ULS for mobile interface. Thanks. Santhosh.thottingal (talk) 09:41, 28 July 2014 (UTC)Reply

Mobilefrontend and facebook comments extension

[edit]

Hi, The extension does not work on the mobile version, the box to post comments not appear. How I can fix this problem?

Mediawiki 1.22.6 151.47.120.49 02:03, 31 July 2014 (UTC)Reply

Hello,
I think you mena this Extension? https://www.mediawiki.org/wiki/Extension:FacebookComments
MobileFrontend doesn't support the Hook used by FacebookComments, so there isn't an easy way to fix this. Florianschmidtwelzow (talk) 10:17, 31 July 2014 (UTC)Reply
Yes, precisely that! Ok, thanks for the reply! 37.77.117.146 03:04, 1 August 2014 (UTC)Reply

Mediawiki homepage design

[edit]

Hi.

I wonder, how i design my viki homepage? I have custom homepage already, but when i use MobilFrontEnd plugin my homepage is broken for mobil version. And when i upgrade Mediawiki version (1.18 to 1.23) my homepage is broken and my text is shifted and broken.

My viki is http://viki.gameofthronestr.com

Thank you for suggestions and answers. 78.167.231.63 22:11, 1 August 2014 (UTC)Reply

Hello!
Yeah, your homepage is not very well formatted for mobile devices :) I think all is explained here and here how to get a good homepage for mobile devices :) Florianschmidtwelzow (talk) 19:18, 2 August 2014 (UTC)Reply

Requires Mantle extension?

[edit]

When the software is downloaded through git apparently a version is installed that requires the Mantle extension. There is nothing however in the documentation about this. And installing the Mantle extension is not described as well. AdSvS (talk) 15:45, 18 August 2014 (UTC)Reply

Yes, the actual MobileFrontend (from git master) requires the Extension Mantle. I will add this to the Extension page, thanks!
Just as info for you: Simply download the Extension (from Extension page) and add this line to your LocalSettings.php:
require_once "$IP/extensions/Mantle/Mantle.php";
Florianschmidtwelzow (talk) 17:48, 18 August 2014 (UTC)Reply
  • Added Mantle Prerequisites
  • Added Installation section to Mantle
Thanks for reporting this! Florianschmidtwelzow (talk) 17:59, 18 August 2014 (UTC)Reply
Thanks! Works fine. AdSvS (talk) 18:13, 18 August 2014 (UTC)Reply
With MediaWiki 1.24 being released yesterday I've started to investigate upgrade steps and I bumped into this new prerequisite. This has me concerned as Extension:Mantle current shows Release status: experimental, rather than stable. We generally don't consider an extension for installation on our wiki unless it has reached stable status. Is there any way to either a) get Mantle to a stable status or b) remove the prerequisite in the REL1_24 branch of MobileFrontend?
Having a mobile friendly solution is critical in this day and age, so it seems were stuck between a rock and hard place with regards to deploying MediaWiki 1.24. Peculiar Investor (talk) 16:33, 27 November 2014 (UTC)Reply
The REL1_23 branch of MobileFrontend still works on MediaWiki 1.24.0 and doesn't requires Mantle. Egel (talk) 17:53, 28 November 2014 (UTC)Reply
MobileFrontend requires Mantle (and i really mean require ;)). Sure, it's possible to copy the contents, functions and the entire code of Mantle to MobileFrontend, but it's a lot of work and i'm sure, that the mobile web team doesn't have the resources to that. I'm sure, you can install Mantle without any problems, and if you have some, ask here to find a solution :) Florianschmidtwelzow (talk) 18:16, 28 November 2014 (UTC)Reply
Thanks for the information. I run a small wiki and try to stay current with MediaWiki software releases. When we update our version of MediaWiki, our policy has been to update Extensions to the matching version. Not wanting to live too much on the bleeding edge, our policy on Extensions recommends that we stick to Stable versions that are widely used. As far back as I remember, this is the first time we've run into this type of dependency issue. I would hope that MediaWiki developers would understand the rationale behind these policy decisions and attempt to keep core and extension development in sync so that other sites don't have to follow Wikipedia's software deployment strategy geared towards testing and running software that is under development. In this particular case, the dependence on an Extension with status = experimental is challenging. Peculiar Investor (talk) 15:36, 1 December 2014 (UTC)Reply
Most of the software used by Wikimedia is under active development. Mantle is used on a wide range of Wikipedias and other Wikimedia wikis. I run Mantle, too. Mantle is "just" an extension for code sharing, in fact it contains a merged version of the removed MobileFrontend code to use it in other extensions, too (like Flow). I suggest, that you test Mantle in your test installation, in my opinion there isn't a point for don't use it in production.
P.S.: The development of Wikimedia extensions is kept in sync, all extensions deployed on Wikimedia servers working with the correspending wmf versions (wmf7 e.g. of MobileFrontend works with Mantle wmf7 and ConfirmEdit wmf7 for example and so). Florianschmidtwelzow (talk) 21:13, 1 December 2014 (UTC)Reply
The Mantle extension is still required in current version of MobileFrontend (REL1_24 2014-12-02T00:26:32 011e6c1) but reference to that requirement was dropped from Extension:MobileFrontend page. 70.114.230.70 20:08, 17 January 2015 (UTC)Reply
Yes Readded with the notice, that Mantle is only required for MediaWiki 1.24 and older. Florianschmidtwelzow (talk) 11:51, 5 February 2015 (UTC)Reply
[edit]

Why don't red links show as red links in Mobile? I'd like to (a) know that the page editor has created a link (b) know that the article doesn't exist, (c) have a chance to create that article by clicking on a red link, (d) have a chance to read about the fact that an article at that title has previously been deleted. I can do all of that on desktop: why not on mobile? PamD (talk) 18:52, 18 August 2014 (UTC)Reply

Hello!
There are two config variables to change how redlinks are handled:
$wgMFShowRedLinks (show redlinks in stable mode) and $wgMFShowRedLinksAnon (show redlinks for anonymous users) Florianschmidtwelzow (talk) 19:02, 18 August 2014 (UTC)Reply
Is there a bug about enabling those by default? Nemo 06:11, 19 August 2014 (UTC)Reply
Uhm, i think not exactly for this. But what i know is, that the Mobile web team has plans to deprecate this feature (remove redlinks). But i don't know when. Florianschmidtwelzow (talk) 14:36, 19 August 2014 (UTC)Reply
If there are such plans, please create a bug to track them. Nemo 09:53, 21 August 2014 (UTC)Reply
Added: bug 69849 Florianschmidtwelzow (talk) 12:27, 21 August 2014 (UTC)Reply
Is there a workaround for the REL_1.23 version, which doesn't appear to include those options? 97.120.69.224 23:06, 31 December 2014 (UTC)Reply
For branch REL1_23 the easiest way would be to remove the contents of this function:
https://github.com/wikimedia/mediawiki-extensions-MobileFrontend/blob/REL1_23/includes/MobileFormatter.php#L152
But i suggest to just upgrade to MW1.24, which has these options. Florianschmidtwelzow (talk) 18:17, 2 January 2015 (UTC)Reply

How to configure menu

[edit]

Is there a way to configure the mobile menu? AdSvS (talk) 20:33, 18 August 2014 (UTC)Reply

Actually no. But there is a feature request for this: bug 63459 Florianschmidtwelzow (talk) 20:47, 18 August 2014 (UTC)Reply

Table border shows

[edit]

With the current version of MobileFrontend tables show borders where they didn't in earlier versions. Is this meant to be? AdSvS (talk) 20:40, 18 August 2014 (UTC)Reply

I don't know exactly, what you mean, but tables in MobileFrontend should have a border, have you an example where you can describe what you mean? Florianschmidtwelzow (talk) 20:51, 18 August 2014 (UTC)Reply
If you go to www.shopping2020.nl and click on Mobile View at the bottom of the page, you can see what I mean. Borders are around every element it seems, not only tables.
In earlier versions, as I remember, there were no borders at all. Anyway, those borders are ugly! :-) AdSvS (talk) 09:34, 19 August 2014 (UTC)Reply
Hello! Sorry, that i haven't answer here :/ I don't see any border at the tables? Have you fixed the problem? If yes, how? Florianschmidtwelzow (talk) 10:49, 15 September 2014 (UTC)Reply
Yeah, we fixed the 'problem' by adding
.content table td, .content table th {
   border: 0;
   width: 100%;
}
to MediaWiki:Mobile.css AdSvS (talk) 12:09, 15 September 2014 (UTC)Reply

Remove iPad and tablets from mobile detection

[edit]

I always hate when I come across Wikipedia with my iPad and am redirected to the mobile view. Mobile styles are optimised for devices with small screens like phones. They are also less functional than Desktop Sites, and tablets shouldn't be considered "mobile devices". --Bachsau (talk) 18:29, 19 August 2014 (UTC)Reply

Several hundreds users per day agree with you, see m:Research talk:Mobile editor engagement/Editor activation. Nemo 09:42, 21 August 2014 (UTC)Reply
Sorry I get irritated when people don't post full facts, and gloss over certain facts just to back a point (Nemo I get that you don't like the mobile site). I will respond to Nemo separately but Baschau since you are on a MediaWiki discussion page, if you have a 3rd party MediaWiki you can turn this off with $wgMFShowMobileViewToTablets = false; If you dislike it on Wikipedia, we purposely give you the opportunity to click the desktop view link at the bottom and you should never be redirected again.
To reply to Nemo, firstly you mean 'editors' not 'users' (this data you post to says nothing about readers) and as you point out this is not a like for like comparison as currently no anonymous editing. It will be interesting to see how adding anonymous editing effects this. We just pushed a change to enable it in the alpha mode of the site, to start seeing what interest it gets.
You also forget to mention the data around toggling between mobile and desktop site.
To quote Maryana [1]
"Before the redirect, 13% of pageviews from tablets were hitting the mobile site, meaning a non-trivial chunk of users had opted into the mobile experience even before we were serving it to them as the default.
After the redirect, 95% of pageviews from tablets were hitting the mobile site, meaning a fairly small number of users are opting out of the mobile experience we're serving – smaller than the number of people who were opting out of the desktop experience before the redirect :)"
[1] https://lists.wikimedia.org/pipermail/mobile-l/2014-June/007410.html Jdlrobson (talk) 16:27, 21 August 2014 (UTC)Reply
Jdlrobson, I do not understand the point of your reply: the link was a useful resource for me and contained all the context needed. Why did you make it personal instead of staying on topic? Also, nobody mentioned editors or readers in this discussion before you and there is no need to put words in Nemo's or Bachsau's mouth. 213.204.37.227 15:39, 1 September 2014 (UTC)Reply

Replace this page with Flow or a standard talk page

[edit]

Liquid Threads doesn't work on mobile, the software is very buggy, and I usually can't find messages I need to reply to due to these bugs.

As a result I and seemingly others rarely use this page and it's a shame as a lot of people contribute to this page. Would anyone be against to turning this into a Flow page or a standard talk page? It would at least increase my participation here.

Ideally I'd love us to use Flow and use this as a way of improving that software. Thoughts welcomed. Jdlrobson (talk) 19:42, 21 August 2014 (UTC)Reply

> Liquid Threads doesn't work on mobile
That's the real shame at all :/
> it's a shame as a lot of people contribute to this page
Not answering to problems/questions on this page doesn't resolve the real problem?! But i know, what you mean :)
> Would anyone be against to turning this into a Flow page?
Please! Not against, i'm totally with you.
> ... or a standard talk page?
Argh, for me, better LiquidThreads as a standard talk page :/ Florianschmidtwelzow (talk) 20:11, 21 August 2014 (UTC)Reply
I am using a kindle and stumbled upon this: this talk page is working fine for me. On what mobile devices does it not work? 213.204.37.227 15:44, 1 September 2014 (UTC)Reply
In principle it's working, but this isn't what we want, i think :) It's difficult to follow discussions and reply to other posts on a small screen (like my HTC One, and this isn't a "really" small screen). Look at these images, comparing LQT and Flow on the One:
(sorry, but for the LQT i have to take two photos ;))
LQT (not mobile optimized):
File:LQT1.png
File:LQT2.png
Now, Flow:
File:Flow mobile HTC One.png
I prefer Flow! It's much easier to follow discussions on mobile phone as in LQT, it looks much better and more organized. And the answer area: It's a mobile optimized text input, no overloaded edit screen with (for mobile users) useless functions. So, in my point of view: Flow for dicussions is much better as LQT, at least on a mobile device :) Florianschmidtwelzow (talk) 16:44, 1 September 2014 (UTC)Reply
I'm fine with anything which increases participation.
Personally I prefer wikitext and I won't follow the talk page if it's converted to Flow. I'm just one person, so if one other person is allowed to participate who otherwise wouldn't (e.g. Jon) I'm already compensated. :-) Nemo 13:06, 2 September 2014 (UTC)Reply

Exclude from mobile

[edit]

Is there some css class we can use to exclude something from mobile view? Just like class="noprint" excludes something from printing AND pdf exports? Geraki (talk) 13:52, 23 August 2014 (UTC)Reply

Yes, class nomobile Nemo 14:07, 23 August 2014 (UTC)Reply
But you should think about to provide your content optimized for desktop AND mobile, instead of exclude the content :) Florianschmidtwelzow (talk) 19:58, 24 August 2014 (UTC)Reply

How i display Adsense ads on Mediawiki Mobile? (MobileFrontend Extension)

[edit]

Hi.

I am using MobileFrontEnd extension for Mediawiki mobile display. I wonder, how i display Adsense ads on mobile version?

Thank you. 81.215.133.163 18:34, 28 August 2014 (UTC)Reply

There is no "standard" way to reach this (and no extension, if i'm right). But you can do it manually, with a little knowledge. There are several hooks implemented in MobileFrontend:
User:Florianschmidtwelzow/MobileFrontend/Hooks
Now you can create a new Extension (or just as code in LocalSettings.php (or something required by it), adding a function to this hook and load the adSense code.
Another (maybe easier) way is to edit the skin used in MobileFrontend, called Minerva. The mean file, that should be interesting to reach your goal, is SkinMinerva.php/MinervaTemplate.php in includes/skin/ folder of Mobilefrontend. There you can add the AdSense code where you want :)
Hope that helps you! Florianschmidtwelzow (talk) 20:37, 28 August 2014 (UTC)Reply

Hiding content on desktop devices

[edit]

Hi,

Is there any possibility to hide some parts of content for desktop devices but still keep them visible for mobile devices? I mean something like nomobile class but regarding to desktop (it may be called nodesktop class in this situation).

Greetings, Von Wafeln (178.42.89.242) 17:49, 5 September 2014 (UTC)Reply

Only personal interest: What should this be used for? The goal should be to bring the same content to all devices, so the best way is, to don't special handle some device categories :)
There is no way to do this out of the box, iirc. But it's possible that you create your own class. Just edit MediaWiki:Common.css and add:
.onlymobile {
display:none;
}
Common.css will not be loaded in MobileFrontend, so the content is visible on mobile devices using MobileFrontend, but hidden on desktop deveices. Florianschmidtwelzow (talk) 20:50, 6 September 2014 (UTC)Reply
Thanks a lot. I would like to use it to display on both groups of devices different user manuals. Maybe it's unnecessary, but I just learned something new, that I could use in any upcoming situation :) Von Wafeln (178.42.89.242)21:22, 7 September 2014 (UTC)Reply
Maybe is a better solution to create two seperate manual pages (and link them)? Maybe as subpages of the manual page itself. So your users have the chance to see the content from every device (e.g. if i want to read the manual at my pc to follow the steps at my smartphone) :) Florianschmidtwelzow (talk) 07:20, 8 September 2014 (UTC)Reply
Sure, I've created two separate pages and wanted to make visible links for different devices on main page. Well thats good point I have to think about it :) Von Wafeln (178.42.89.242) 16:46, 8 September 2014 (UTC)Reply
Maybe the better solution is to label the links (e.g.
Desktop browsers: Helplink
Mobile browsers: Helplinkmobile
instead of hiding content :) Florianschmidtwelzow (talk) 17:48, 8 September 2014 (UTC)Reply
I'll try :) Von Wafeln (178.42.89.242) 19:37, 8 September 2014 (UTC)Reply

Doesn't work in MediaWIki 1.19

[edit]

I downloaded the "mediawiki-extensions-MobileFrontend-REL1_19", then I install it to my Wiki's /extensions, also add

require_once "$IP/extensions/MobileFrontend/MobileFrontend.php"; $wgMFAutodetectMobileView = true;

to my LocalSettings.php

when I open my wiki, I got:

Warning: require_once(/[my path]/extensions/MobileFrontend/library/WURFL/Application.php) [function.require-once]: failed to open stream: No such file or directory in [my path]/extensions/MobileFrontend/MobileFrontend.php on line 27

then I go to check my extensions/MobileFrontend, I can't find "/library/WURFL/Application.php", also I check MobileFrontend.php line 27, there just "require_once( WURFL_DIR . 'Application.php' ); "

well, I don't understand how to fix it. Chelinchan24 (talk) 17:18, 8 September 2014 (UTC)Reply

Hello! You should consider to update your MediaWiki installation to the newest supported version (1.23.3) or at least to the latest legacy version (1.22.10) to use MobileFrontend. The REL1_19 is really old and i can't imagine, that this branch is supported anymore :)
I would like to cite MaxSem for this (from here):
Unfortunately, the 1.19-era MobileFrontend is very antiquated, and is quite hard to set up for use in a non-Wikimedia environment. This particular problem has legal grounds (because the developers of a library used in this version decided to become copyright trolls it has beed removed from source control history, breaking old versions). We recommend you to upgrade your MediaWiki and install a corresponding version of MF. The latest release, 1.21, has particulary nice features like the ability to automatically display mobile content for mobile users without having to mess with frontend proxy. Florianschmidtwelzow (talk) 17:40, 8 September 2014 (UTC)Reply
I can't use 1.23 or 1.22, my php is 5.2, MySQL is 5.1... Chelinchan24 (talk) 14:23, 9 September 2014 (UTC)Reply
Then you have just the chance to try to install the REL1_20 or REL1_21 or REL1_22 branch of MobileFrontend and look if it works or not. Or maybe you have the chance to update your PHp version?
Otherwise you have to install wurfl first, to use MF. The AutoDetect Feature isn't in this old version, too. There can be other features documentated on the Extension page, which aren't in this old code :) Florianschmidtwelzow (talk) 16:08, 9 September 2014 (UTC)Reply

Mobile view linking problem. MobileFrontend

[edit]

Mediawiki 1.22.0

Hello,

I have two wikis linked 'mainwiki.com' and 'de.mainwiki.com' now I have installed MobileFrontend, but I cant link the two wikis via $wgMobileUrlTemplate. How to link these sites together? Im using 'm.mainwiki.com' and 'de.m.mainwiki.com' for mobile.

Linking on desktop view works perfect. The problem seems to be that the URL´s for the sites are not similar as of lenght. Is there anyway to link these sites without changing 'mainwiki.com' URL I.E. 'fr.mainwiki.com'?

Thanks. Samuel Peter9 (talk) 17:36, 17 September 2014 (UTC)Reply

In german Localsettings.php I have $wgMobileUrlTemplate = "%h0.m.%h1.%h2"; and in english $wgMobileUrlTemplate ="m.%h0.%h1";
So when I try to switch language i.e. from german to english it tries to look for URL 'mainwiki.m.com./'.
Has anyone have any suggestions? Samuel Peter9 (talk) 06:53, 18 September 2014 (UTC)Reply

Disable login and sign-up functionality?

[edit]

Hi - Is there any way to remove the login and sign-up functionality from the mobile app? The content of our wiki is a read-only resource, not intended for self-registration or modification. Along those lines, i'd want to remove the edit and favorite buttons as those are very prominent buttons on every page but require login and self-registration. These are not appropriate for our use case.

Thanks! 76.120.100.103 00:06, 22 September 2014 (UTC)Reply

Hello!
Sure, you can configure, what buttons a user see on top of a page. There is the configuation variable $wgMFPageActions, which you can set (for your use case) as follows:
$wgMFPageActions = array( 'talk' );
To disable all buttons expect "talk". Florianschmidtwelzow (talk) 05:31, 22 September 2014 (UTC)Reply
[edit]

What is the easiest way to edit the mobile footer links? Right now only privacy displays but I would like the disclaimer link to also appear. Thank you! Ostermayer (talk) 00:30, 30 September 2014 (UTC)Reply

Hello!
Sure, you can use the same way like described here, but replace SkinTemplateOutputPageBeforeExec with SkinMinervaOutputPageBeforeExec. Florianschmidtwelzow (talk) 07:01, 30 September 2014 (UTC)Reply
[edit]

When i used template FN and FNZ in en.wiki, I noticed that the footnotes when using mobile phones (Mobile view) do not appear correctly show (like references when show) and all that shows is the number or character that connects the template FN and FNZ, For example see my sandbox here, Where you will see when you press [1] (reference) the text displays correctly, And when you press 1 (footnote) you see only the number 1 Without the text. and please see the talk here. Mohammedbas (talk) 11:08, 30 September 2014 (UTC)Reply

The reason for this is, that the text extraction will be done with the selector ol.references, which is used by the cite extension. The generated overview of foot notes from FNZ is in div containers, so this can't work. The drawer will be visible because you use the reference class for the links, which is used for cite extension, too. So the reference drawer will be created, but without any text (which you reported here) :)
Solution:
Use the same code like cite to create the FNZ overview :) Florianschmidtwelzow (talk) 12:16, 30 September 2014 (UTC)Reply
Can you help to fix the problem, I'm not an expert in templates Al-bibas (talk) 09:57, 1 October 2014 (UTC)Reply
Hello!
Sorry, but maybe i'm not the right for templates :) The result of Template:FNZ should be something like this:
<ol class="references" style="list-style:none;">
  <li id="FN_1">
    <a href="#FN_1_back">
      <sup>1</sup>
    </a>
     <span class="reference-text"> Check it with yourself</span>
  </li>
</ol>
The style="list-style:none;" is very ugly, but needed, bc you have to reuse the references class for the ol (so MobileFrontend find it's contents). But ol has a decimal listing enabled, so you have to disable this with the element style. Now you only need someone, who can change the template in this direction :)
Hint: I don't see a reason to use a template for references, which reuses code of the cite extension :/ Florianschmidtwelzow (talk) 16:25, 1 October 2014 (UTC)Reply
Thanks Florian, it is working. Al-bibas (talk) 08:29, 2 October 2014 (UTC)Reply
Great :) Florianschmidtwelzow (talk) 11:10, 2 October 2014 (UTC)Reply

visualeditor abandoned

[edit]

is the visualeditor-support abandoned?

there is no support in the builds of the last weeks anymore? or how do i turn it on as default? anon 11:06, 3 October 2014 (UTC)Reply

Hello!
No, visualeditor on mobile devices is still enabled and should be available. But i see on dewiki, that the switcher icon isn't visible, so you can't see, that you can switch to visual editor (if you click at the position, where the switcher is normally, at the left side of the "Next" button, you can still switch). I will open a bug for it, this should be fixed asap. Thanks for reporting this! Florianschmidtwelzow (talk) 12:01, 3 October 2014 (UTC)Reply
thank you very much, does work now.
is there any option to turn ve on by default for all non-logged in users? anon 20:07, 3 October 2014 (UTC)Reply
> does work now.
Yes, we have hot-fixed and deployed it :)
> is there any option to turn ve on by default for all non-logged in users?
Unhappily no :( Florianschmidtwelzow (talk) 21:18, 3 October 2014 (UTC)Reply
[edit]

presently the link at the main page points to https://en.openbike.org/wiki?title=Main_Page&mobileaction=toggle_view_mobile

however, https isn't set up. How can I have it to point at http://... Tickle me (talk) 11:14, 9 October 2014 (UTC)Reply

Hello!
What is your value of $wgMobileUrlTemplate in your LocalSettings.php?
P.S.: You should think about to upgrade your MediaWiki version to at least MW 1.23 or any other supported version, support for 1.22 will be dropped in December 2014 :) Florianschmidtwelzow (talk) 11:39, 9 October 2014 (UTC)Reply
//$wgMobileUrlTemplate = 'mob.openbike.org';
$wgMFAutodetectMobileView = true;
I'm on hosted webspace (LAMP) so I can't configure Apache to send custom headers as described at Extension:MobileFrontend/Configuring_browser_auto-detection
I can send c. headers with PHP, (or htacces, I guess) but I don't know if that does the trick (it's not mentioned above), so I didn't set $wgMobileUrlTemplate, though I would like to. (subdomain mob.openbike.org is active) As it is, I guess I need to relay on $wgMFAutodetectMobileView, but setting up https would cost extra for a certificate--I'd like to do without. I could fiddle with the extension's source code, but that's not advisable, so I'm at a loss.
re:upgrade
will do Tickle me (talk) 17:44, 10 October 2014 (UTC)Reply
Hello!
Normally the link has the same protocol like all other links, too. Have you changed something in the files of MobileFrontend? Can you try to upgrade to MW 1.23 (is much more work, but if you planned to do that, it will be interesting, if the same issue is there, too). Can you post (maybe via a pastebin service) your non-priavte settings of your LocalSettings.php? Florianschmidtwelzow (talk) 19:31, 10 October 2014 (UTC)Reply
Hi! I've got the same problem. And I have MediaWiki 1.22 but now i don't have time to upgrade. It's always pain in the ass... Where is this https:// hardcoded?
Peter 193.34.162.150 09:47, 22 October 2014 (UTC)Reply
It's not hardcoded ;) I have now tested MW 1.22 with MF for MW 1.22, and there is no redirect to https, http is used. So it's a problem of your configuration (MW/MF or Server) Can you post your MobileFrontend related configuration variables in your LocalSettings.php? Florianschmidtwelzow (talk) 16:40, 24 October 2014 (UTC)Reply

How to design skins for mobile frontend?

[edit]

Normal skins for desktop view cannot be loaded in mobile frontend. How to design a skin to mobile frontend? Guoyunhebrave (talk) 19:27, 10 October 2014 (UTC)Reply

You can configure this using the unadvertised and therefore experimental global $wgMFDefaultSkinClass
$wgMFDefaultSkinClass = 'SkinNameClass'
I would be interested in how you get on with this. Jdlrobson (talk) 02:10, 14 October 2014 (UTC)Reply

Compatibility with other extensions

[edit]

Is there some documentation on making extensions that rely on custom css and js formatting compatible with MobileFrontend extension? Physikerwelt (talk) 15:15, 19 October 2014 (UTC)Reply

Hello,
not that i know. But, if your extension uses ResourceLoader, you can test your modules and set the mobile target for it:
$wgResourceModules['ext.ExampleExtension'] = array(
	'scripts'       => 'ext.ExampleExtensions.main.js',
	'dependencies'  => array(
		'jquery.cookie',
	),
	'targets' => array( 'desktop', 'mobile' )
);
Read more about it: ResourceLoader/Writing_a_MobileFrontend_friendly_ResourceLoader_module Florianschmidtwelzow (talk) 19:41, 19 October 2014 (UTC)Reply

Auto-detection not working

[edit]

Hi all,

I just installed a fresh 1.23 MW + MobileFrontend. Unfortunately auto detection does not work, only when I explicitly click on the mobile view link. HostmasterWiki (talk) 08:35, 2 November 2014 (UTC)Reply

I have the same problem. I suspected it might be an issue with APC which I installed recently, but removing that did not solve the problem. I have $wgMFAutodetectMobileView = true; yet Vector is loaded for all devices. Locke64 (talk) 03:44, 1 March 2015 (UTC)Reply
[edit]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.


$wgMobileFrontendLogo specifies only a small icon (35×22px). I'd like to show a large logo (or image) near the top of my mobile home page only. Is there a workaround? Can the image be responsive? Iantresman (talk) 13:40, 9 November 2014 (UTC)Reply
Currently this is not configurable. Open to ideas and to hear more about your use case and how that could be supported. Jdlrobson (talk) 01:29, 14 November 2014 (UTC)Reply

The three image show:

  1. How I'd like to display a header image as my logo for my mobile view
  2. My workaround, currently showing an image at the top of my home page content, with mf- class suffix (and hidden it from my desktop view with some css)
  3. How the page looks without an image on my mobile view (Android, 720x480)
I think a configuration setting using a variable in LocalSettings.php, eg.
  • $wgMFheaderImageAllPages = filename
  • $wgMFheaderImageHomePage = filename (overrides $wgMFheaderImageAllPages)
By default, I would envisage width=100%, and then users can use MediaWiki:Common.css to modify its position, size and whether it is fixed. Iantresman (talk) 19:30, 14 November 2014 (UTC)Reply
Has anyone come up with a solution to add a logo header on mobilefrontend? 173.73.158.163 (talk) 00:50, 3 January 2017 (UTC)Reply
Same question here. 111.220.142.238 (talk) 05:17, 25 June 2021 (UTC)Reply
Extension:WikidataPageBanner Jdlrobson (talk) 14:12, 25 June 2021 (UTC)Reply
The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

MediaWiki:Sidebar alternative

[edit]

Mediawiki uses MediaWiki:Sidebar (manual) to display various panels of information in the left column (in Vector) theme (eg. Support, Development, MediaWiki.org, etc). These disappear in the mobile view. Are there options to:

  1. Add menu items to the mobile menu button?
  2. Create a new horizontal drop-down menu at the top of each page?

Iantresman (talk) 13:55, 9 November 2014 (UTC)Reply

This has been requested before but we haven't quite worked out how. I'm reluctant to add a dependency on an undiscoverable MediaWiki page but would be happy if we had a config option that could be added to LocalSettings.php. Our main problem is the mobile side bar is radically different from that on desktop. See https://bugzilla.wikimedia.org/show_bug.cgi?id=63459 Jdlrobson (talk) 01:28, 14 November 2014 (UTC)Reply
I had to disable the skin because of this same issue of not reading the MediaWiki:Sidebar. The site heavily relies on the Sidebar for navigation. I hope it can be fixed. The WPTouch skin (it will stop working in 1.25) has these functions to pull data for the Sidebar. It just makes a long list of all the links on the Sidebar. Its not perfect but at least the links are there. Here's the code for it in case it can help:
<?php foreach ($this->data['sidebar'] as $bar => $cont) { ?>
 <?php foreach($cont as $key => $val) { ?>
  <li id="<?php echo Sanitizer::escapeId($val['id']) ?>"<?php
  if ( $val['active'] ) { ?> class="active" <?php }
  ?>><a href="<?php echo htmlspecialchars($val['href']) ?>"<?php echo Xml::expandAttributes( Linker::tooltipAndAccesskeyAttribs( $val['id'] ) ) ?>><?php echo htmlspecialchars($val['text']) ?></a></li>
 <?php } ?>
<?php } ?>
Choshi (talk) 23:12, 12 January 2015 (UTC)Reply

Optimised for mobile, but not on desktops

[edit]

How do I hide elements on my desktop Vector-skinned home page display, that are meant for display on mobiles only? eg.:

<div id="mf-homemobile">[[file:homepagemobileimage.jpg]]</div></pre>

Per [[Extension:MobileFrontend#Configuring_the_main_page|Configuring the main page]], the "mf-" class/id prefix adds the element to the mobile display. But it also displays on my desktop display.

*Is there a corresponding "nomobile" class (ie. "nodesktop") class?
*Is there a CSS snippet that can be added to [[MediaWiki:Common.css]]
*Is there another extension I need?

I am using MW 1.23.5. [[User:Iantresman|Iantresman]] ([[User talk:Iantresman|talk]]) 15:02, 13 November 2014 (UTC)
:This seems to work:
:*Add class="mf-homepage" to elements you want to display on mobile displays.
:*In [[MediaWiki:Common.css]], add: .mf-homepage {display:none}, ie:
:<syntaxhighlight lang='text'><div class="mf-homemobile">[[file:homepagemobileimage.jpg]]</div></pre>
I had tried to use id="mf-homemobile" with the corresponding #mf-homepage {display:none}, and while the element displayed as expected, the rest of the homepage on my mobile did not display, even though I had not used the "nomobile" class. [[User:Iantresman|Iantresman]] ([[User talk:Iantresman|talk]]) 15:24, 13 November 2014 (UTC)
::Yeh this is essentially what .nomobile does it just hides stuff in css. This is not ideal as any images inside that element and all its content will still get loaded on mobile. It's a tricky problem they we still haven't worked out how best to solve. You may be interested in [[Requests_for_comment/Allow_styling_in_templates]][[User:Jdlrobson|Jdlrobson]] ([[User talk:Jdlrobson|talk]]) 01:24, 14 November 2014 (UTC)
:::Can't you use something like the [http://www.appelsiini.net/projects/lazyload Lazy Load] jQuery plugin, which "delays loading of images in long web pages". It can also be set to ignore images that are not ":visible", hence they will never load. Perfect! [[User:Iantresman|Iantresman]] ([[User talk:Iantresman|talk]]) 17:35, 22 November 2014 (UTC)

== Specify alternative home page ==

My desktop MW 1.23.5 shows a particular home page (specified with [[Manual:FAQ#How_do_I_change_which_page_is_the_main_page.3F|MediaWiki:Mainpage]]. I couldn't see the option, but it would be useful to be able to specify:

*A different home page for mobiles/tablets. eg. $wgMFMainpage="My Mobile Home Page"
*A different home page for different mobiles and tablets (ie. based on screen size) [[User:Iantresman|Iantresman]] ([[User talk:Iantresman|talk]]) 15:11, 13 November 2014 (UTC)
:This is a cool idea although I'm not quite sure how it would work. Please log a feature request [https://bugzilla.wikimedia.org/enter_bug.cgi?product=MobileFrontend&component=Feature%20request here]. I doubt we'll be able to work on this but if we can work out how to do this and you can find someone to submit a patch or willing to code it I can help make it happen... [[User:Jdlrobson|Jdlrobson]] ([[User talk:Jdlrobson|talk]]) 01:26, 14 November 2014 (UTC)

== nomobile tag works in DIV, but not in TABLE ==

:I'm using the "nomobile" class which works fine in a surrounding <div class="nombile"> .. <.div>, but did not work in a table element, eg. <table align=center cellpadding=10 style="border-radius: 10px" class="nomobile"> [[User:Iantresman|Iantresman]] ([[User talk:Iantresman|talk]]) 17:29, 22 November 2014 (UTC)
::Feel free to add a table.nomobile class in your MediaWiki:Mobile.css
::We are hoping to deprecate use of .nomobile in the far far future and provide better ways to style content differently on mobile/desktop. [[User:Jdlrobson|Jdlrobson]] ([[User talk:Jdlrobson|talk]]) 10:29, 24 November 2014 (UTC)
:nodesktop? [[Special:Contributions/171.232.66.162|171.232.66.162]] ([[User talk:171.232.66.162|talk]]) 18:03, 14 February 2020 (UTC)

== Special:AllPages does not display well on mobiles ==

Special:AllPages lists articles in a tables. I've tried using MediaWiki:Common.css to override the table td cells without luck, eg.:

<pre>.mw-mf-special .mw-allpages-table-chunk td {display:block; border:0}</pre>

#I've tried adding !important, different paths, and clearing my Browser cache. Is there another solution?
#In the long term, it would make sense that a mobile friendly format is used, eg. divs, rather than tables/td [[User:Iantresman|Iantresman]] ([[User talk:Iantresman|talk]]) 16:17, 23 November 2014 (UTC)
:Should I be editing the Minerva Skin CSS instead? less/specials/common.less? [[User:Iantresman|Iantresman]] ([[User talk:Iantresman|talk]]) 16:39, 23 November 2014 (UTC)
::Try editing [[MediaWiki:Mobile.css]] instead. <code style="white-space:nowrap">-- [[[[User:Edokter|<span style="color:#006">User:Edokter</span>]]]] {{[[User talk:Edokter|<span style="color:#060">talk</span>]]}}</code> 22:49, 23 November 2014 (UTC)
:::That works great! Thank you. [[User:Iantresman|Iantresman]] ([[User talk:Iantresman|talk]]) 23:04, 23 November 2014 (UTC)
::::See also: https://phabricator.wikimedia.org/T65428 [[User:Jdlrobson|Jdlrobson]] ([[User talk:Jdlrobson|talk]]) 10:28, 24 November 2014 (UTC)
:::::Yes, I also noticed that many Special pages used tables, that don't show on mobile screens very well. A little bit of CSS in MediaWiki:Mobile.css (the counterpart to [[Manual:Interface/Stylesheets|MediaWiki:Common.css]], which makes table TDs into display:block, seems to be an OK workaround. [[User:Iantresman|Iantresman]] ([[User talk:Iantresman|talk]]) 12:00, 24 November 2014 (UTC)

== MobileFrontend and [[Manual:$wgUseFileCache|$wgUseFileCache]] ==

REL1_24. If [[Manual:$wgUseFileCache|$wgUseFileCache]] is true, enabling of MobileFrontend results in a Mediawiki Exception when any page is displayed in desktop mode to an anonymous user.

<pre>[7e68290e] /index.php/%D0%97%D0%B0%D0%B3%D0%BB%D0%B0%D0%B2%D0%BD%D0%B0%D1%8F_%D1%81%D1%82%D1%80%D0%B0%D0%BD%D0%B8%D1%86%D0%B0 
Exception from line 182 of /htdocs/includes/Hooks.php: 
Invalid callback in hooks for HTMLFileCache::useFileCache

Backtrace:

#0 /htdocs/includes/GlobalFunctions.php(3995): Hooks::run(string, array, NULL)
#1 /htdocs/includes/cache/HTMLFileCache.php(134): wfRunHooks(string, array)
#2 /htdocs/includes/MediaWiki.php(561): HTMLFileCache::useFileCache(RequestContext)
#3 /htdocs/includes/MediaWiki.php(435): MediaWiki->main()
#4 /htdocs/index.php(46): MediaWiki->run()
#5 {main}

StasR (talk) 14:50, 5 December 2014 (UTC)Reply

Solved by changing MobileFrontend.php:
$wgHooks['HTMLFileCache::useFileCache'][] = 'onHTMLFileCache_useFileCache';
to:
$wgHooks['HTMLFileCache::useFileCache'][] = 'MobileFrontendHooks::onHTMLFileCache_useFileCache';
Nicjansma (talk) 03:25, 14 December 2014 (UTC)Reply
Can you submit that as a patch so that devs can evaluate it? Nemo 10:37, 14 December 2014 (UTC)Reply
Many thanks! It worked. StasR (talk) 10:50, 14 December 2014 (UTC)Reply

How to hook onUserLoginForm?

[edit]

Hello! I'm using onUserLoginForm hook for add custom code on login page such as social auth. How can i make this on MobileFrontend Login Form? UksusoFF (talk) 06:15, 9 December 2014 (UTC)Reply