swalling wrote:

It's unlikely that we will support the previous messages or new blank equivalents in this release. I'd rather wait and see if Wikipedians really ask or need to additional information, because we have endeavored to cover the three use cases for these custom messages -- user name policy, help documentation links, and security information like an HTTPS connection link -- in the default appearance of both new forms. So far in discussions on wikis which had these, like English Wikipedia and German Wikipedia, users have been understanding about why we removed the previous wordy messages and incorporated new information by default. If the mood changes and there are needs not being met without such messages, we will seriously consider adding new messages for that purpose.

I wish you have right :-)

Setting "low enhancement" as per comment 1, might be reconsidered depending on future feedback.

parsonsa wrote:

I would like to see this feature returned for the following use case.

We disable account creation and use the LdapAuthentication plugin. Along with this, we use mod_auth_kerb to allow users to login with their Kerberos ticket. We used to provide a link above the login form to let users login with their ticket. Now, there is a not a good, clean way to put that link on the login page.

I don't see this as "high priority" and major, but patches would certainly speed up fixing this.

It was just specular to bug 56455.

Should these messages be still there in core.
because, as per https://bugzilla.wikimedia.org/show_bug.cgi?id=47883#c0 ,
those messages doesn't look used in new login form.

(In reply to comment #7)

those messages doesn't look used in new login form.

Yes, that's what this bug is about: they should be included again (though empty by default).

swalling wrote:

(In reply to comment #8)

(In reply to comment #7)

those messages doesn't look used in new login form.

Yes, that's what this bug is about: they should be included again (though
empty
by default).

Yeah we did that for 'signupstart' and 'signupend', so if someone wants to submit a patch for 'loginstart' and 'loginend', they're welcome to.

'login-https' should *not* be added back in, because 'userlogin-signwithsecure' was created to replace it.

(In reply to comment #9)

(In reply to comment #8)
Yeah we did that for 'signupstart' and 'signupend', so if someone wants to
submit a patch for 'loginstart' and 'loginend', they're welcome to.

I added this to the backlog, so if no one takes this, we plan to take care of it at some point. However, this will also require running a script, similarly to before.

'login-https' should *not* be added back in, because 'userlogin-signwithsecure'
was created to replace it.

I think these messages are actually signupend-https and loginend-https. If I'm reading the code right, signupend-https was actually reinstated when signupend was, though it only takes effect if it's on HTTPS, and both signupend and signupend-https are non-blank.

We could potentially keep it (and loginend-https) for third-party users (as with the others), but I'm not sure if it's still useful.

(In reply to comment #9)

Yeah we did that for 'signupstart' and 'signupend', so if someone wants to
submit a patch for 'loginstart' and 'loginend', they're welcome to.

Can you please share the gerrit change id so that it would be easy for us to prepare the patch ?

https://gerrit.wikimedia.org/r/#/c/97185/

gerrit 97185 already merged to master, marking bug for backport

(In reply to Umherirrender from comment #13)

Gerrit change #97185 already merged to master, marking bug for backport

That's signupstart and signupend; the bug is about login*.

Oh, yes, there is an own template. Sorry.

Removing target milestone that was in the past.

If you want this in a specific release, have a good reason AND you are willing to find resources to fix this bug, feel free to change it to something appropriate.