Add token for Drupal Forge widgets

Created on 27 November 2024, 8 months ago

Problem/Motivation

Drupal Forge widgets are embeddable web components that launch Drupal in a cloud environment. We plan for vendors to offer hosting through them. As web components, they require a script to be embedded along with them to function. We would like project maintainers to be able to add them to project pages to support their projects with hosting sales. However, allowing users to add scripts to drupal.org would be an unacceptable security risk.

Proposed resolution

Create a token that expands to a web component element and script tag. For example, [drupalforge:71] would expand to

<webform-component host="https://www.drupalforge.org" templateid="71"></webform-component>
<script src="https://www.drupalforge.org/modules/custom/starshot_core/assets/js/webform-component.js?sni73c"></script>
โœจ Feature request
Status

Active

Version

3.0

Component

User interface

Created by

๐Ÿ‡บ๐Ÿ‡ธUnited States darren oh Lakeland, Florida

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @darren oh
  • ๐Ÿ‡ช๐Ÿ‡ธSpain fjgarlin

    Wouldn't it make more sense to have a "Drupal Forge" specific module for D7 and D10+ that offers those tokens, and then we can evaluate/decide whether we use the module or not? If we install that module on d.org then the tokens that you suggest would be available.

  • ๐Ÿ‡บ๐Ÿ‡ธUnited States darren oh Lakeland, Florida
  • ๐Ÿ‡บ๐Ÿ‡ธUnited States darren oh Lakeland, Florida
  • ๐Ÿ‡ช๐Ÿ‡ธSpain fjgarlin

    I guess that if we want to consider it we'd need to have a D10+ version of it as well so when we migrate the tokens continue working. In any case, I'd like to have @drumm evaluate this request.

  • ๐Ÿ‡บ๐Ÿ‡ธUnited States drumm NY, US

    We avoid loading 3rd-party resources as much as possible, especially JS. This is for visitorโ€™s privacy, and security since this is JS code. If there is a really good reason this canโ€™t be all in Drupal.orgโ€™s codebase without 3rd-party requests, then we can look around your privacy policy and make sure our privacy policy and terms are compatible.

    Unless this is time-sensitive, we really should wait for Drupal 10. The more time we spend on D7, the longer migration will take.

  • ๐Ÿ‡บ๐Ÿ‡ธUnited States darren oh Lakeland, Florida

    This is time-sensitive because we are using it for Starshot demos. I have moved the external JS to the module code.

  • Assigned to drumm
  • Status changed to Needs review 4 days ago
  • ๐Ÿ‡บ๐Ÿ‡ธUnited States darren oh Lakeland, Florida

    Now that sections of the site are running Drupal 10, it is time to revisit this.

Production build 0.71.5 2024