Do not store URL protocol in the database

[aristath]

We should not store the protocol of files in the database.
Instead of http://mysite.com/wp-content/uploads/image.png we could strip the protocol while saving the entry and save it as //mysite.com/wp-content/uploads/image.png instead.
This will make http/https issues a lot easier to address, and hopefully ease migrations to HTTPS.
There are a bunch of plugins out there that can do this, but they shouldn't have to... This is something that can be done in-core a lot more efficiently for everyone.

[lukecavanagh]

Look at ticket #17048.
As well as ​https://make.wordpress.org/core/handbook/contribute/design-decisions/#absolute-versus-relative-urls.

[aristath]

I'm not talking about relative vs absolute URLs... Relative URLs strip the domain completely and we wouldn't want to do that.

What I'm suggesting is simply stripping the protocol (http or https) from the URL which is a very different thing.
Stripping the protocol would ensure compatibility with both http & https sites no matter if the user changes from one to the other.

Furthermore it will not break anything since if the saving process changes then only new assets will use the stripped format, while old ones will still have the protocol included.
This will not affect anything on any site running WordPress...
Current sites that already have assets will use the format they're already using for existing images, and new images will have the protocol stripped.
New sites however will be a lot cleaner since all assets will not include the protocol when they're saved in the db, so if they decide to switch from http to https at some point it will be a lot easier for them.
It's just cleaner this way and has no unwanted side-effects.

[jorbin]

​protocol relative urls are an anti pattern that can lead to ​security issues.

[mdgl]

Thinking more radically, why do we store explicit URLs that reference other WordPress managed content in any case? Shouldn't these be expanded dynamically as we generate the page, for example if we stored something like a shortcode in the database [objref id="2392"]? This would allow us to deal with the http(s) issue, enable users to change slugs/permalinks as they wish and create great filtering opportunities for developers. Of course you would still need to be able to insert absolute URLs if you want for references to external sites and other special cases. In my view, a clear distinction between such "internal" and "external" links would be quite helpful.

[aristath]

@mdgl that would require significantly refactoring parts of WordPress Core... and would most probably cause backwards-compatibility issues. You'd need a mechanism to store those object references, another one to retrieve them ,expand them and so on. There a re a bunch of plugins out there that query the database directly, so all those would probably break if we change the schema.
The current implementation is battle-tested and just works. All it needs in my opinion is just a couple of tweaks...

[mdgl]

Why would you need to change the database schema? Wouldn't the following work:

• New option in TinyMCE to "insert reference to internal content", perhaps showing a popup/filterable list of items; when selected insert shortcode to reference the appropriate database object.
• New shortcode to expand reference to database object to URL.

No backwards compatibility issues. Current content is unaffected. Users can still insert and edit URLs if they want.

[aristath]

Oh, ok... Now I get what you're saying. I misunderstood your comment above.
But still... Not everyone uses TinyMCE. I know I don't... I just go to the media library, get the URL of the image I want to use, and then write my own markup in the text editor.

[mdgl]

Indeed, and nothing stops you just writing the shortcode yourself: go to media library, identify object ID, insert shortcode manually in text editor.

For images, I think this method would provide an even cleaner and more flexible method for dealing with image substitution (e.g. for responsive designs, use of CDN and so on).

Only question for me is whether this should use a standard "shortcode" or whether a new/private facility should be created so that it is clearly a separate function.

[desrosj]

I still have not heard an argument for a specific change, or a convincing argument for why the related ​design decisions detailed in the core handbook should be changed.

Unless someone can make a more compelling case for this, I think this is a wontfix.

[aristath]

@desrosj this ticket was never about relative URLs, it was about stripping the protocol from db-stored URLs.
It was created 3 years ago, at a time when people were starting to mass-migrate all their sites from http to https.
The fact that we're storing the URL protocols in the db usually requires changing a lot of things and causes massive issues when a site changes its protocol. If on the other hand we were not storing http/https when saving a URL in the db, most of these issues would be a thing of the past.
For example try switching an http site with a slightly complex theme and a dozen plugins to use SSL... Images are usually the first thing to go when loading a page on such a site 'cause the browser just blocks them since they're getting loaded using the http url. Or at least that was the case back then, I haven't checked in the past couple of years so maybe something has changed.

[pento]

There are several options available for working around this, without needing to change every URL in every post in the database.

#28521 has more discussion on appropriate ways to handle sites upgrading from HTTP to HTTPS, so I'm going to close this ticket in favour of that one.