Page MenuHomePhabricator

[EPIC] MobileFrontend extension should stop special-casing main page
Open, HighPublic

Description

The MobileFrontend extension shouldn't special-case the main page. Currently a lot of the logic and infrastructure is based on a { if isMainPage() } { else ... } model, which is silly and unnecessary. The extension code should be flexible and adaptable to any page. A few tweaks might be necessary for the main page, but there doesn't need to be a completely different system in place for it.

Steps to achieve this

  • Audit all wiki pages which use special cased main pages
  • We should set $wgMFSpecialCaseMainPage = false for any projects currently not using mobile main page special casing
  • Deploy TemplateStyles to render this code obsolete
  • Editors when editing main pages that use special casing should be warned that they are using an outdated and now unsupported paradigm. Preferably a parser warning should be thrown linking to instructions.
  • Community engagement - T138622. All mobile main pages need to be updated to not use the mf- prefix using only the nomobile where necessary. See wikidata.org for a good example.
  • All mobile main pages should stop using tables immediately for layouts
  • Main page special casing turned off for all projects with $wgMFSpecialCaseMainPage
  • Remove special casing code from MobileFrontend

Version: unspecified
Severity: enhancement

Details

Reference
bz30405

Related Objects

StatusAssignedTask
DuplicateNone
OpenNone
OpenNone
OpenNone
ResolvedJdlrobson
DuplicateNone
OpenNone
ResolvedTgr
ResolvedAnomie
Resolvedtstarling
Resolvedcoren
ResolvedAnomie
StalledMhurd
ResolvedAnomie
ResolvedEsanders
ResolvedEsanders
Resolvedssastry
ResolvedAnomie
ResolvedCKoerner_WMF
Resolvedjhsoby
ResolvedTgr
DeclinedTgr
Resolvedcoren
ResolvedAnomie
ResolvedTgr
OpenNone
Resolvedssastry
ResolvedTgr
ResolvedTgr
ResolvedTgr
ResolvedDeskana
ResolvedCKoerner_WMF
ResolvedWhatamidoing-WMF
ResolvedTgr
ResolvedTgr
ResolvedTgr
ResolvedUrbanecm
ResolvedTgr
ResolvedTacsipacsi
ResolvedTgr
ResolvedCKoerner_WMF
StalledNone
DeclinedNone
DeclinedNone
OpenNone

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

Is this ever realistically going to get fixed? I hear that most wiki projects are moving to DIV based layouts and with good use of the nomobile class there is really no excuse for not being able to optimise the main pages without us doing anything.

Is it time to be more brutal and deprecate this main page special casing?

I could imagine the following approach:

  • Add a JavaScript warning on mobile pages that are special cased saying that "This page has been special cased. We are deprecating this functionality. If you are seeing this warning, you need to act now"
  • Identify all special cased main pages and throw a message on the main talk page telling them to act now with a link to how to make a good mobile optimised page.

Now we have useskin=minerva there is no reason why editors cannot easily fix their main page. See https://en.wikipedia.org/?useskin=minerva

If we don't want to take this approach I suggest we WONTFIX this bug as this is not realistically going to happen without a brute force approach.

@Tfinc: Having a separate version of the main page for mobile isn't desirable. Somehow it made sense to me at the time, but I agree. I'd like wikis to stick to having one Main page and solve this problem in a more generic way.

None of these pages (Portals, Main page) have to be a complex cluster of nested tables. We should help the community modernise these structures in general. It doesn't really have anything to do with mobile in particular. These are anti-patterns on the web for so many reasons. Including accessibility. And we have varying resolutions on desktop too. And, of course, people resize their window as they please. Layouts should be flexible. We already did it for category pages, galleries and special pages in MediaWiki core (e.g. using floats instead of tables and media queries).

The main thing I'd like MobileFrontend to achieve is to no longer have these mf- prefix IDs. Which is exactly what I proposed in 2012 (and now agree with @Tfinc, is not a good idea). They take the content bits and put it in a separately maintained layout... (Hardcoded in MobileFrontend.)

The Main page should not visually behave/look exactly the same on mobile as on desktop. But that goes for any wiki page. We don't need mf- prefixes for that. Wikis can provide proper styling for different devices/screen sizes (using flexible styles and/or media queries). Just like MobileFrontend now does for them. Just as wikis do for desktop already. Just like MediaWiki core and extensions do already. That doesn't all have to be controlled and duplicated by MobileFrontend.

@Krinkle note that the mf- id prefixes are no longer needed. If you don't have them your page will render as normal.
See also T75425 - I'd suggest conversation about separate main pages should be had there.

Restricted Application added a project: Readers-Web-Backlog. · View Herald TranscriptApr 8 2015, 7:02 AM

@MaxSem you did some analytics around comparing the reduced page size vs the processing time
Would it make sense to make the main page formatter more generic so it can run on any arbitrary page?

Not in present state where it can add a considerable slowdown on every request that reaches appservers. It would definitely be possible with Parsoid pageviews where a plugin would pregenerate an optimized HTML and cache it in Cassandra.

Jdlrobson moved this task from Backlog to Epics on the MobileFrontend board.Jun 15 2015, 5:19 PM
Jdlrobson set Security to None.
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptSep 18 2015, 8:49 PM
Jdlrobson updated the task description. (Show Details)Dec 17 2015, 6:16 PM
MaxSem removed a subscriber: MaxSem.Dec 30 2015, 3:01 AM
Jdlrobson renamed this task from MobileFrontend extension should stop special-casing main page to [EPIC] MobileFrontend extension should stop special-casing main page.Jun 22 2016, 4:28 PM
Jdlrobson added a project: Readers-Web-Backlog.

I ran an audit and all the projects that are using it are documented in https://gerrit.wikimedia.org/r/295600

Jdlrobson updated the task description. (Show Details)Jun 22 2016, 11:56 PM
kaldari removed a subscriber: kaldari.Jun 23 2016, 9:06 AM

Change 295774 had a related patch set uploaded (by Jdlrobson):
Default wgMFSpecialCaseMainPage to false

https://gerrit.wikimedia.org/r/295774

Is this the reason the en.m.wikipedia main page now looks like this?

Krinkle raised the priority of this task from Normal to Unbreak Now!.Jun 24 2016, 1:45 PM
Restricted Application added subscribers: Luke081515, TerraCodes, Urbanecm. · View Herald TranscriptJun 24 2016, 1:45 PM
Krinkle added a comment.EditedJun 24 2016, 1:48 PM

@Pcoombe Seems to be caused by 463499a57c86c026337d65795ce42b7393fffb0f.

Filed separately as T138578.

Krinkle lowered the priority of this task from Unbreak Now! to High.Jun 24 2016, 4:17 PM

Change 295774 merged by jenkins-bot:
Default wgMFSpecialCaseMainPage to false

https://gerrit.wikimedia.org/r/295774

Jdlrobson moved this task from Backlog to Later on the Readers-Web-Backlog (Tracking) board.
Restricted Application added a subscriber: PokestarFan. · View Herald TranscriptAug 4 2017, 2:15 PM
Krinkle removed a subscriber: Krinkle.Sep 27 2017, 3:33 PM
hashar removed a subscriber: hashar.Jul 7 2018, 2:12 PM
TheDJ updated the task description. (Show Details)Aug 1 2018, 7:43 AM
TheDJ added a subscriber: TheDJ.EditedAug 1 2018, 7:47 AM

@Jdlrobson I've been thinking a bit about this, and I've wondered if you considered adding something similar to a 'lint' report to the edit page of the main pages. This could be used to detect and report problems with the main page as well as maybe the config of the main page feeds (as used by mobile) and have communities slowly take action and move things forward. People not knowing what is wrong and how it should be improved is a big part of being able to move this forward I think.

Should be easy to do with a hook and some algo's ?

Editors when editing main pages that use special casing should be warned that they are using an outdated and now unsupported paradigm. Preferably a parser warning should be thrown linking to instructions.

Well i guess you sort of did.... ;)