WordPress.org SSO: custom template handling and CSS for login-related screens

[stephdau]

Bringing custom template handling to some of the main screens involved in login related actions, to have full control over the design of our authentication experience. Other wp-login.php screens (password reset process, etc) are handled by the same custom stylesheet.

Design and CSS by @mapk.

This work involves changes to both the wporg-login theme, as well as some tweaks to our SSO library.

Code is upcoming, tweaking some CSS. Sample screenshots attached.

Relates to #1406.

[stephdau]

Login screen

[stephdau]

Lost password form

[stephdau]

In 2308:

WordPress.org SSO: Adding new assets for custom template handling.

See #1524

[ocean90]

I know it's WIP, but login.scss looks hard to maintain at its current state:

• Compass should be avoided, there is no real benefit of it.
• Some CSS properties have missing vendor prefixes, some have to many. ​Autoprefixer can take care of it.
• The ​CSS Coding Standards should be followed like "each selector should be on its own line" or "property-value pairs should be on their own line".

I've noticed the ?screen=lostpassword line in the second screenshot, IMO it should be just /lostpassword or /recovery.

[stephdau]

In 2312:

WordPress.org SSO: mapk won't be using SASS after all.

See #1524

[stephdau]

In 2313:

WordPress.org SSO: new custom template handling for login experience.

See #1524: wporg-login theme partof the work.

[stephdau]

In 2314:

WordPress.org SSO: new custom template handling for login experience.

See #1524: wporg-sso part of the work.

[stephdau]

In 2315:

WordPress.org SSO: deleteing obsolete stylesheet.

See #1524

[mapk]

I've just worked more of the CSS to account for the wp-login pages and error handling. I'm attaching the diff file as well. [login-css.diff]

[mapk]

The patch file for the additional CSS changes.

[netweb]

In 1524.1.diff​ is a refresh of login-css.diff​ that includes those changes and the following:

• Updates normalize.css to v3.0.3 ​https://github.com/necolas/normalize.css/releases/tag/3.0.3
• CSS parsed with Autoprefixer using browser versions per ​Gruntfile.js#L27
• CSS now matches ​WordPress CSS Coding Standards

[ocean90]

In 2320:

Login Theme: Don't use filemtime() for nonexistent files.

See #1524.

[stephdau]

Replying to ocean90:

I know it's WIP, but login.scss looks hard to maintain at its current state:

• Compass should be avoided, there is no real benefit of it.

We were having the same conversation on our end, and we're dropping SASS in favor of pure CSS.

• Some CSS properties have missing vendor prefixes, some have to many. ​Autoprefixer can take care of it.

Nice,thanks.

• The ​CSS Coding Standards should be followed like "each selector should be on its own line" or "property-value pairs should be on their own line".

cc @mapk

I've noticed the ?screen=lostpassword line in the second screenshot, IMO it should be just /lostpassword or /recovery.

I was also thinking the same, and is on my plate for today, provided I already have handling for /oauth/*.

Thanks for the feedback.

[stephdau]

In 2322:

WordPress.org SSO:

• updating WP plugin with a path router/validator for login.wordpress.org
• adding a is_valid_wporg_sso_path filter

See #1524

[stephdau]

In 2323:

WordPress.org SSO: updating theme with a patyh router/validator.

See #1524, and r2322

[stephdau]

In 2324:

WordPress.org SSO: using fmtime() to define CSS version passed in URL, so designers like mapk can see their changes without having to modify hardcoded values every time.

See #1524

[netweb]

Adding reference to r2321 that didn't link to the ticket here

Wordpress.org SSO: committing 1524.1.diff, from #1524
Rollback to pure CSS (over Compass), plus updates, plus cleanup.
Props mapk, netweb

[stephdau]

Replying to netweb:

Adding reference to r2321 that didn't link to the ticket here

Wordpress.org SSO: committing 1524.1.diff, from #1524
Rollback to pure CSS (over Compass), plus updates, plus cleanup.
Props mapk, netweb

Weird that it didn't pick up the one at the end of the 1st line.

[netweb]

Replying to stephdau:

Weird that it didn't pick up the one at the end of the 1st line.

Yeah, no idea really, occasionly Trac misses commits so will put it down to that ¯\_(ツ)_/¯

[stephdau]

In 2336:

WordPress.org SSO: Improvement: Try to send people back to a better destination that just ​https://login.wordpress.org/loggedout/ (kept as fallback) when logging out, such as the page they instigated the logout from.

If said page is public, they will be sent bacck,loged out. If said page is private, they will once again be promted to login, as if they had accessed it directly.

See #1524

[stephdau]

In 2338:

WordPress.org SSO: adding an ! empty() test to avoid an undefined index warning.

props ocean90

See #1524

[michaelarestad]

This caught me off guard today. For a second, I thought I was on the wrong site or that it was broken. I don't think it particularly feels like it fits with WordPress.org's design aesthetic or even the design aesthetic of WordPress itself. Is this something you're planning on iterating on?

[mapk]

@michaelarestad - This is the product of several iterations. Maybe there should be an announcement of something like this to the community when it goes live so that people aren't thrown off? I'm not sure. The feedback I've seen thus far has been very positive.

Based on extensive research by Hugo, the current WordPress.org tends to feel "dated" to our users. We're exploring new ways to enhance the design while increasing the user's performance/experience on our site - this is a step in that direction.

This design uses the brand colors, fonts, and doesn't veer much away from WordPress.org as a whole, but rather distinguishes itself from WordPress.com all the more. Yes the page is darker. This would only apply to the login/OAuth screens and not the rest of the site as a clear indicator that the user isn't logging into .COM.

[melchoyce]

Hey Mark,

I think this is a good exploration, but for now it's a little too much of a departure from our current design language on WordPress.org. I think the decision to go dark is bold, but a little too drastic to suddenly introduce on one screen. If we want to go in a dark direction overall, it would be good to build that up over the course of a couple iterations on multiple screens to keep it more cohesive. However, I don't think that dark is a great direction for us to be going with — we've received a lot of feedback in the past that the dark admin color scheme feels unwelcoming and unfriendly. I think that moving WordPress.org in that direction, when the goal of the site is to bring people into the WordPress community, could be a step backwards. Dark can look really nice and modern, but I think for a community like WordPress, it needs to be balanced with a lot of light.

If this is useful to think about, when we were first reskinning the admin, the idea behind the MP6 design language was that all content was on a white sheet of paper that was laid on top of the dark background that makes up the admin bar and navigation column. So to extend that metaphor to a .org login screen, the background could be dark, but the actual login form should be on a white “sheet."

I had a chance last night to review some of your earlier mockups, and I think some of them were heading in a better direction. I used them as a jumping point to come up with a couple more ideas, which I'll attach to this ticket.

[mapk]

@melchoyce - Really cool! I like the explorations and totally understand the concerns with the dark background. Thanks for explaining that. I really like the additional text about it as well. I was meaning to get something like that in there.

I'm posting something on make.wordpress.org/design right now. I think moving this feedback there would be beneficial.

I am open to changing the background. :) No worries there. I will say it's interesting that the public feedback has been all positive (from what I've seen). So I'm not sold yet that it's 'unfriendly' to our users. But I definitely value your feedback along with Michael's and Hugo's as well. You guys are more established in the community and thus hold a respected insight that I'd like to learn from.

[melchoyce]

Replying to mapk:

I'm posting something on make.wordpress.org/design right now. I think moving this feedback there would be beneficial.

Sounds good, I'll keep an eye out there.

[hugobaeta]

Replying to melchoyce:

the idea behind the MP6 design language was that all content was on a white sheet of paper that was laid on top of the dark background

I think Mel summed things up quite well. I do think the current implementation is actually closer in structure to .com than before, like I've told Mark. It took me a while to understand what was even the purpose of this redesign, and from what I understood, what prompted it was the upcoming OAuth stuff.

So I decided to take in all the information we discussed and make a mockup that sits in between all of this, and would feel maybe like less of a drastic departure from before. Check it out and let me know what you think:

Log in:

Log in with the intro text Mel suggested:

Space for OAuth stuff next to log in:

Thoughts?

[hugobaeta]

Another important piece of feedback, that I've passed on to Mark privately, but is important to share here as well: There's a few accessibility concerns in the current live implementations, like text having too low contrast and inputs in the form not having any active outline/state. Those are easy fixes :)

[netweb]

Adding reference to r2350:

Revised the CSS for more contrast in text and accessibility practices.

@mapk, adding a ticket to reference to commits please :)

See also ​https://make.wordpress.org/core/handbook/best-practices/commit-messages/#ticket-references

[rmccue]

As a quick note on the OAuth design stuff, I'd love if the design there was easily adaptable to core as well; we desperately need a design touch on the ​OAuth plugin for the REST API, so if we can steal it from .org, all the better. :)

(P.S. Love the work you're doing here folks!)

[mapk]

@netweb - Thanks, I'll make sure to do that going forward.

[mapk]

It's great to see some other directions we can take this page! From the mockups on this ticket, it looks like a dark background is workable, but removing the white box can make it seem too dark. Does that sound about right?

Here are some other changes I see in the mockups:

• Intro text: I really like the idea of adding intro text to better explain where the user is going after logging in.
• Adding ".org" to the logo: This has been requested a lot and could be a great addition to differentiate from typical WordPress installs.
• Adding "wordpress.org" to the login button: I hadn't thought about adding wordpress.org to the login button. With the other changes, would this be too much?
• White box around content: Personally, I find adding a white box around all the content to be too constraining. I lean toward open spaces and allowing the elements themselves to define the boundaries. Maybe we can try placing the form in the box, but leaving the other elements outside of it?
  • One reason I decided to remove the white box was to allow more flexibility when incorporating the OAuth stuff. @hugobaeta's mockup shows a side-by-side view, which I explored as well, but I was concerned about how this would look on mobile devices. Do you have ideas here?
• Moving "login" inline with "forgot password": I personally liked the fully-extended button better with my current design (no white box) because it helped define space. If we go back to using a box around the form, then having the button inline with the 'forgot password' checkbox should work just fine.

I really appreciate everyone taking some time to work through their thoughts. It's immensely helpful.

[hugobaeta]

Replying to mapk:

it looks like a dark background is workable, but removing the white box can make it seem too dark. Does that sound about right?

@melchoyce put it best: There's a design language in place that would make sense to follow. If we don't, then there needs to be a strong reason for it.

• Adding ".org" to the logo: This has been requested a lot and could be a great addition to differentiate from typical WordPress installs.

I'm still on the fence about it.I think this new page has enough of a distinguishing look from self-hosted installations logins or WordPress.com, that there less reason for confusion. Adding the intro text and the "Login to WordPress.org" would make it even clearer, what do you think?

• Adding "wordpress.org" to the login button: I hadn't thought about adding wordpress.org to the login button. With the other changes, would this be too much?

Yes, great idea that I didn't notice from @melchoyce mockups before. I'll revise mine to include it

• One reason I decided to remove the white box was to allow more flexibility when incorporating the OAuth stuff. @hugobaeta's mockup shows a side-by-side view, which I explored as well, but I was concerned about how this would look on mobile devices. Do you have ideas here?

What did your research tell you? If you have any, would you mind sharing screenshots of what some other apps do? I've seen some flows where it just stacks and I have no problem with it, honestly - OAuth info first, login after.

• Moving "login" inline with "forgot password": I personally liked the fully-extended button better with my current design (no white box) because it helped define space. If we go back to using a box around the form, then having the button inline with the 'forgot password' checkbox should work just fine.

The full width button and lack of structure (white sheet) is what, in my opinion, makes it look more like .com than before. With the addition of "Login to WordPress.com" in the button, then it will likely have to be full width, yes.

Updated mockups to follow ;)

[hugobaeta]

Here we go, revised mockups. Check this out:

And on mobile:

Essencials:

• Made Button larger to include "Log in to WordPress.org";
• Moved the "Lost Password?" link up, makes more semantic sense there than at the bottom, and also makes elements more balanced.
• After going back and forth with @melchoyce, decided to keep the dark around the login sheet on mobile (tried letting the white sheet go all the way to the edges as well, but then the footer would look weird).

I haven't included anything related to OAuth. I think we'd benefit more from some sketches/wireframes around that first. I don't know enough about the scope of that project yet to make educated decisions. From what I gathered so far, it won't be a lot of information. Other apps/services usually include some bullet list with what the site will have access to, etc.

Thoughts?

[hugobaeta]

Oh, and just for experimentation's sake, here's a version with the ​full WordPress.org logotype:

[melchoyce]

Hey @hugobaeta, I think your latest mockups are really moving in a good direction for the next iteration of this screen. Having a background underneath the entire form feels really focused. I think that if only part of the form was constrained in a box, the rest of the information would fade back a little too much into the background, since the attention would all be focused on the fields. If we're trying to emphasize that you're logging into WordPress.org, having the logo and the supplementary text fade back seems like it wouldn't improve clarify.

Speaking of clarify, for all that it's a bit busier, I like the WordPress.org logo; I think it's okay to over explain where you're logging in to, since people logging in to the wrong place by accident was one of the prompts for redesigning this page. A little overkill can go a long way.

Looking at oAuth screens, there seem to be two trends: ​https://cloudup.com/cWir3T67OSw

1. If you're logged out, log in on one screen, and then approve on a second (eventbrite, facebook, g+, path, tumblr)
2. If you're logged out, log in and authorize on the same page (linkedin, twitter)

All of them (except for Linkedin, which makes you log in again, even when it shows you being logged in) allow you to authorize on one screen if you're logged in already.

The log in --> approve method is nice because it doesn't force you to throw all of your information, plus login form, on the same screen. It's not a bad flow. If you're already logged in to WordPress.org, you'd just see the second screen.

In general, the screens seem to have the following information:

• The service you're authorizing, strongly branded
• "This app wants to access [the following features]. Is that okay?"
• Authorize or Deny buttons
• Who you are logged in as

They're also all popup windows, so we have the advantage of being able to control the size of the window we're presenting on desktop.

Do we know what a WordPress.org single sign-on would be able to access? My guess would be a list of themes and plugins you've created, your basic profile information, your contribution history, and maybe your support forum history? @stephdau, do you know?

@mapk, I know you've done some work into the oAuth screen already, but I think it would be a good next step to take a step back and sketch out some flows based on Hugo's new layout. I think you should keep really low-fi at first — either pen & pencil or something like balsamiq to start. That'll help you nail down the flow and information that needs to be included without having to worry about the overall styles yet.

If you don't want to share low-fi deliverables with the community at large, you're welcome to ping me (and any other core designer) for feedback whenever you'd like. As a group, we do a lot of peer revision and impromptu feedback sessions, both in #design and in DMs or group chats. I try to get feedback on projects from fellow designers early and often (especially after I've been staring at it for a while and start to lose track of the bigger picture).

I know this has been sort of a stressful first community project for you, especially with all of us jumping in (sorry!), but I think you've been handling it really well and this is really on-track.

[stephdau]

Replying to melchoyce:

Do we know what a WordPress.org single sign-on would be able to access? My guess would be a list of themes and plugins you've created, your basic profile information, your contribution history, and maybe your support forum history? @stephdau, do you know?

The single sign-on is for WordPress.org, as in, you login to all the wp.org properties (sites) through the same login screen, not the one for bbPress, or single instance of WP, or GlotPress', etc. Those are sites that live under the wordpress.org domain and can share auth cookies as is.

The oAuth flow on this same login.wordpress.org, on the other hand, will be used (at first) for our other properties/sites that donot run on the wordpress.org domain, and can therefore not share auth cookies, such as buddypress.org, wordcamp.org,bbpress.org, etc. Instead of authenticating (logging in, sharing cookies), they'll authorize the site (as an app, with login only seen if if not yet logged in to wp.org).

There are dreams of more than that for the future, but we'll cross that bridge once we cross the first one. :)

[stephdau]

EG: if you currently go to ​https://make.wordpress.org, and hit the login there, you will be redirected to login.wordpress.org, then back to make.wordpress.org. Same for Trac, etc.

[mapk]

Thanks for the comps, @hugobaeta, and for the words of advice, @melchoyce! They are helpful.

@melchoyce - I did sketches early on during the project to work out OAuth flows. That's where I ran into the 'white box' restrictions that didn't seem to be so pleasing when two white boxes have to stack on smaller screens. I'll share them with you on Slack because I don't know how to attach a PDF here. :)

I'll also shoot you a link to where I shared a couple different flows that I was working on as well. I totally agree about sharing stuff early on, but being the first project, I wasn't exactly sure where. I like the idea of getting a post up on /design, and PMing or posting in Slack somewhere too.

One thing to note is that we should probably hold off making new login comps without taking the time to explore the OAuth side of things.

I appreciate the words of encouragement. If my first project wasn't stressful, something aint right. :)

[mapk]

To help with this discussion, I'm including the flows that will be necessary to design for and some wireframes to help inspire ways in which these can be accomplished.

These are the different flow cases:

Flow 1: User is logged into WP already and has already approved secondary site/app to use WP login.
Flow 2: User is NOT logged into WP but has already approved secondary site/app to use WP login.
Flow 3: User is logged into WP but has NOT yet approved secondary site/app to use WP login.
Flow 4: User is NOT logged into WP and has NOT yet approved secondary site/app to use WP login.
Flow 5: User doesn’t have an account and needs to register on WordPress.org.

FLOWS
​https://cldup.com/FpjEwBuRCY.png

login.wordpress.org
​https://cloudup.com/c5J2_ezZjKO

OAuth approval
​https://cloudup.com/cZewK415gD0

[mapk]

Here's some concepts how I imagine incorporating the white box behind the form in a way that groups elements together more cohesively throughout the whole OAuth process.

Let me know what you all think.
​https://cloudup.com/cjl2ZY6QbGl

• Removed the footer text since we're saturating the page with "WordPress.org" language.
• Kept oauth stuff constrained to the white box while allowing general login stuff to exist outside it.
• The pages show the general login screen, login for oauth, approval for oauth, and a lost password screen as well.

[melchoyce]

Replying to stephdau:

Replying to melchoyce:

Do we know what a WordPress.org single sign-on would be able to access? My guess would be a list of themes and plugins you've created, your basic profile information, your contribution history, and maybe your support forum history? @stephdau, do you know?

The single sign-on is for WordPress.org, as in, you login to all the wp.org properties (sites) through the same login screen, not the one for bbPress, or single instance of WP, or GlotPress', etc. Those are sites that live under the wordpress.org domain and can share auth cookies as is.

The oAuth flow on this same login.wordpress.org, on the other hand, will be used (at first) for our other properties/sites that donot run on the wordpress.org domain, and can therefore not share auth cookies, such as buddypress.org, wordcamp.org,bbpress.org, etc. Instead of authenticating (logging in, sharing cookies), they'll authorize the site (as an app, with login only seen if if not yet logged in to wp.org).

Yup, I get that, but what access does that grant the partner sites (buddypress, bbpress, wordcamp, etc.)? Just an account? Is any of their WordPress.org data or information, aside from username, accessed by those partner sites?

Essentially: what information does the user need to know before making the decision to approve or deny authorizing this site to use their WordPress.org account?

[melchoyce]

Replying to mapk:

Here's some concepts how I imagine incorporating the white box behind the form in a way that groups elements together more cohesively throughout the whole OAuth process.

Let me know what you all think.
​https://cloudup.com/cjl2ZY6QbGl

• Removed the footer text since we're saturating the page with "WordPress.org" language.
• Kept oauth stuff constrained to the white box while allowing general login stuff to exist outside it.
• The pages show the general login screen, login for oauth, approval for oauth, and a lost password screen as well.

This is feeling really good — having it all together makes it more cohesive and streamlined than some of your earlier oAuth drafts. Are you planning to adopt Hugo's styles? I think as a v2 design they're feeling a little more polished and on-brand.

[mapk]

Replying to melchoyce:

This is feeling really good — having it all together makes it more cohesive and streamlined than some of your earlier oAuth drafts. Are you planning to adopt Hugo's styles? I think as a v2 design they're feeling a little more polished and on-brand.

Definitely. I know the button needs to be revised to match the commonly used styles. Was there anything else you were thinking?

[hugobaeta]

@mapk Here's the sketch file with my mockups - ​https://cloudup.com/ctYVx2oOoOj - Use this as base for your other screens, as I have made sure they have the right proportions and spacing, and made sure the text is the right color and sizes too. Let's keep the logo within the sheet too.

Notice how I'm treating the "Create Account" link there - it's in a secondary section of the sheet. That kind of detail helps give the content some hierarchy and structure. That would also be a perfect spot for the "Currently logged in as..." information or the "Back to login" link.

Another note is, we also have a standard (non-primary/non-blue) button styles in core. Please use that instead of the gray "Decline" button you created on your mockups.

I followed your lead and removed the footer text. If we don't have that, then I believe the white sheet should cover the whole screen on narrower screens (mobile). Adjusted the mockup to reflect that.

If you're stuck on any of this, feel free to ping me and I'll point you in the right direction ;)

[mapk]

I don't think putting everything in a white box is the best design solution here. If we're trying to follow a design language (as mentioned above), I think my recent comps are much more closer inline with the header that exists across the entire site (a lighter logo against a darker background).

It appears that placing everything in a white box is an attempt to get it off the dark background. This being said, I believe we're not designing for the problem. As I've mentioned, if there are strong opinions against the dark background, let's revert it back to a lighter background.

Yes, no? :)

[mapk]

I explored this with the lighter grey background. Please take a look and let me know what you think.

​https://cloudup.com/cwlw-OSH_0m

[melchoyce]

I think comment:33 was heading in a good direction, but going back to a light background isn't a bad jump.

Overall, your mockups seem okay, but there's a lot of small design details that can use polishing:

• The roundness of the logo and the text against the straight edges of the form creates a bit of a weird optical illusion with the overall sizing and alignment of the content area that makes it feel really top-heavy. I'd suggest breaking that illusion either by increasing the width of the login box, or playing around with the sizing of the logo.
• The spacing feels off, which I think makes it feel a little unbalanced.
• There are a couple places where the alignment is off:
  • "Remember me" is not vertically aligned to the checkbox
  • "Forgot Password / Create an account" are not horizontally aligned to the login box
  • The Approve/Deny button text also looks 1px off
• Some of the oAuth screens could benefit from some dividers, or light grey backgrounds beneath some of the supplementary info, like "currently logged in as..."
• Also on the oAuth screens, the repetition of the grey WordPress logo feels a little weird; maybe you could try using either the version of the WordPress.org logo with the blue W, or swap out the singular grey W for a blue one?
• The Approve/Deny button text looks a little small.
• Some of the text feels unbalanced — the labels feel a little too big, for example, and since all of the text is the same color none of it really stands out. There's an overall lack of text hierarchy on some of these screens, compounded I think by some of the spacing between elements (especially on this screen: ​https://cloudup.com/ivKkqJsxXFp)
• The borders on the input fields feel really dark. What if we kept the more subtle borders and box shadows on the existing input fields?
• The "remember me" checkbox also feels really large.

[mapk]

OK, cool, I'll make a few of those suggestions and get another round up for review. In the meantime, if this is the agreed upon direction, I'll start implementing these changes in the HTML/CSS.

• I've shrunk down the logo a bit to pull it away from the sides.
• Everything I have is on an 8 pixel grid. I did adjust a few things you mentioned, so spacing should be spot on.
• I think the repetition of the logo enforces what's going on. If we change the logo color, the visual connection may be lost.
• I darkened the shadow on the grey button more (to match what currently exists) so it should appear correct now.
• The forms are now more inline with what Hugo presented earlier.

Here's the revised comps.
​https://cloudup.com/cqxYmM8QzFU

[mapk]

Another round of comps. :)

These were done after discussions with @hugobaeta and dialing things in a bit further.

​https://cloudup.com/cxGzK_UD04A

[hugobaeta]

@mapk Sweet! Thank you for taking in all the feedback! We're in the right direction! A few extra little bits that could improve:

• Lets center the whole thing vertically as much as possible (in css we can do a vertical breakpoint to make sure this looks good);
• Vertical spacing: Let's make the logo and the bottom secondary info ("Create Account", etc) equidistant from the sheet, smame vertical spacing as padding in the sheet. Also, you might have to do optical compensation, make that measure to the baseline of the logo wordmark, not the bottom of the logo bounding box. Makes sense?
• On the mobile screenshots (that I saw, but please post them here as well for everyone to see), do a 1px light border at the bottom of the sheet, so there's a better hierarchy divide from the secondary action bottom part of the layout. I think it will help really divide the section.
• The "Deny" button has a weird vertical optical alignment, but it's not a biggie, since you'll get the right alignment in the buttons for free by using the login css from core (that you can build on, instead of overwriting to get the buttons etc without extra work).

Aside from that, I think we're golden. I really like how the Approve/Deny screen was summarized to be just one short paragraph. As we discussed, it might be good to understand if we'll allow for more things that would justify having a bullet list. But that's an easy iteration from here.

Onward and Upward! I think it's ready to be coded! :)
@michaelarestad and @melchoyce - yes?

[melchoyce]

Looks good to me :thumbsup:

[michaelarestad]

On the third screen, I'd make it more obvious which account the user was signed into. (probably not a huge deal) Other than that and Hugo's last comments, it looks golden.

[mapk]

Thanks, everyone, for your input and direction. I appreciate the process and feedback! I'll be working on the HTML/CSS today.

[stephdau]

In 2465:

WPORG SSO: filtering the lost password URL to make sure to always point to our custom route/template.

See #1524

[stephdau]

In 2466:

WPORG Login: using wp_lostpassword_url() instead of a hard coded path. Now filtered for a custom route, as of r2465.

See #1524

[ramiy]

Related: #1565

[ocean90]

In 2492:

wporg login: Redesigned login pages based on feedback. Reverted to lighter background.
#1524

[ocean90]

@stephdau: ​https://login.wordpress.org/lostpassword/ is returning a 404 status header.

[stephdau]

In 2536:

login.wordpress.org theme: control returned HTTP header status code, to not return 404 for valid partials.

See #1524

Props ocean90 (https://meta.trac.wordpress.org/ticket/1524#comment:57)

[mapk]

In 2573:

Fixing UI for mobile devices.

refs
​https://make.wordpress.org/flow/2016/02/24/log-in-visual-survey-of-login-wordpress-org-on-phones/

props @ryan

See #1524

[mapk]

In 2574:

Changing version number on css to clear cache.

See #1524

[mapk]

In 2577:

Changed version number on CSS to clear cache.

See #1524

[mapk]

In 2579:

More mobile UI fixes.

See #1524:

[mapk]

In 2580:

Reversion of CSS.

See #1524

[dd32]

In 4470:

Login.WordPress.org: Allow user registration through login.wordpress.org

This change does many things, including, but not limited to:

• Making all the routes have proper templates, rather than being template-parts
• Removing all the extra WordPress functionalities and outputs
• Adding the Registration pages and routes
• Updating SSO to handle routes with URL params
• Adding rest endpoints for username/email validation

See #148, #1524

[dd32]

I'm going to go ahead and mark this as completed. There's stuff in here on things like oAuth which we'll have to come back to, but that's another ticket.