-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add link rel=canonical tag for /log-in
to tell search engine it is the same page as /wp-login.php
#15297
Conversation
3613181
to
3244849
Compare
Localized SSR would require us to async load and cache the translation files with some sort of expire delay. It's not trivial so I suggest we don't enable it for this PR. |
Just make sure this is documented in a separate issue. along with a rough estimate of the work needed. We can then prioritize it along with the rest of our maintenance backlog. |
Hmm, in this branch I'm having issues logging in via 2FA. In |
@fabianapsimoes Oh right, it needs a rebase |
Product 👍 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I had two comments but the rest of the code looks good.
client/login/wp-login/index.jsx
Outdated
@@ -79,6 +79,9 @@ export class Login extends React.Component { | |||
|
|||
<DocumentHead title={ translate( 'Log In', { textOnly: true } ) } /> | |||
|
|||
<DocumentHead meta={ [ { name: 'robots', content: 'noindex, follow' } ] } /> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we really add such meta
attribute here? As far I can see, we shouldn't combine a canonical
tag with such attribute as it might prevent the canonical page from showing up in the search engine results.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we decide to keep it, the meta
should be merged into the DocumentHead
element above.
client/login/wp-login/index.jsx
Outdated
@@ -79,6 +79,9 @@ export class Login extends React.Component { | |||
|
|||
<DocumentHead title={ translate( 'Log In', { textOnly: true } ) } /> | |||
|
|||
<DocumentHead meta={ [ { name: 'robots', content: 'noindex, follow' } ] } /> | |||
<DocumentHead link={ [ { rel: 'canonical', href: 'https://wordpress.com/wp-login.php' } ] } /> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What do you think of using our login()
path function here instead of hardcoding the url?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should both be merged into the DocumentHead
above.
server/pages/index.js
Outdated
@@ -120,13 +120,9 @@ function getCurrentCommitShortChecksum() { | |||
} | |||
|
|||
function getDefaultContext( request ) { | |||
let initialServerState = {}; | |||
// We don't cache routes with query params | |||
if ( isEmpty( request.query ) ) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Starting to cache if there are query params is a rather big change that should be highlighted in the PR desc, and deserves some discussion, since it means that cache slots will fill up way faster.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right, I didn't highlight this enough in the description (will do) but that's one of the reason you're marked as a reviewer here, since you have experience on SSR :)
As far as I could test, I tried every isomorphic sections and didn't see any rendering issues on the current version of calypso, I might have missed some cases though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The issue is that we need to somehow predict how this will scale under load...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Tug do you have a defined set of query args and values we could whitelist?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The idea here is to actually ignore query params for SSR completely.
server/render/index.js
Outdated
@@ -86,8 +86,7 @@ export function serverRender( req, res ) { | |||
config.isEnabled( 'server-side-rendering' ) && | |||
context.layout && | |||
! context.user && | |||
isEmpty( context.query ) && |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Again, dropping this criterion might have quite an impact since we might end up calling renderToString
(and thus, blocking node
) way more often.
cc @ehg
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, this worries me. Aside from crawlers slowing the loop down, we could conceivably attack the server to DoS it with ease.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@alexsanford this where an event loop timing log could come in useful :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think this change implies calling renderToString
more often. Here we're basically saying that we should ignore query parameters and just cache the first version of the page rendered. Follow up requests with the same pathname but different query parameters will end up loading that first version.
I agree it's quite a change but I tested the few logged out routes we have and I didn't see any issue with it so far.
Can you update Jed template instead? I'm on parental leave after sleepless nights so you can ignore me :D |
Yes that would be a solution. Imo, it's cleaner to have it here. But in case we can't agree on this SSR change we'll have to go with editing the server template.
Happy parental leave Grzeg ;) |
This would be a problem at least for Magic Login which is rendered server side and uses query params. |
Let's worry about SSR in another PR and merge this change first. |
👍 for a simple solution for now. 🚢 |
@scruffian I added a commit to update the head tags from the client once the js has loaded. If you feel this is unnecessarily complex I'll remove it and we'll merge without it |
Nice changes @Tug. 🚢 |
Redirecting
/wp-login.php
to/log-in
resulted in some internal checks raising errors regarding our meta and link tags.This fix will tell search engine that our new
/log-in
page is essentially the same as the legacy one (/wp-login.php
).Testing instructions
npm start
)curl "http://calypso.localhost:3000/log-in" | grep '<link rel="canonical"'
and check that the tag is indeed in the returned htmlcurl "http://calypso.localhost:3000/log-in?redirect_to=https%3A%2F%2Fwordpress.com%2F" | grep '<link rel="canonical"'
will not workcurl "http://calypso.localhost:3000/log-in/fr" | grep '<link rel="canonical"'
will not workReviews