@ozfiddler @anon95694377 I’ve added option 4 with all links in the white box in my original post. I thought leaving one at the bottom might serve as a footer that ideally the privact policy link would occupy.
I like 4. If you wanted to subtly differentiate the privacy link from the others, you could use a grey horizontal line, same as they have done in the login.gov example (but I don’t think it is necessary).
1 Like
I think all of these would be fine. Thank you, @viktor and @ozfiddler, for persevering here! Like you both, my preference is for #4: once all the links are underlined and left-justified, they are clearly a list of links.
4 Likes
Not sure why it never occurred to me but I realized just now CP/WP form pages are missing page titles while using H1 for the logo. For accessibility, I’ve created a petition to add page titles to these forms. I included a mock-up under that petition.
This is looking much better to me also.
I am not one to blindly trust the US gov with everything, but in the case of web accessibility they certainly do their homework. I think basing our design on theirs is an acceptable alternative to what I had previously asked for in terms of investigating the history of this screen before making changes.
Let’s make sure that existing hooks to customize the login page keep working reasonably well (it seems like they probably would, since this isn’t a major change).
2 Likes
I had some time, so I’ve done some work on my local fork:
It’s a lot more complex than I thought, but everything seems to be working and nothing is broken. This includes a custom login logo feature. I’ve also included H1 page title from this thread for accessibility. Although it can be removed. Will be doing more testing, especially with translations.
What do you think about blue messages visible in the lost password and registration forms?
For example, many forms include a brief description below the page/form title. Here’s a Google and Amazon examples, and a mockup of what that might look like in CP:
Thoughts? I’m happy to leave it as is but thought I’ll ask.
1 Like
This is already available in ClassicPress, as far I know.
What do you mean by it? That you added a new feature?
The blue messages are OK IMO, but they need to be filterable (do change them as the developer may like).
Also note that the footer text (go back to X and privacy policy) are part of an action and there might be plugins expecting that to be outside the box. But with the changes I see here, everything is going to be inside the box.
Not sure that is backwards compatible.
All filters and actions are still there. The only unnecessary filter/function I would like to deprecate is login_link_separator, checking about it on GitHub.
I don’t mean it’s gone.
I mean it changed location 
It all looks good to me. I don’t think changing the location is going to break anything because the text is all left-justified.
1 Like
Tested some translations with updated forms. All seem to look and work great. A few examples.
Need to test RTL languages, but I’m not sure CP even has a language pack for an RTL language.
2 Likes
Reset password form in WP has changed. So I’ll need to backport those changes first.
Thanks Joy, but it doesn’t look like it’s compatible with CP or at least CP doesn’t have the right stylesheets:
I don’t know what’s wrong with your setup (running from src), but I’m running that plugin just fine on CP 1.3.0. I have version 1.2 of the plugin.
Edit: Although my test site has DEBUG on, I don’t have it displayed or logged. I’m not seeing these 404s, but they would supposedly be happening. This is how RTL styles work, as you can see in the code.
That’s my local fork repository, set up to work so I can test changes quickly. How exactly does the RTL Tester plugin work? Does it download RTL stylesheets from somewhere?
I checked CP repository, it doesn’t include RTL stylesheets (hence my local fork doesn’t include them):
Am I missing something?
1 Like
The RTL stylesheets are generated during the ClassicPress build process. They are in the official releases but not in the development code. In order to get them running locally you need to install the version of Node.js that ClassicPress is using (see .nvmrc file for this version), run npm install and npm install -g grunt-cli then run grunt build. This will generate a ClassicPress build in the build folder and you can run your test site from there instead of from src.