In WordPress 4.4 and 4.5, various pieces of work were done to improve HTTPS support in core, but not much has been tackled since then. To address this, I’m going to re-start the weekly chats in the #core-http channel in Slack. Fridays late afternoon UTC/GMT are good for me — does this work for other people who are interested in helping with HTTPS issues?
Although the HTTPS improvements are always ongoing and not tied to a particular release, it would be great to get some improvements into 4.7.
If you run a WordPress site over HTTPS only, support is very good and there are very few issues to contend with. If you’re running a multisite network on HTTPS there are a few small issues when adding new sites. However, the main HTTPS issues in core come from:
- Enforcing the HTTPS scheme on assets (such as embedded images in post content, and enqueued JS and CSS).
- Enforcing the HTTPS scheme on links, redirects, and canonical URLs.
- Migrating an existing HTTP site to HTTPS.
- Running a site that uses a mixture of HTTP and HTTPS.
The first two points — avoiding mixed content on HTTPS sites — need to be solved via an opt-in system (either via constants or filters) because enforcing these can cause issues with sites that run proxies (for example Cloudflare’s Universal SSL). Overall though, this ought to be a fairly straight forward set of enhancements to implement.
The third point is a potentially complex one which will need a lot of discussion and some ideas putting forward. How can core make life easier for a site owner who wishes to switch their site from HTTP to HTTPS? Should it be a case of being able to change the scheme in the URL on the General Settings screen or is there too much risk of breakage? What else can be done post-migration to aid the site owner, or will the opt-in enhancements for avoiding mixed content be enough?
The last point is one that, going forward, should be generally discouraged, however it needs to continue to be supported for multisite networks that use domain mapping and can’t serve every domain over HTTPS.
There’s an https keyword on Trac which has been applied to tickets that concern HTTPS issues. We’ll start going through this list in next week’s chat.
Here’s a bunch of further considerations that need to be taken into account while working on HTTPS issues:
- Differing schemes, domains, and ports in the
siteurl and home options.
- Domain mapping
force_ssl_admin() usage- Self signed certs
- No public access to admin URLs
- Different HTTPS domain on front end (!)
- HTTP site optionally available over HTTPS
Here’s a list of items that should be considered for enforcing over HTTPS:
- Enqueued JS and CSS.
- Post content, images, js, CSS, iframes,srcset, oembeds, forms.
- How about other fields such as term descriptions, user bios, etc.
- Force https links. Links to the current site.
- Force https link in nav menus.
- Force https redirects and/or canonical.
- Force HSTS. (Probably not.)
- Force https rest api endpoint.
- Force https XML RPC.
- Set https-only on cookies.
Let me know in the comments if you’d like to help out and if Fridays are good for the meeting time!
Reply
You must be logged in to post a comment.