Change Login Label name

[wparslan]

I wanted to change the Login Labels of my Login Page and couldn't find anything to hook as it is only labeled with raw values.

It would be a lot better if there was anything else than gettext function to change the value. Maybe a filter.

I added filters for the labels on the Login, Register and Lost Password pages, as they were missing, making it hard to change those labels. This includes labels for text fields, buttons and links.

Trac ticket: https://core.trac.wordpress.org/ticket/55459

[aleksganev]

I added filters for the labels for the text fields, buttons and links on the Login, Register and Lost Password pages.

I went with the single filter for every label approach, since they didn't really group together well to be put in arrays, so a lot of lines changed, but I think it's better this way.

[knutsp]

All text strings are filterable by gettext and friends.

[wparslan]

@aleksganev We have to come up with a better plan than this. A total of 5 to 8 filter additions to the core is bad, if we are using it in the same file, then only one filter will take care of everything here.

@knutsp even if we apply a check to only execute the gettext for the login page, a lot of string/s will be checked here on each login page call. which is bad.

@aleksganev Really appreciate your time into this brother :)

[sabernhardt]

If you use the wp_login_form() function, it already has a single login_form_defaults filter to change each of those labels.

Perhaps this filter could be added inside wp-login.php, too.

[wparslan]

I am talking about the main login form which resides on /wp-login.php page.

Yes, we can use the login_form_defaults filter to change each of those labels, it will only change the parameters of wp_login_form() this function, right?

However, I need a list of parameters for this /wp-login.php page.

[sabernhardt]

As it is now, yes, the filter works on the wp_login_form() parameters but not the standard login.

However, I think the login_form_defaults hook could be reused within /wp-login.php instead of creating something new.

[sabernhardt]

option for supporting login_form_defaults filter in wp-login.php

[sabernhardt]

Using the code in 55459.diff​, I was able to change the labels with this filter:

add_filter( 'login_form_defaults', 'login_form_default_args_array', 10, 1 );
function login_form_default_args_array( $args ) {
	$args = array(
		'label_username' => __( 'Username/Email' ),
		'label_password' => __( 'Strong Password' ),
		'label_remember' => __( 'Remain logged in' ),
		'label_log_in'   => __( 'Sign in' ),
	);
	return $args;
}

[wparslan]

@sabernhardt it will affect the wp_login_form() what if someone needs separate parameters.
Real Pain eh?
I suggest that the filter's name should be changed here, that way we can have flexibility.

What do you think @sabernhardt ?

[sabernhardt]

Yes, it would need a new name. I thought anyone who edits the labels in the filter would want those changes in any login form. Of course, if I'm wrong in any case, automatically replacing the label text on the standard form would not be good.

[wparslan]

Any Updates?
@sabernhardt @knutsp @aleksganev

[sabernhardt]

option to create a login_form_labels filter

[sabernhardt]

With 55459.1.diff​, I could use the same function for both the existing login_form_defaults filter and the proposed login_form_labels:

function my_login_form_labels( $defaults ) {
	$defaults['label_username'] = __( 'Username/Email', 'myplugin' );
	$defaults['label_password'] = __( 'Strong Password', 'myplugin' );
	$defaults['label_remember'] = __( 'Remain logged in', 'myplugin' );
	$defaults['label_log_in']   = __( 'Sign in', 'myplugin' );

	return $defaults;
}
add_filter( 'login_form_labels', 'my_login_form_labels', 10, 1 );
add_filter( 'login_form_defaults', 'my_login_form_labels', 10, 1 );

[rajinsharwar]

Putting this for 6.4, Do we need to update the codex as well @sabernhardt?

[viralsampat]

I made small escaping changes and added my patch.

[sabernhardt]

Except for these filtered labels, let's leave any additional escaping for a separate ticket. It might be good in the title tag. However, #58305 specifically did not escape the linked heading, the $message variable's contents could easily include a strong (or similar) tag, $aria_describedby gives the full attribute, and Core translations have been trusted in many other places.

55459.1.diff would need a version number update in the docblock. I think it might help to mention the login_form_defaults hook in the docblock, too, as it was the model for this and its usage can overlap.

I'm not sure about any edits needed for the Developer Hub (or Help Hub or Codex), but this would need at least a miscellaneous dev note.

[sabernhardt]

55459.2.diff edits the 'Email' label 'to 'Email Address' in the registration form. Should this filter also include the 'Username' and 'Email' strings for registration?

Naming the label keys could be a little complicated because label_username stands for 'Username or Email Address' in both login_form_defaults and this proposed filter.

[oglekler]

I also think that Username and Email for registration for also needs to be added.

And it looks like 55459.2.diff patch is trying to solve another problem at the same time, the case when $_SERVER['REQUEST_URI'] is not defined, but it will not work, because it used in else part as well. And I believe that if there is a problem, it needs to be addressed as a separate issue.

We have 9 days before the Beta 1, and because this is an enhancement, if it will not land into trunk before it, it will be rescheduled into 6.5 milestone.

[oglekler]

All function intended to translate strings have filters:
_e() and __() use translate() and it has 2 filters that can be used to change text as you wish.
esc_attr() also has a filter inside. So, I am wondering if we need something additional at all.

But the current patch has additional things that are unrelated to the issue in question, and we are in two days before the Beta 1, I am moving this ticket into 6.5. It can go in trunk as soon as the patch will be ready and trunk open again after 6.4 will be branched out.

[oglekler]

@rajinsharwar can you please take a look?