Disable external libraries error from webform

While this is technically OK, from a privacy and compliance perspective this may cause issues, since loading from third parties may require user's consent first.

I see! Well this is the default state so I'm glad I brought it up :)

How can we determine whether it is a privacy concern? We can always load the libraries if needed, just assumed it would not be the preference.

Providing them locally is the best approach from a privacy perspective, and if download duration or storage volume, especially in the WASM context isn't an issue, this should be the way to go.

Note: we've changed the download of all libraries away from regular composer dependencies and now use zodiacmedia/drupal-libraries-installer instead, see https://packagist.org/packages/zodiacmedia/drupal-libraries-installer

This downloads the packages directly without going through composer repositories, which is cumbersome to maintain.

In January 2022, there was a German Court decision that including Google Fonts via Google URLs violates GDPR, because it sends IP address to Google. See for example: https://cookie-script.com/blog/google-fonts-and-gdpr

This is similar as other scripts / CDN resources.

@poker10 that's correct and we have that on the radar for the privacy track. Thanks for confirming this.

So...Webform includes a download-libraries Drush command that...downloads its libraries.

The Starshot prototype ran it as part of installation, but it was removed from Drupal CMS for technical infrastructure reasons. The in-browser trial will, ultimately, NOT be preinstalled, so I'm not sure there's a whole lot we can do there.

I didn't know about that neat-looking Composer plugin mentioned in #6 - that seems like an interesting solution, but the issues I see there are:

• We'd have to convince Webform to adopt it, and file a patch for that, which would have to be committed first, since composer.json files are effectively unpatchable.
• The last commits to the plugin's code were two years ago, during which Composer has significantly evolved. Is this plugin even maintained?

@phenaproxima webform wouldn't have to change anything. The list of libraries would have to go into the composer.json of the root project, e.g. like this:

{
  "extra": {
    "drupal-libraries": {
      "blazy": "https://github.com/dinbror/blazy/archive/1.8.2.zip",
      "codemirror": "https://github.com/components/codemirror/archive/refs/tags/5.65.12.zip",
      "colorbox": "https://github.com/jackmoore/colorbox/archive/refs/tags/1.6.4.zip",
      "dompurify": "https://github.com/cure53/DOMPurify/archive/refs/tags/3.0.9.zip",
      "dropzone": "https://github.com/dropzone/dropzone/releases/download/v5.9.3/dist.zip",
      "imagesloaded": "https://api.github.com/repos/desandro/imagesloaded/zipball/67c4e57453120935180c45c6820e7d3fbd2ea1f9",
      "fontawesome": "https://use.fontawesome.com/releases/v6.5.1/fontawesome-free-6.5.1-web.zip",
      "friendly-challenge": "https://registry.npmjs.org/friendly-challenge/-/friendly-challenge-0.9.16.tgz",
      "fullcalendar": "https://github.com/fullcalendar/fullcalendar-workspace/releases/download/v6.1.11/fullcalendar-scheduler-6.1.11.zip",
      "jquery.chosen": "https://github.com/harvesthq/chosen/releases/download/v1.8.7/chosen_v1.8.7.zip",
      "jquery.geocomplete": "https://github.com/ubilabs/geocomplete/archive/refs/tags/1.7.0.zip",
      "jquery.hotkeys": "https://github.com/jeresig/jquery.hotkeys/archive/refs/tags/0.2.0.zip",
      "jquery.icheck": "https://github.com/dargullin/icheck/archive/refs/tags/1.0.2.zip",
      "jquery.image-picker": "https://github.com/rvera/image-picker/archive/refs/tags/0.3.1.zip",
      "jquery.inputmask": "https://github.com/RobinHerbots/jquery.inputmask/archive/refs/tags/5.0.8.zip",
      "jquery.intl-tel-input": "https://github.com/jackocnr/intl-tel-input/archive/refs/tags/v17.0.19.zip",
      "jquery.rateit": "https://github.com/gjunge/rateit.js/archive/refs/tags/1.1.5.zip",
      "jquery.select2": "https://github.com/select2/select2/archive/refs/tags/4.0.13.zip",
      "jquery-simple-color": "https://github.com/recurser/jquery-simple-color/archive/refs/tags/v1.2.3.tar.gz",
      "jquery.textcounter": "https://github.com/ractoon/jQuery-Text-Counter/archive/refs/tags/0.9.1.zip",
      "jquery.timepicker": "https://github.com/jonthornton/jquery-timepicker/archive/refs/tags/1.14.0.zip",
      "jquery.toggles": "https://github.com/simontabor/jquery-toggles/archive/refs/tags/v4.0.0.zip",
      "masonry": "https://api.github.com/repos/desandro/masonry/zipball/3b0883cf4a4a046896719b9cf282ea74be7ffecd",
      "popperjs": "https://registry.npmjs.org/@popperjs/core/-/core-2.11.6.tgz",
      "progress-tracker": "https://github.com/NigelOToole/progress-tracker/archive/refs/tags/2.0.7.zip",
      "select2": "https://github.com/select2/select2/archive/4.0.13.zip",
      "signature_pad": "https://github.com/szimek/signature_pad/archive/refs/tags/v2.3.0.zip",
      "slick": "https://github.com/kenwheeler/slick/archive/1.8.0.zip",
      "slide-element": "https://github.com/alexmacarthur/slide-element/archive/refs/tags/v2.3.1.zip",
      "spectrum": "https://github.com/bgrins/spectrum/archive/refs/tags/1.8.0.tar.gz",
      "svg-pan-zoom": "https://github.com/ariutta/svg-pan-zoom/archive/refs/tags/3.6.1.zip",
      "tabby": "https://github.com/cferdinandi/tabby/archive/refs/tags/v12.0.3.zip",
      "tippyjs": "https://registry.npmjs.org/tippy.js/-/tippy.js-6.3.7.tgz"
    }
  }
}

The drush is not required as the download is handled by the composer plugin.

The code hasn't changed for a while, but it is a simple plugin and it just works. It's not affected by composer version either.

@pameeela

To solve Disable external libraries error from webform you need to follow mention step:

1. In composer.json add this code

"merge-plugin": {
"include": [
"web/modules/contrib/webform/composer.libraries.json"
]
},

2. use this command in root

-> composer require wikimedia/composer-merge-plugin
-> composer update drupal/webform "drupal/webform-*" --with-dependencies
-> composer update

Please let me know if any query.

Re #10: I'm strongly opposed to that idea because if we do that, we would effectively be forking Webform's list of dependencies, which is almost guaranteed to cause headaches for us.

Re #11: That's at least marginally better, since it's not forking anything, but I dunno...something about it still makes me uneasy - the merge plugin has always felt a little kludgey, and this just outlines the ongoing problem that Drupal core has no good way to manage external libraries.

I am truly not sure the solution is to be found at the Drupal CMS level. Most likely we should talk to the Webform maintainers, and possibly some core developers, to find a sustainable path here.

Assigning to myself to see if my gurus have any advice on this front.

Thanks @phenaproxima! Sounds like we are not going with the disable check option so I've updated the issue :)

This is blocked on the proof of concept being done in #3472824: Add support for a11y_autocomplete widget → , and possible adoption of the Foxy module.

The in-browser trial will, ultimately, NOT be preinstalled, so I'm not sure there's a whole lot we can do there.

I think it will be now, so I wonder if we can revisit this? It doesn't look like we'll get the proper library management working for v1.

Discussion of this going on at ✨ Create a mirror for external library dependencies for composer support Active

There's potential for a long-term fix, but not one that will be ready for 1.0. So I think we need to decide whether to try to handle this separately, for the moment, or live with the CDN implementation.

The CDN route is not feasible as it would turn the privacy achievements upside down. But as discussed in the referenced issue, here is what I can do, if nobody objects:

• Creating general projects for each webform library on d.o to mirror the current version of each library
• Tagged them with the same release numbers as the current original library
• Provide a recipe for Drupal CMS that requires the webform module and all those libraries from d.o, i.e. from packagist.org at that point

With that approach, webform is installable and usable from within Drupal CMS (also from project browser on other Drupal sites) and still upgradeable with the regular tools that are used nowadays, without the need for any extra plugin.

I think #17 might be the best approach I've heard suggested to how the Drupal community could handle external dependencies.

I would urge us to come up with a naming convention for the external libraries.

The Full Calendar module is using https://www.drupal.org/project/fullcalendar_io →

My thought/suggestion is we suffix all the mirrored libraries with *_library because there are being installed in the /libraries directory.

The _io suffix for fullcalendar was chosen because of the external domain fullcalendar.io.

In general, I think _library is not bad. I had suggested _js before, but either way should work.