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.