-
Notifications
You must be signed in to change notification settings - Fork 100
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
Display notice if HTTPS is not enabled, use 301 code in redirect #56
Comments
Strong 👍 to both. (a) What will be the messaging for no HTTPS? (b) FWIW, there is a use case for 302, but we wouldn't want that to be the permanent setting. A 302 is useful and relevant when you're testing a site migration: you want to see it live, but you may not be ready to signal to all the crawlers that HTTPS is the new "canonical". However, to complete the migration we definitely need the 301 as the final destination. Ideally, there would be some "burn in" period where 302 is used to verify and troubleshoot, with a 301 switch once everything is confirmed. |
This burn-in period sounds similar to what we were thinking of for HSTS. Maybe adding HSTS could be the final step in the burn-in period, with exponential backoff of the TTL. So maybe:
|
Redirect Code, HTTPS Notice Hi @westonruter and @igrigorik, (b) Here's some possible copy for an admin notice if HTTPS is not possible, like if there's no certificate:
|
Re, HTTPS notice, some suggestions..
For the "more details" link, are there any other pages that we could link to in the codex, that focus on the user+site owner benefits of HTTPS instead of the technical guidance? I don't think that page does a good job of motivating the claim we're proposing in the notice. If there aren't resources in the codex, could we link to: https://developers.google.com/web/fundamentals/security/encrypt-in-transit/why-https ? Re, burn-in period: @westonruter how do you see the proposed schedule working?
|
Link For 'More details' Hi @igrigorik,
Good question. I couldn't find a page on |
@kienstra @westonruter could we link to the Web Fundamentals article then? Are there any best practices / requirements on links from WP dashboard? |
Hi @igrigorik, Sure, I think it'd be fine to link to the Web Fundamentals article.
Good question. I couldn't find any documentation or best practices on links in the dashboard. But it looks like all of 5 of the external links on 'Settings' pages are to the Codex (in 'General Settings,' 'Writing Settings,' and 'Permalink Settings'). |
I suspected as much. If there are no objections, let's go with the WF link. If there is push back down the road, we can investigate other options. I just don't feel that the current codex page on HTTPS covers the motivation sufficiently well. |
Yes, that's right.
That sounds like a good idea.
For core merge proposal we would definitely need a WordPress Codex page for HTTPS. In the mean time, linking to WF is fine. Here are all of the linked URLs that I can find in the admin: https://gist.github.com/westonruter/01d87482846aa8131afca186cad2de0f There are only 3 exceptions to linking to WordPress.org URLs: |
Hmm, there is a complication here. Once you set 301 and/or HSTS, and you uncheck the setting.. The users may still be directed to HTTPS (due to HSTS policy), and you'd need a 301 from the HTTPS back to HTTP for crawlers if you want to avoid any confusion there. 302 is safe "testing mode". Once you flip the 301 + HSTS switch though, going back is much harder. I think it's worth spending a bit more time on the UX here: how we communicate the 302 / testing, if/how the transition to 301 happens, and what happens when you try to "revert" the 301.
What's the process for updating codex pages? If we can update the HTTPS page to cover the why, perhaps even by linking to WF, then I'm a happy camper. |
I've raised the topic in WordPress core dev chat today: https://wordpress.slack.com/archives/C02RQBWTW/p1536178915000100 I was really happy with the positive response. It was proposed that the HTTPS detection and switchover could be incorporated into a new “Site Health Check” initiative which would be merged into core, and the WordPress marketing team would include HTTPS in the materials that are presented to users to explain the importance of securing their sites. |
That's awesome! What's the best way to track that discussion and is there an ETA or deadline for this? |
@igrigorik Probably by joining the Also, as @schlessera noted:
The discussion conversation about HTTPS should probably be tracked as part of Site Health Check discussions: https://make.wordpress.org/core/?s=%22Site+Health+Check%22 This post has a roadmap: https://make.wordpress.org/core/2018/07/17/servehappy-roadmap-update-and-priorities/
/cc @felixarntz |
Cool, thanks for the details. I'll defer to you guys to drive this. LMK if there is anything I can help with :) |
As a follow-up to #17:
siteurl
andhome
(WordPress Address and Site Address) are HTTP, and HTTPS is not enabled (like if there's no certificate)302
to301
:https://github.com/xwp/pwa-wp/blob/e1431eae92f75a09742c7cdd3dc438011f53fb9d/wp-includes/class-wp-https-ui.php#L358
The text was updated successfully, but these errors were encountered: