Hugo: Remove built-in shortcodes for 3rd party services

[onedrawingperday]

In light of the recent changes of the Instagram API that Facebook has enforced -see https://github.com/gohugoio/hugo/issues/7879 for the details-

I propose that all built-in shortcodes for 3rd party services (Twitter, Google Analytics, Instagram, YouTube, Vimeo etc) be removed from Hugo source.

Times have changed.

The onus of third party tracking cookies should be on individual website admins and Hugo should have nothing to do with enabling this practice anymore.

Also these shortcodes come with a maintenance cost that could be spent in other areas.

If a Hugo site admin wishes to continue having the functionality of the built-in shortcodes, then they can replicate these at the project level.

[marcusramberg]

I suspect I'll switch to another blog engine that supports embedding if this proposal goes through. 🤷‍♂️

[bitsapien]

@marcusramberg The OP here wants to remove it from the scope of the "Hugo" project and that would mean they would stop existing in Hugo's code base.

These would still live on, but as separate projects with their own software development lifecycle. They can just be plugged in as sensible defaults with the initial setup of Hugo (_maybe?_).

Documentation for this transition would be helpful though.

[bep]

@bitsapien is correct.

[jasikpark]

:raising_hand: I use the simple configuration of those shortcodes on my website, and I would find it harder to include the embeds in a privacy-preserving way without them. Perhaps instead they could be switched so that the simple version is the default, and the privacy-infringing embed is the switch you have to flip on?

  [privacy]
  [privacy.instagram]
    simple = true
  [privacy.twitter]
    simple = true
  [privacy.vimeo]
    simple = true
  [privacy.youtube]
    privacyEnhanced = true

[jasikpark]

i.e. make the default of all of those switches true rather than false, and require a privacyEnhanced = false clause in the config.toml

[jasikpark]

these have also provided good examples of how to write shortcodes for me when trying to figure it out myself -- I think including them in the base documentation should at least be replaced by similarly useful shortcode examples.

[capnfabs]

I wonder if, as an alternative to disabling these services entirely, we could split things out into separate fetch and render steps? This wouldn't address the general privacy concerns, but _would_ have prevented the Instagram breakage in #7879.

How I propose that this would work:

• Fetch required data from remote service, cache it all on disk, keyed off the shortcode params.
• Render from those cached files instead of relying upon remote servers and an internet connection for every rebuild.

The 'cache' can then be checked into source control, like what we recommend with processed images to keep build times down.

The outcome of a system like this in the Instagram breakage would be -- it would have prevented new shortcodes from being added, but everything that had already been fetched would still be able to be rendered.

This also gives you the ability to punt on the privacy problem a little bit -- the only compulsory communication with remote servers would be at build time. If we designed it right, theme / site implementors could then choose whether to present the fetched data using the service's standard embed code (i.e. what we have now), or render using custom, stripped down logic, which doesn't reference the host service.

[onedrawingperday]

@capnfabs

Please do not post general thoughts that are not about this issue.

This issue is about removing the internal shortcodes.

General discussion goes in the forum: https://discourse.gohugo.io/

In the past there had been discussion about what you proposed. Please look it up in the forum or open another GitHub issue with your proposal or discuss it at the forum.

However I am a busy person and this issue should not pop-up in my notifications without good reason.

Thanks.