RFC: protocol-relative URL from site_url

gaekwad · 2014-02-19 11:20:01

site_url outputs the URL of the Textpattern site as set in admin -> preferences, like this:

http://example.org

or:

https://example.org

In the spirit of protocol-relativite URLs and the like, is there scope to have an attribute for site_url to not output the protocol? It’s going to be useful for site operators who use https in the first instance, but it would offer a more seamless experience where a site has identical content for http and https; there would be fewer ‘this content could not be loaded because the protocol is incorrect, so nyah-nyah’ errors and dialogues.

Something like:

<txp:site_url exclude="protocol" />
<txp:site_url flavor="relative" />
<txp:site_url format="relative" />
<txp:site_url type="relative" />

Edge case, or worth investigating? Thanks in advance.

Bloke · 2014-02-19 22:20:22

gaekwad wrote #279086:

is there scope to have an attribute for site_url to not output the protocol?

Spookily enough, Mr Mind Reader, I was thinking about this yesterday, but from the other angle: what if we just omitted the forced protocol rendering from the various tags that output such things, and let whatever you specify as Prefs->Site URL shine through? If you then set your site URL to //domain.com, that’s what would get spat out.

Not sure if that’s the best way to go, as there may be edge cases where you want more control over it, for example when using a separate static image domain (ihu). Plus, having the double slash version in your prefs means that if you do, for whatever reason, want to output a scheme-aware URL, there’s some string handling gymnastics to be done to strip bits off; though it might be as simple as using parse_url().

So in that light, maybe forcing the Site URL preference to be scheme-less and then reworking the various tags to output the protocol-relative version by default, with a possible attribute to inject a dedicated protocol/scheme, e.g.:

<txp:site_url scheme="https" />

Certainly, the avoidance of ‘insecure content delivered over a secure connection’ is something we should be able to gracefully handle these days. I’m not the greatest authority on all this malarky so I’m open to ideas on how best to achieve this.

gaekwad · 2014-02-19 22:35:13

Hi Stef. It’s fairly clear to me that the vast majority of users don’t see this as an issue, and so my gut would be to leave the current URL setting in admin -> prefs as it stands to avoid having a lot of people wig out, then have an optional (attribute-based) solution to switch the protocol to http, https or agnostic for those folks (me) who would certainly benefit.

Bloke · 2014-02-19 22:47:41

gaekwad wrote #279111:

my gut would be to leave the current URL setting in admin -> prefs as it stands to avoid having a lot of people wig out, then have an optional (attribute-based) solution to switch the protocol to http, https or agnostic

Sure. Quite a few tags output URLs though, all of which use the underlying globals hu (site), ihu (images) or rhu (relative site) to render the link. Images, category and article navigation, breadcrumb trail, CSS output, search input, link to home, site url, ….

So instead of introducing a new attribute for all those potential tags that output a URL, I was wondering if there was some clever way to nip it in the bud early by allowing the Txp globals to be defined in a more generic (or perhaps scheme-free) manner so the various schemes could be switched in and out centrally (or something, not thought it through: might be difficult).

There’s some stuff in index.php to try and detect the protocol and serve the right one based on browser headers, but it’s probably flawed and only chooses between http and https, which is not the whole story.

gaekwad · 2014-02-19 22:49:26

Right, now I understand -thanks for the clarification.

Textpattern CMS

Textpattern CMS support forum

#1 2014-02-19 11:20:01