Make WordPress Core

Opened 2 years ago

Last modified 5 months ago

#55459 new enhancement

Change Login Label name

Reported by: wparslan's profile wparslan Owned by:
Milestone: Future Release Priority: normal
Severity: normal Version:
Component: Login and Registration Keywords: has-patch needs-refresh dev-feedback
Focuses: Cc:

Description

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.

Attachments (4)

55459.diff (3.2 KB) - added by sabernhardt 2 years ago.
option for supporting login_form_defaults filter in wp-login.php
55459.1.diff (3.2 KB) - added by sabernhardt 2 years ago.
option to create a login_form_labels filter
55459.patch (6.7 KB) - added by viralsampat 11 months ago.
I made small escaping changes and added my patch.
55459.2.diff (6.7 KB) - added by viralsampat 11 months ago.

Download all attachments as: .zip

Change History (26)

#1 @sabernhardt
2 years ago

  • Focuses accessibility removed

This ticket was mentioned in PR #2598 on WordPress/wordpress-develop by aleksganev.


2 years ago
#2

  • Keywords has-patch added; needs-patch removed

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

#3 @aleksganev
2 years ago

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.

#4 @knutsp
2 years ago

All text strings are filterable by gettext and friends.

#5 @wparslan
2 years ago

@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 :)

#6 @sabernhardt
2 years ago

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.

#7 @wparslan
2 years ago

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.

#8 @sabernhardt
2 years ago

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
2 years ago

option for supporting login_form_defaults filter in wp-login.php

#9 @sabernhardt
2 years ago

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;
}

#10 @wparslan
2 years ago

@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 ?

#11 @sabernhardt
2 years ago

  • Keywords needs-patch added; has-patch removed

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.

#12 @wparslan
2 years ago

Any Updates?
@sabernhardt @knutsp @aleksganev

@sabernhardt
2 years ago

option to create a login_form_labels filter

#13 @sabernhardt
2 years ago

  • Keywords has-patch added; needs-patch removed

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 );

#14 @rajinsharwar
11 months ago

  • Milestone changed from Awaiting Review to 6.4

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

@viralsampat
11 months ago

I made small escaping changes and added my patch.

#15 @sabernhardt
11 months ago

  • Keywords needs-refresh needs-dev-note added

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.

#16 @sabernhardt
11 months ago

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.

Last edited 11 months ago by sabernhardt (previous) (diff)

#17 @oglekler
10 months ago

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.

Last edited 10 months ago by oglekler (previous) (diff)

This ticket was mentioned in Slack in #core by oglekler. View the logs.


10 months ago

#19 @oglekler
10 months ago

  • Milestone changed from 6.4 to 6.5

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.

#20 @oglekler
7 months ago

@rajinsharwar can you please take a look?

This ticket was mentioned in Slack in #core by rajinsharwar. View the logs.


5 months ago

#22 @swissspidy
5 months ago

  • Keywords dev-feedback added; needs-dev-note removed
  • Milestone changed from 6.5 to Future Release
Note: See TracTickets for help on using tickets.