Last modified: 2014-02-12 23:45:14 UTC
Articles like http://en.m.wikipedia.org/wiki?search=final+fantasy+character+jobs surface tons of fix me templates which were not showing on the ruby gateway. This looks like a bad regression.
(In reply to comment #0) > Articles like > http://en.m.wikipedia.org/wiki?search=final+fantasy+character+jobs surface tons > of fix me templates which were not showing on the ruby gateway. > > This looks like a bad regression. Do you mean <http://en.wikipedia.org/wiki/Final_Fantasy_character_jobs?useformat=mobile>? Otherwise, this bug is completely incomprehensible.
This is now fixed in r94779.
Re-opening this. My comment from CodeReview: This isn't a scalable solution and this just adds further English Wikipedia-specific code to what's supposed to be a generic extension. I recommend reverting this. I'm also not sure that hiding the banners on the mobile site, in general, is a good idea. They could equally be hidden from logged-out users on the main (non-mobile) site, but specifically are not. There seems to be some rendering issues with them, but that's a problem with the extension, I imagine.
<http://en.wikipedia.org/w/index.php?title=Final_Fantasy_character_jobs&printable=yes> The amboxes don't show up in the printable version. Why don't we just make the extension follow [[MediaWiki:Print.css]]?
I think we should stick the solution in r94784.
(In reply to comment #4) > <http://en.wikipedia.org/w/index.php?title=Final_Fantasy_character_jobs&printable=yes> > > The amboxes don't show up in the printable version. Why don't we just make the > extension follow [[MediaWiki:Print.css]]? There's already a [[MediaWiki:Handheld.css]], but as bug 22659 notes, it's not really intended for this. I think adding a Mobile.css page here is probably the sanest and most scalable solution. (In reply to comment #5) > I think we should stick the solution in r94784. Requiring sysadmin intervention is generally a bad idea for timeliness and resource allocation (both on Wikimedia wikis and other MediaWiki installations). I think r94784 is better than r94779, but I think both could be improved by a dedicated Mobile.css page that can be customized by local administrators and that applies specifically to mobile devices.
I support MZMcBride. It is what I have proposed several times as well. Mobile.css is the way to go.
(In reply to comment #1) > (In reply to comment #0) > > Articles like > > http://en.m.wikipedia.org/wiki?search=final+fantasy+character+jobs surface tons > > of fix me templates which were not showing on the ruby gateway. > > > > This looks like a bad regression. > > Do you mean > <http://en.wikipedia.org/wiki/Final_Fantasy_character_jobs?useformat=mobile>? > Otherwise, this bug is completely incomprehensible. Yes. I was using the opt in beta (blog posting imminent) which is why the url didn't look any different.
Er, shouldn't these explicitly *BE* shown? They're an important part of how Wikipedia authors communicate the state of the article & its information to readers.
I'm afraid site CSS won't help WML devices.
Is there still interest in this issue? I could add an on-wiki blacklist for unwanted elements.
(In reply to comment #11) > Is there still interest in this issue? I could add an on-wiki blacklist for > unwanted elements. There are a bunch of issues mixed in here. Any "ambox" code shouldn't be present in the MediaWiki extension (from r94779). $wgMFRemovableClasses (from r94784) shouldn't be present in the MediaWiki extension. Once these issues are resolved (if they haven't been already), I think this bug can be closed. This assumes more bad code hasn't been added in the meantime, I guess. The outstanding issue is regarding a "MediaWiki:Mobile.css" page, but that's a matter for a separate bug (bug 22659).
MW:Mobile.css now exists. Can we clear $wgMFRemovableClasses in site config now and allow communities decide themselves?
I guess so. I suppose as an intermediate step we might add a css rule to common.css that hides these by default (obviously then MediaWiki:Mobile.css can then override them.
I'm completely lost with whether this issue is resolved now (as MZ says there are a bunch of issues mixed in here) so I'm closing. I'd suggest we open some newer bugs for anything remains unresolved - I prefer clearer bugs that focus on separate issues as these are more likely to be resolved (quicker than a year :P).
(In reply to comment #15) > I'm completely lost with whether this issue is resolved now (as MZ says there > are a bunch of issues mixed in here) so I'm closing. > > I'd suggest we open some newer bugs for anything remains unresolved - I prefer > clearer bugs that focus on separate issues as these are more likely to be > resolved (quicker than a year :P). Yes. Not very difficult to split this out. I've done so for you. (In reply to comment #12) > Any "ambox" code shouldn't be present in the MediaWiki extension (from r94779). It seems like ambox has been removed, but other non-MediaWiki specific classes seem to linger: <https://gerrit.wikimedia.org/r/gitweb?p=mediawiki/extensions/MobileFrontend.git;a=blob;f=MobileFormatter.php;h=e54b7c312985e3ebd569cac1fb4f34c597f4e8b8;hb=HEAD>. Is this where itemsToRemove has ended up? And if so, are these lingering classes and IDs worthy of a separate bug? > $wgMFRemovableClasses (from r94784) shouldn't be present in the MediaWiki > extension. Bug 40343: Kill $wgMFRemovableClasses in MobileFrontend extension
Thanks MZ .. much appreciated! :-) Yes itemsToRemove became defaultItemsToRemove in commit 4bc466c145aad82231fc2f7f44f937feefedaa1a I personally think the things that remain here are better surfaced by bugs for the reason they are here rather than create a bug for why they are here. For instance I suspect #ogg_player_2 and #ogg_player_1 are scrubbed due to bug 38305 (lack of video support).
Sorry there is a typo in the above: *I personally think the things that remain here are better surfaced by bugs for the reason they are here rather than create a bug for why they are here. should be: I personally think the things that remain here are better surfaced by bugs for the reason they are here rather than create a bug for __them being here__
(In reply to comment #17) > Yes itemsToRemove became defaultItemsToRemove in commit > 4bc466c145aad82231fc2f7f44f937feefedaa1a > > I personally think the things that remain here are better surfaced by bugs for > the reason they are here rather than create a bug for __them being here__. > > For instance I suspect #ogg_player_2 and #ogg_player_1 are scrubbed due to bug > 38305 (lack of video support). Yes, it'd be nice if the array were annotated with specific bug numbers.
