Hey y'all,
Yesterday (Monday, 7th) Alex Monk submitted and subsequently back-ported
and deployed a fix for an annoying bug in the code that registers the
EventLogging schemas in the MobileFrontend extension [0]. The bug resulted
in browse and diff click events failing to log as associated schemas
weren't registered.
The patch that introduced the bug was merged on Tuesday, 25th August,
which, I think, means that it'd have been deployed on Thursday, 3rd
September – that's a long weekend's worth of data that we won't see again.
Thanks to Alex for squashing the bug so diligently.
–Sam
[0] https://gerrit.wikimedia.org/r/#/c/236239/
Hello together,
today I want to notice the members of this lthat that I've merged a (at least for me) very important change for MobileFrontend. By resolving task T74910, MobileFrontend now will use the mediawiki core login page instead of it's own implementation. That reduces code duplication and minimizes the cost of maintenance for MobileFrontend. On the other hand, extension developers now can customize the mobile and desktop login page on the same way.
More information can be found in the task, the associated tasks and changes.
Thanks to Jon for making this possible :)
Best,
Florian
Gesendet mit meinem HTC
Hey all,
I've been encouraged to write an update on a 1%* project that I've been
working on: separating the HTML formatter and APIs from the Minerva skin.
Right now, I've created a new extension, which contains the code,
associated configuration variables, and unit/integration tests [0] and am
running it alongside a cut down version of the MobileFrontend extension [1]
locally.
My long-term goal is to further separate out the HTML formatter into a
versioned library and to version the API extension so that we can make
smaller, more easily reasoned about changes to smaller, more easily
reasoned about components and update the (relative) titan that is the
MobileFrontend extension more responsibly.
My short-term goals are:
* to *cover* the new extension in integration tests so that I can make
structural changes
* to get the unit tests passing without hitting the DB
* to document the new extension thoroughly
* to reduce the binding between the two extensions to exactly one call [2]
* to get the extension deployed
Cool? Cool!
–Sam
* Not a typo
[0] https://github.com/phuedx/MobileView
[1] https://github.com/phuedx/mediawiki-extensions-MobileFrontend
[2]
https://github.com/phuedx/mediawiki-extensions-MobileFrontend/blob/dd9e99e0…
On 09/01/2015 11:30 AM, Ori Livneh wrote:
> We appear to be running a banner campaign on the mobile web site, driving
> people to download the mobile app:
>
> https://en.m.wikipedia.org/wiki/?banner=Aug2015_app_banner_2
> https://en.m.wikipedia.org/wiki/?banner=Aug2015_app_banner_1
>
> Campaign definition:
> https://meta.wikimedia.org/w/index.php?title=Special:CentralNotice&subactio…
>
> This isn't cool. This isn't us. We don't drive people from an open platform
> to a closed one.
I don't necessarily think it's a great idea to push people from web to
apps either, especially when we also have people working on mobile web.
I also do most of my mobile Wikipedia browsing on mobile web.
That said, I think that assessment is overly critical.
* The Android mobile app is fully free and open source (obvious, since
all of our stuff is, but worth re-iterating).
* They've done a great job on the app. In particular, they've
implemented features that are easier on app (or only feasible there),
like a user-friendly saved pages list and a nice UI in general.
* I don't know this for sure, but I would guess the app works on
fully-FOSS versions of Android (e.g. Replicant), since an updated
version is in the fully-free app store
(https://f-droid.org/wiki/page/org.wikipedia). If it doesn't work on
Replicant (or some similar fully-FOSS Android), that does seem like
something important to address.
* No one is going to install proprietary software as a result of this
ad. It only shows to people who are *already* running Android and asks
them to install free and open source software.
It's no different then recommending to a Windows user that they install
Inkscape because it's a great piece of free and open source software.
Finally, this is indeed only configured for Finland.
Matt Flaschen
> Cool?
Cool! It would make the installation of MobileFrontned a lot easier for third parties (ok, I only talk about me :P), if this would be a composer module, but having it in it's own extension sounds reasonable nontheless!
Best,
Florian
Gesendet mit meinem HTC
----- Nachricht beantworten -----
Von: "Sam Smith" <samsmith(a)wikimedia.org>
An: "mobile-l" <mobile-l(a)lists.wikimedia.org>
Betreff: [WikimediaMobile] Breaking apart MobileFrontend's front and back ends
Datum: Di., Sep. 1, 2015 15:52
Hey all,
I've been encouraged to write an update on a 1%* project that I've been
working on: separating the HTML formatter and APIs from the Minerva skin.
Right now, I've created a new extension, which contains the code,
associated configuration variables, and unit/integration tests [0] and am
running it alongside a cut down version of the MobileFrontend extension [1]
locally.
My long-term goal is to further separate out the HTML formatter into a
versioned library and to version the API extension so that we can make
smaller, more easily reasoned about changes to smaller, more easily
reasoned about components and update the (relative) titan that is the
MobileFrontend extension more responsibly.
My short-term goals are:
* to *cover* the new extension in integration tests so that I can make
structural changes
* to get the unit tests passing without hitting the DB
* to document the new extension thoroughly
* to reduce the binding between the two extensions to exactly one call [2]
* to get the extension deployed
Cool? Cool!
–Sam
* Not a typo
[0] https://github.com/phuedx/MobileView
[1] https://github.com/phuedx/mediawiki-extensions-MobileFrontend
[2]
https://github.com/phuedx/mediawiki-extensions-MobileFrontend/blob/dd9e99e0…