Extension talk:MobileFrontend
Contents
| Thread title | Replies | Last modified |
|---|---|---|
| Mobile Search Broken | 2 | 14:09, 23 May 2012 |
| Usage manual | 1 | 14:07, 16 May 2012 |
| Read me | 2 | 14:07, 16 May 2012 |
| Add dynamic context to the footer | 1 | 14:00, 16 May 2012 |
| Add "history" link | 1 | 11:29, 16 May 2012 |
| useformat key-value pair | 1 | 11:27, 16 May 2012 |
| Add "edit" link | 1 | 11:25, 16 May 2012 |
| Add "discuss" link | 1 | 11:22, 16 May 2012 |
| How Do we make to Mobile view stick? | 1 | 06:52, 18 April 2012 |
| class="noprint" | 0 | 15:53, 11 May 2012 |
| Common.css ignored? | 2 | 18:44, 27 February 2012 |
| Issues with MobileFrontend and possible rewrite | 12 | 01:30, 25 February 2012 |
| Unable to download snapshot | 2 | 23:12, 10 February 2012 |
| Bad performance | 1 | 17:58, 10 February 2012 |
| Site icons | 2 | 20:53, 8 December 2011 |
| Installation guide | 4 | 00:26, 21 November 2011 |
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?
You will need to enable OpenSearchXml extension (Extension:OpenSearchXml). I have updated the Extension:MobileFrontend installation instructions to reflect this.
Sorry for the confusion.
Is there a usage manual somewhere? I want to configure what content will be visible through this extremely useful extension, but there are no instructions. Tried to figure out from Wikipedia's main page, but couldn't figure anything out. Can someone please help out? 89.139.189.175 20:15, 22 December 2011 (UTC)
I've added a README file https://gerrit.wikimedia.org/r/7791 which hopefully will be a good starting point!
Is there are readme-file for this extension or a description?
Besides Extension:MobileFrontend? No, I don't think so. Your best bet is to try reading through the source code or ask specific questions here.
Added https://gerrit.wikimedia.org/r/7791 Let us know what is missing in the README and help it be more useful.
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.
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.
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, inf act. 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.
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!
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
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.
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.
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.
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
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.
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.
In our installation it seems to completely ignore the content of Mediawiki:Commons.css. Is there a setting for this? An alternative CSS page? G.Hagedorn 21:06, 8 December 2011 (UTC)
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.
- 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.
I'd like to se the horrid output buffer based hack replaced with implementation via a custom skin.
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.
- 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.
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).
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.
Shouldn't things like the login form simply (re-)use core code?
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.
Just as a note I've made a reply on the mailing list on this.
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.
Could someone fix this?
I tried Special:ExtensionDistributor/MobileFrontend just now. It works for 1.18.x and trunk. If you continue to have issues, please note them here (links are always helpful).
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?
You must have object caching set up, or WURFL will keep reinitializing on every request.
Please add instruction on setting up the icons. Both favicon and upper left corner logo settings are ignored in MobileFrontend (SVN trunk of today). I guess there are new configuration options - can someone add a bit of documentation? Also, the information that the front page will be ignored unless specifically reformatted is missing, I found it somewhere but fail to find it back so I could add it here; it is not linked two links deep away... G.Hagedorn 23:28, 6 December 2011 (UTC)
I've added information about configuration variables I could find here. The variable $wgMobileFrontendLogo is supposed to allow altering the logo; for the favicon I could not find a configuration variable.
What about installation guide? Requirements?
I copied the MobileFrontend folder to /w/extensions/ and added the following to LocalSettings.php:
# MobileFrontend Extension
require_once("$IP/extensions/MobileFrontend/MobileFrontend.php");
I also edited the following files:
- MobileFrontend.i18n.php (text)
- /views/layout/_search_webkit.html.php (logo)
- /views/layout/application.html.php (server, icon)
...and uploaded my logo to /images/ and /stylesheets/images/
It kinda works for me, however, all special characters in my articles are screwed up and so is the ToggleDisplay extension. Cheers,
Thank you. The new version of the extension works. I had previously prescribed the same thing, but getting some errors.
You realized somehow automatically redirect mobile users to link the mobile version with "useFormat=mobile"?
No, but it will probably work with Extension:WikimediaMobile. Unfortunately, I'm still stuck with the mobile subdomains. I already posted at MWUsers and ModRewrite. Cheers,
