Author: tim.schenk
Description:
The link supplied by the mobile page redirects to :
http://wiki.firstconsulting.nl/Speciaal:Aanmelden <-- dutch
This is the default login page and not the special GoogleLogin page.
In my LocalSetting.php I have:
$wgGLReplaceMWLogin = true;
Is this a GoogleLogin bug, or a MobileFrontend bug?
Version: master
Severity: normal
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Invalid | Florian | T74909 Login link redirect to default login (with MobileFrontend) | |||
| Resolved | Jdlrobson | T74910 Getting rid of own login page (tracking) | |||
| Resolved | Sumit | T85192 Captcha positioning is inconsistent between JavaScript and non-JavaScript users | |||
| Resolved | Jdlrobson | T85189 Login form password reset and account creation form inconsistent between desktop and mobile | |||
| Resolved | Florian | T87261 Watermark and no default message not shown in alpha version of login form | |||
| Resolved | Florian | T87256 Alpha captcha styling different from stable | |||
| Resolved | Florian | T95903 Should be possible for other extensions to register custom messages on MobileFrontend login and signup forms | |||
| Declined | Jdlrobson | T96191 Login form should support custom messages based on returnto and returntoquery parameters | |||
| Resolved | Florian | T101463 Captcha warning caption html shows up as plain text | |||
| Resolved | Jdlrobson | T108855 Standardise on sign up button |
Actually it depends on MobileFrontend in a special way :) Both Extensions, MobileFrontend and GoogleLogin, will rewrite the handler for the Login class. GoogleLogin will do this only, if $wgGLReplaceMWLogin is set to true to prevent the vanilla LoginForm to appear.
MobileFrontend was created in an early version of MediaWiki and had to replace the LoginForm, too, to fit the needs of a mobile device (it will do this every time, the user is in mobile mode).
Now, the problem is, that the login page can be only one class and it wins the extension that has overwritten the key last.
So, in fact, the Extension which was loaded last will provide the login screen. That means for you, as a quick fix, that you can place the "require_once" line of GoogleLogin somewhere _after_ the MobileFrontend "require_once" line. This should solve the problem for now.
The best solution is, that MobileFrontend doesn't need to overwrite the login page anymore. Actually, the developer team is working on this and implemented such a feature in the alpha mode of MobileFrontend (I8f89bdaf3dc7fde104f199554b18486c30580910). It will take some time to solve this problem, but it isn't a real bug of GoogleLogin. I will create a tracking but for this in MobileFrontend :)
(I will set the status of this bug to assigned and take it anyway, but the work has to be done in MobileFrontend :))
P.S.: Thanks for the very detailed bug report! :)
tim.schenk wrote:
Florian, thanks for your help.
Changing the order in which the extensions load solves my problem.
Thanks again for the fast reply!
Thanks for confirm this :)
Added the info to the Extension page: [[Extension:GoogleLogin#MobileFrontend_.3C-.3E_GoogleLogin_conflict_.28only_with_.24wgGLReplaceMWLogin_.3D_true.21.29]]
:/ MediaWiki.org links seems not to work:
https://www.mediawiki.org/wiki/Extension:GoogleLogin#MobileFrontend_.3C-.3E_GoogleLogin_conflict_.28only_with_.24wgGLReplaceMWLogin_.3D_true.21.29
@Jdlrobson: in general: yes :) But i thought, that we can let this task open as a "Blocks" for T74910?