https://bugzilla.wikimedia.org/show_bug.cgi?id=41341
--- Comment #5 from Krinkle <krinklem...@gmail.com> 2012-10-25 20:49:32 UTC --- (In reply to comment #3) > No.. the problem I am raising here is that if a version of MediaWiki is run > which has a ResourceLoader that does not support the target property - the > mobile site will receive all javascript from the desktop site including > gadgets. > No no, yes! We are saying exactly the same thing. Both wmf branches were updated with the latest version of MobileFrontend, but only the latest wmf branch is branched from MediaWiki after 'target' was implemented. As a result load.php?modules=startup&target=mobile on older wikis loads all modules (the 'target' parameter is ignored as it doesn't exist yet in the old mediawiki version). I didn't mean to suggest that bug 41340 should be fixed to solve this problem (I would've marked it as a dependency in that case). I'm merely trying to clarify that the fact that those gadgets throw exceptions for Geo, wgPageName and mw.config etc. is not related to the fact that it is an older version of ResourceLoader but due to bug 41340. Having said that, lets rewind: (In reply to comment #0) > Go to > http://pt.m.wikipedia.org/wiki/Wikipédia:Accueil%20principal?title=Wikipédia:Accueil_principal&mobileaction=toggle_view_mobile > > It throws an exception due to a gadget. > It throws an exception due to bug 41340. And (obviously) this bug is not gadgets related, various core and extension modules are equally failing due to the incompatible environment. > Brion suggested this might be due to the fact that the mediawiki core on this > box has not been updated. > > Possibly we should be feature detecting whether ResourceLoader has support for > target before adding javascript as it's possible we could break backwards > compatibility on various wiki sites. (In reply to comment #3) > [..] > > I am proposing we do the following: > > if ( ResourceLoader supports target property ) { > useResourceLoader(); > } else { > useMockMw(); > } I'd recommend instead to simply not deploy the latest MobileFrontend master on older wikis. It is a reasonable requirement that the latest 'master' head of an extension requires the latest 'master' head of mediawiki/core. When there are breaking changes in master, extensions are updated and deployed at the same time. When a wmf-branch is created this link is fixed, and during the 2-week period various core updates and extension updates are backported. We shouldn't fast-forward extensions in the older wmf-branches unless there are critical updates. And in that case we make a wmf-branch in the extension repo, cherry-pick the fix to there, and update the mediawiki/core wmf-branch to that revision. Basically the same as in the svn days. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
