Why do you need separate special pages?

Why not? It makes sense, when you're making an account it's not technically logging in. I don't see why it shouldn't be a separate page considering it's using a separate form. Trivial change, perhaps. Practical change? Definitely.

Historically, they were on the same page. Now that the logic abstracted them to separate "pages" (one specialpage, two different forms), it should be fairly trivial to move them entirely apart. I'd still keep Special:Userlogin?type=createaccount as a redirect for Special:CreateAccount, for b/c, but other than that I can't see a reason to keep them together anymore.

Special:UserLogout is separate :)

• Bug 29785 has been marked as a duplicate of this bug. ***

FWIW, Extension:SignupApi makes a change to add Special:UserSignup and that part seemed to work, although I didn't try it with all variations like $wgUseCombinedLoginLink. This might be an easy change, but verifying it everywhere is the challenge.

special:createaccount has existed for ages. Yes, it's only an alias; but now it also has separate incoming links in the UI.

Re-opening for now. I believe the request here is for "Special:UserLogin/signup" to become (redirect to) "Special:CreateAccount". Currently the redirect goes the other way. That's how I read comment 0 and comment 3, at least.

It would be confusing. It will be a different special page when the logic is actually separate.

Just because you think it's confusing doesn't make it not worthwhile.

(In reply to comment #9)

Just because you think it's confusing doesn't make it not worthwhile.

Sigh.

URLs are important. It's needlessly confusing that creating an account puts users on a page Special:UserLogin&type=signup , regardless of the code internals.

A comment from the redirecting function SpecialCreateAccount() in SpecialPage.php :

• @todo FIXME: This (and the rest of the login frontend) needs to die a horrible painful death

(In reply to comment #11)

A comment from the redirecting function SpecialCreateAccount() in
SpecialPage.php :

• @todo FIXME: This (and the rest of the login frontend) needs to die a

horrible painful death

Yes. But that's bug 17312.

(Copying comment from bug 17312 comment 0)
At the moment, UserLogin is concentrating too much responsability:

1. Displays and manage a form intended for gathering login information;
2. Displays and manage a form intended for gathering information for a new

account (create new account link)

3. Manages part of authentication process;
4. Coordinates creation of a new account.

From the 'object orientation' point of view, clearly UserLogin should be split
on smaller components.
UserLogin, IMHO, should be *only* reponsible for

1. Displays and manage a form intended for gathering login information;

Other tasks should be managed by their corresponding responsible classes.
In fact, it does not matter whether Mediawiki is object oriented or not. Object
orientation is a very useful (and helpful!) concept which can be implemented
even in bash scripts. Object orientation (or at least the concept) allows
better organization of code, it's easy to maintain, easier to extend and easier
to adjust to specific needs.

I've integrated LDAP authentication in our wiki and it was a nightmare :(
Now I'd like to replace LDAP by SAML and it's another nightmare, not working
yet :(

Separating concerns on different classes would allow easier integration with
several authentication layers.

• One thing is getting username/password/domain from a form.
• Another thing is using username/passoword for authenticating against a

certain authentication layer.

• Another thing is obtaining data required for registration and coordinating

the registration workflow.

• Another thing is performing the steps required to create a new account in a

certain respository.

A good example which shows how integration is tangled can be seem at:
https://ow.feide.no/simplesamlphp:mediawiki
and the corresponding 'plugin' provided by:
https://ow.feide.no/_media/simplesamlphp:simplesamlphp-mw.php.zip?id=simplesamlphp:mediawiki&cache=cache

Thanks very much

Richard Gomes
http://www.jquantlib.org/index.php/User:RichardGomes

• Bug 17312 has been marked as a duplicate of this bug. ***

(In reply to comment #12)

Yes. But that's bug 17312.

FTFY.

(In reply to comment #15)

(In reply to comment #12)

Yes. But that's bug 17312.

FTFY.

The summary you chose for this bug is surely incorrect if you mean it to be a duplicate of bug 17312; I'm not a coder, though, so I leave this to those who understand the logic here.