Remove built-in shortcodes for 3rd party services

[onedrawingperday]

In light of the recent changes of the Instagram API that Facebook has enforced -see #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]

🙋 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.

[gj52]

Remove all this 3rd party things ....
I've overwritten all this with my own to embed the used CSS framework.
Move it in the themes, if needed.

[rodrigoalcarazdelaosa]

Related to this, the tweet shortcode will soon need to be adapted to use the new v2 API: https://developer.twitter.com/en/docs/twitter-api/migrate

[sharebear]

Related to this, the tweet shortcode will soon need to be adapted to use the new v2 API: https://developer.twitter.com/en/docs/twitter-api/migrate

That day appears to have arrived, created #8130 to cover just that issue independantly of whether the code it split out of the core hugo repo.

[philoserf]

On removing third-party short-codes from the Hugo codebase

TL;DR: I support moving third-party short-codes out of the core Hugo codebase.

Factors that contribute to my position are:

• we have Hugo modules that allow Hugo users to add short-codes as a component
• the move simplifies the core Hugo codebase
• maintenance cadence for third-party APIs need not drive a Hugo release
• developers with a focused interest in a third-party short-code have a simpler codebase
• questions of third-party endorsement are moved out of core Hugo

[davidsneighbour]

I said it at other places: Hugo is there to translate your layouts and your contents into a website. I think that ALL "internal" templates are basically holding the developers down and waste their time adapting to updates and changes in standards and implementations. An external repo with "internal layouts" would be ok. Moving them as sample into the documentation would be ok. I personally tend to NOT use anything that is internal or a Hugo based shortcode.

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.