Username, email and password fields must be ltr in rtl locale

[man4toman]

Currently, username, email and password fields are rtl in rtl locale.
But for better experience and readability they must be ltr.

[joyously]

How do you run a blame command on a file that will show lines that have been deleted?
If you look at https://core.trac.wordpress.org/browser/tags/5.9/src/wp-admin/css/forms.css#L110 you will see that the CSS is there for the email and url input types to be LTR. The src/wp-admin/css/login.css file used to have @import url(forms.css); but that got removed somewhere (possibly with the change for conditionally loading blocks happened). I don't know SVN well enough to figure out where it got removed.

[sabernhardt]

r45673 removed the CSS imports because the 'forms' and 'l10n' styles are listed as dependencies for 'login' (plus 'install' and 'wp-admin'). However, the login fields are text and password types.

Maybe someone has a better idea, but I would add a new class to the selector list in forms.css (and assign the class wherever necessary):

/* rtl:ignore */
.always-ltr,
input[type="email"],
input[type="url"] {
	direction: ltr;
}

[sabernhardt]

I forgot to mention that moving the password show/hide button outside the input border (#48222) should help with the login form in RTL and password left-to-right, too.

(That is, changing the text direction would make a little more sense without the visibility toggle button on the left side of the input. The other ticket does not need to be completed first.)

[sabernhardt]

The common.css file has had a .ltr class for this, but that is not included on the login screen. I added the class to forms.css and included password-type inputs.

/* rtl:ignore */
.ltr,
input[type="password"],
input[type="email"],
input[type="url"] {
	direction: ltr;
}

The patch adds the ltr class to several inputs.
Login: username, password
Install: username, password
User Edit (Profile): username, password, application password
New User: username, password

I expect I missed at least one more input that needs the class, too.

[sabernhardt]

refresh, adding network pages plus comment author fields

[sabernhardt]

Earlier ticket about this: #26824

Extra changes in 54915.1.diff​:

• Network wp-activate.php: The patch sets direction for the activation key.
• Network wp-signup.php: The patch sets direction for the username and any email-type input.
• Comment Author Email (in edit-form-comment.php and the wp_comment_reply() function in template.php): Changing the input type to email would correct the text direction, but I added the code class to match the styling to the URL input below it (including the direction).

However, the wp_login_form() function in general-template.php would need a different approach to make the text direction work (on the front end).

[sabernhardt]

#52266 was marked as a duplicate. (props ierwira)

[sabernhardt]

The patch needs updating after a few changesets involving these files.

For the wp_login_form(), and possibly similar front-end fields, I'm considering inline styles even though I usually would not recommend that.
$direction_style = is_rtl() ? ' style="direction: ltr;"' : '';
And maybe we should ignore those fields, at least for this ticket.

[sabernhardt]

I'm waiting on #43061 before updating the patch. (If done soon enough, I might ask to put this ticket back to 6.1.)

Sets all password type inputs to LTR direction and adds the .ltr class to forms.css for use in the login page. Several fields need the ltr class or another method of setting the direction.

Site fields in Arabic

Login pages: username and password

Common login at wp-login.php, with the password visibility button on the right (as recommended by ierwira)

Reset Password

Custom login form using wp_login_form() in Twenty Sixteen (this adds the direction style inline, but I do not expect anyone would want to override that)

Comments: email field

Switching the type from text to email would solve the direction, but I used the .code class instead to match the styling of the URL field. (These could have both the email type and the class, too.)

Edit Comment

Quick Edit on Comments screen

Post password

Quick Edit on Posts screen

Post metabox (in Classic Editor)

Media: URL fields

Edit from Media Gallery (list mode)

Edit from Media Gallery (grid mode)

Insert an image into a post (I used Classic Editor)

User Profile: username, password and application password

Navigate to your profile page (/wp-admin/profile.php) or edit another user's profile (/wp-admin/user-edit.php).

​Editing another user is very similar.

New User: username and password

Network (multisite) fields, in Persian

Activation page: activation key

Set language in Network Settings, and navigate to /wp-activate.php.

Registration page: username and email

Set language in main site's Settings, and make sure the network allows both site and user registrations. Then navigate to /wp-signup.php.

User signup (not logged in, step 1)

Network Site Info: Site Address (URL)

Navigate to /wp-admin/network/sites.php (if using a mouse, you could hover over the first link under My Sites dropdown, and then click the second link in the sub-menu). Open individual sites, and the first tab will be Info.

The main site has a code element to fix the direction.

Other sites use the url type for their input fields.

Network Site Users: username and email

Navigate to the second tab for each Site (main: /wp-admin/network/site-users.php?id=1), and scroll down to the Add New User form.

Network Site Settings: several options are URLs, usernames or emails

Navigate to the fourth tab for each Site (main: /wp-admin/network/site-settings.php?id=1).

This patch adds the ltr class to multiple option fields (siteurl, home, admin_email, new_admin_email, mailserver_url, mailserver_login, mailserver_pass, ping_sites, permalink_structure, category_base, tag_base, upload_path, upload_url_path).

Main site:

...

...

...

(The upload path options were empty.)

Second site:

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

The Install and setup-config.php pages already set LTR direction on their fields (by ID selectors).

The Repeat Password fields on the profile screens, which appear without JS active, would not need the special class because they remain password type.

[shibleemehdi]

Test Report

This report validates that the indicated patch addresses the issue.

Patch tested: ​https://github.com/WordPress/wordpress-develop/pull/3933

Environment

• OS: Ventura 13.1
• Web Server: nginx/1.23.3
• PHP: 7.4.33 (Supports 64bit values)
• WordPress: 6.2-beta1-55292-src
• Browser: Chrome 109.0.5414.119 (Official Build) (arm64)
• Theme: Twenty Twenty-Three
• Active Plugins:

Actual Results

• ✅ Partially Issue resolved with the patch.

Additional Notes

• Without the patch /wp-admin/user-new.php looked like: ​https://d.pr/i/f8SIM6
• With the patch it is fixed /wp-admin/user-new.php looks like: ​https://d.pr/i/IVG1Ii
• But with the patch, the login page not fixed yet: ​https://d.pr/i/P86pVd

[sabernhardt]

If the login page did not change but all the other pages were improved, the forms-rtl and login-rtl stylesheets may not have compiled correctly. I tend to have success with the npm run dev command when testing RTL stylesheets.

Anyway, I think I took too long to get this done for 6.2.

[agnieszkaszuba]

Test Report

This report validates that the indicated patch addresses the issue.

Patch tested: ​https://github.com/WordPress/wordpress-develop/pull/3933

Environment

• OS: macOS 13.0.1
• Web Server: Nginx
• PHP: 7.4.24
• WordPress: 6.3-alpha-55505-src
• Browser: Chrome 109.0.5414.119 (Official Build) (x86_64)
• Theme: Twenty Twenty-Three
• Active Plugins: -

Actual Results

• ❌ Issue not resolved with patch.

Additional Notes

• I tested the following scenarios and didn't get the expected result in any of them (password and username were in RTL instead of LTR). I tested all of these scenarios with site language Arabic, and scenarios 3 and 4 also in Hebrew.

1. Login page
2. Admin page
3. New user page
4. Post password

Supplemental Artifacts

[oglekler]

I am adding changes-requested to indicate that this patch needs further work and removing needs-testing until the patch will be ready.

Hi @sabernhardt
Just for follow up this ticket(that I have been sent into WordPress trac before), when we can have these patch in core?
Thanks

[audrasjb]

As per today's 7.0 bug scrub:
We have a PR waiting for review. @sabernhardt do you think it's ready for testing?
Because this changeset would probably require a lot of tests, better to assign the correct needs-testing keyword asap.

[audrasjb]

Feedback from @sabernhardt: it's ready for testing

[sajjad67]

Test Report

Description

This report validates whether the indicated patch works as expected.

Patch tested: ​https://github.com/WordPress/wordpress-develop/pull/3933

Environment

• WordPress: 7.0-alpha-61215-src
• PHP: 8.2.29
• Server: nginx/1.29.5
• Database: mysqli (Server: 8.4.8 / Client: mysqlnd 8.2.29)
• Browser: Chrome 144.0.0.0
• OS: Windows 10/11
• Theme: Twenty Twenty-Five 1.4
• MU Plugins: None activated
• Plugins:
  • Test Reports 1.2.1

Actual Results

1. ❌ Issue not resolved with patch.

Additional Notes

• During the testing session, it was observed that when an RTL language (e.g., Arabic) is active, most fields correctly adhere to LTR/RTL rules. However, the Username, Email, Password, and URL fields remained consistently LTR.

Supplemental Artifacts

• Login Page: ​https://img.lightshot.app/ymwbiEDXR-Ov0HM8ShpJmw.png
• Add New User Page: ​https://img.lightshot.app/vsrRNWh7T7SPkPiEK0Sz9Q.png
• Profile Page: ​https://img.lightshot.app/WeYnw3sxQSOXnkM09qygHA.png
• Quick Edit Post: ​https://img.lightshot.app/7ONWvGloTFWSo6atd-sinA.png
• Post Edit Page: ​https://img.lightshot.app/66ZxNDaMRXmtlrwkUfuFbQ.png
• Settings General Page: ​https://img.lightshot.app/KKA9EIZaTNakiUDvvioCfw.png

[huzaifaalmesbah]

@sajjad67 I reviewed your screenshots and they show the expected result. However, you marked the report as ❌ Issue not resolved with patch.

Could you please check the behavior before and after applying the patch and confirm whether the fix is actually working or not?

[sajjad67]

@huzaifaalmesbah As you can see in the screenshots, even after applying the patch, username, email & password were in RTL instead of LTR. So expected behavior is they should be LTR not RTL.

[huzaifaalmesbah]

Screenshots/Screencast with results

Screencast before: ​https://files.catbox.moe/vk60zw.mp4

Screencast after: ​https://files.catbox.moe/zn3kqz.mp4

The patch is now working correctly and the primary issue (Username, Email, Password, and URL fields) appears to be resolved as expected.

However, the remaining fields shown below are not related to Username, Email, Password, or URL.

Given that, would it be better to handle these in a separate ticket to keep this PR focused and scoped properly? Or should we extend this PR to address those fields as well? @sabernhardt

### Edit User Page

### Add User Page

### Settings General Page

@huzaifaalmesbah Thanks for testing!

This PR is intentionally for Username, Email, Password, and URL fields. I expect that input fields such as profile names and site titles are commonly right-to-left. There might be a reason to consider auto direction for some fields, such as time zone, but that is outside the scope of this ticket. The PR already involves the custom login form and several parts of multisite administration.

Okay Thanks for clarification. Then this pr Looks good for me.