Relative URL option breaks standards / Q: To support or not to support relative URLs

[fmt]

When the relative URL option is set, hreflangs tags FQURLs (namely protocol + domain, that are required by the hreflang specification) are being replaced with the relative URL setting, ie:

<link rel="canonical" href="**https://www.domain.com**/path/">
<link rel="alternate" href="**https://www.domain.com**/path/" hreflang="en">
<link rel="alternate" href="**https://www.domain.com**/lang/path/" hreflang="lang">

are being replaced with:

<base href="/basepath/">
<link rel="canonical" href="/basepath/path/">
<link rel="alternate" href="/basepath/path/" hreflang="en">
<link rel="alternate" href="/basepath/lang/path/" hreflang="lang">

[leonstafford]

Thanks Felipe!

I'm going to be doing some deep-diving into the ZIP/Offline ZIP method soon, which should see a refactoring and hopefully some unit tests around this area.

Still a few days away, I think...

[leonstafford]

This issue was discussed similarily with WP2Static V7, where default URL setting is site root relative, with option to use FQURL. This is handy for newcomers, who may export to Netlify, S3, BunnyCDN, etc, using the https://MYSITE.netlify.app or such.

What it doesn't cater for are these link element's hrefs and similarily, Sitemaps and other places, where the standard is to use FQURLs.

So, for those still wanting to use site or document relative URLs, there's going to be some extra hoops the plugin will need to do, checking what kind of content we're changing and what preferences the user has.

The only case we're really supporting doc root relative URLs for are:

• offline site export (my preference would be to drop this feature and refer to HTTrack/wget/SiteSucker/Save as web archive, etc. Else, we need to also rewrite external protocol-relative URLs, like external fonts, it's just more trouble than is worth)
• hosting exported site in a subdir (usually more trouble than it's worth and most doing such a setup should be able to proxy requests from https://wpsite.domain to https://domain.com/wpsite/. This would be a case where site root relative URLs would probably make sense to avoid the https://wpsite.domain URLs appearing in proxied source.

Based on this pondering, I'm inclined to limit options to FQURLs as destination URLs, at least in Static HTML Output, where we're parsing the DOM and normalizing URLs as first step (similar in SimplerStatic). Then, when a user has the option "Use site root relative URLs" (optionally with setting Base HREF tag, we determine if it's a safe tag to convert to site root relative, preserving things like link href, sitemap/robots URLs and others with RFC's requiring FQURLs.

TL;DR proposed actions:

• require Deployment URL set as FQURL
• drop document root relative URLs option
• drop offline URLs feature & recommend better suited tools
• selectively convert to site root relative URLs when user chooses that option, keeping base href option to allow for FQURL or /blog/ as base href (still questioning how useful this is)

@fmt I know this is an old discussion, but I think you were utilizing relative URLs in your deployments. If this is still the case, what potential issues do you see with proposed actions above?

[thegulshankumar]

Relative URLs should be supported. It can help user quickly addressing mixed content issues.

It can also reduce HTML page size (Maybe just few bytes, but worth as it looks good)

I would prefer having complete absolute path for ...

• Canonical
• hreflang
• Facebook Open Graph
• Twitter Card
• JSON-LD markup

Thanks

[leonstafford]

The risk of breaking those elements which require absolute paths is too great a risk to let the plugin do the conversion from FQURLs to relative. We may know about Open Graph code today, but then need to update the plugin to blacklist other elements from relative URL rewriting in the future.

There are some plugins to do relative URLs available, so the end result should still be possible. For this though, our plugin should respect the existing URL and not rewrite it to FQURL, which it is likely to try and do today, but work can be done to preserve those.

FQURLs: no risk to break site functionality (mixed content issues as per https://github.com/WP2Static/static-html-output-plugin/issues/62)

Relative URLs: risk to break site functionality