Add token for Drupal Forge widgets

Created on 27 November 2024, 24 days 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.

Production build 0.71.5 2024