Ghost: Skip absolute->relative transform for canonical urls with mismatched protocols

[kevinansfield]

Currently, when storing a canonical URL for a post, if the domain matches we automatically transform the URL to relative when storing it in the database. Then, when it comes time to output the canonical URL either on the front-end rendered pages or via the API we transform it again to absolute. This works well for the most part and matches our other URL handling.

However, there is a particular use case which comes up when sites have migrated from http to https and they are using Facebook comments, sharing stats, etc. The problem here is that Facebook treats the old canonical as source-of-truth even when there is a 301 redirect set up for http->https which means that post-migration all of your comments and share stats disappear. The workaround for this is to set the canonical back to the http version for old pages where you want to to keep Facebook comments.

The proposed change is to keep the absolute->relative behaviour _unless_ the protocol entered in the canonical field does not match the one that's configured, in that case we will store the absolute URL. The change is specific to the canonical_url field, all other absolute<->relative handling should stay as is.

Impact of the change:

• majority of users never enter a custom canonical, nothing changes
• users with external canonical urls always have absolute urls, nothing changes
• users with internal canonical urls should be using the same protocol (eg, copy/paste) or manually typing a relative url when putting the url in, nothing really changes
• users trying to deal with FB after a http->https change now have an escape valve to get their share states, comments, etc back. No more confusing behaviour of manually typing http only for it to magically switch to https when saving

[umuur]

Hi there, can I take this as a first timer?

[kevinansfield]

@umuur go for it 👍 😄

[aileen]

@umuur Just a little heads-up 😉 We would like to have this fix in our next release, do you think you'll be able to tackle this issue until Friday? Let us know if you have questions or get stuck!

[umuur]

@AileenCGN thanks for catching up! I think I'm able to fix and send a pull request until Friday :)

[aileen]

@umuur Sorry, but I just pushed a PR for this 😊 Thank you for taking a look at this anyway 🙇‍♀

[aileen]

Reopening this issue, as it doesn't work as intended. The value stored in the db is stored correctly:

and also shown as such in the Post Settings Menu:

but the HTML output seems to enforce https somehow:

I can't see anything in the further processing (meta data, ghost_head helper) where this would be manipulated further...

[naz]

@AileenCGN have you been able to reproduce this locally? On my environment it works fine:

[aileen]

@gargol I couldn't really, as I can't use SSL locally. Using a different protocol in my local environment did work without a problem. Only when I use it in production which a https site, and setting the canonical URL to http, it doesn't work.

[naz]

@AileenCGN the feature is meant to be used with API v2 only, it wasn't meant to work on v0.1 :sweat_smile:
We default to v0.1 when no version is specified in config's engines.ghost-api property which leads to this confusing behavior.

The solution would be adding in theme's package json correct API version:

    "engines": {
        "ghost": ">=2.0.0",
        "ghost-api": "v2"
    },

if the server is on Ghost >2 and if theme is compatible with v2 API.

Special thanks to @vikaspotluri123 for a tip :wink: