Contrib.social

disabling CDN causes php warnings with webform in multilingual setup

Open on Drupal.org →
Created on 26 April 2024, 7 months ago
Updated 6 May 2024, 7 months ago

Problem/Motivation

Error message:

Warning: file_get_contents(libraries/codemirror/lib/codemirror.js): Failed to open stream: No such file or directory in _locale_parse_js_file() (line 1097 of core/modules/locale/locale.module).

Warning: file_get_contents(libraries/codemirror/addon/runmode/runmode.js): Failed to open stream: No such file or directory in _locale_parse_js_file() (line 1097 of core/modules/locale/locale.module).

Warning: file_get_contents(libraries/codemirror/addon/display/placeholder.js): Failed to open stream: No such file or directory in _locale_parse_js_file() (line 1097 of core/modules/locale/locale.module).

Warning: file_get_contents(libraries/codemirror/mode/yaml/yaml.js): Failed to open stream: No such file or directory in _locale_parse_js_file() (line 1097 of core/modules/locale/locale.module).

Caused by:

I thought, that the cdn key in *.libraries.yml is a core feature for external libraries. But it is just some magic from the webform module to replace it’s library definitions during HOOK_library_info_alter if they are not present in the file system.

Because of the alphabetical execution order of hooks (disable_libraries executes before webform), the following happens:

  • disable_libraries removes cdn key of webform libs
  • webform doesn’t transform cdn based libs
  • core wants to parse js files for localization (for no reason)
  • js file doesn’t exist in local file system
  • php warning is displayed

Related issues:

Steps to reproduce

  • dual language setup (de, en; default: de)
  • install disable_libraries module (default settings, cdn keys are disabled)
  • install webform module
  • save Config/Advanced form of webform (causes cache flush) or
  • clear cache and open a webform page

Proposed resolution

Make sure to execute last when altering library info using HOOK_module_implements_alter, so all other modules (like webform) can do their changes. With the current implementation webform would transform it’s libraries to external libraries, pointing to the urls defined in the cdn keys. Afterwards only the cdn key is removed from these libraries and external libraries are loaded. So a different implementation is needed.

Remaining tasks

  • [x] execute last disable_libraries_module_implements_alter
  • [x] implement different solution to disable webform cdn usage
  • [x] rename disableCDN config to disableWebformCdn
  • [x] change existing tests
  • [x] write new tests

User interface changes

TODO

API changes

TODO

Data model changes

TODO

🐛 Bug report
Status

Fixed

Version

0.1

Component

Code

Created by

raffaelj

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

Comments & Activities

  • Issue created by @raffaelj
  • Comment 7 months ago →
    System Message
    • raffaelj → committed a3a64869 on 0.x 
      improved handling/disabling external libraries, fixes #3443762

*...
  • Status changed to Fixed 7 months ago
  • Comment 7 months ago →
    raffaelj
  • Issue was unassigned.
  • Status changed to Fixed 7 months ago
  • Comment 7 months ago →
    raffaelj
  • Comment 7 months ago →
    🇩🇰Denmark ressa Copenhagen

    Maybe you know this, but a "Fixed" issues will automatically change to "Closed (fixed)":

    The issue has been resolved (usually by committing a patch). Issues that remain in this state without any additional comments will automatically be set to "Closed (fixed)" after two weeks. This gives interested parties time to reactivate the issue if they see a problem with the fix and also allows time to see that a change has been made.

    https://www.drupal.org/docs/develop/issues/fields-and-other-parts-of-an-... →

  • Comment 7 months ago →
    raffaelj

    I know, but I was in cleanup mode :-)

    > This gives interested parties time to reactivate the issue if they see a problem with the fix and also allows time to see that a change has been made.

    This is a good point to keep future issues open for a while... But the color coding is confusing. On Github and Gitea/Forgejo (and I think Gitlab, too) green is open and red is closed. So everytime I see a non-red issue, it looks like it needs work. With Drupal's color coding and fixed, but open issues, the list becomes too cluttered. Closing manually helps getting things out of sight and out of my head.

  • Comment 7 months ago →
    🇩🇰Denmark ressa Copenhagen

    Heh, I thought it might be something like that -- a spring clean :)

    And I agree about the colors, though with a slightly different take ... The other day I thought about it, and reached a conclusion that open issues could be a standard link as they are now, "Needs work" with a slightly colored background is fine. But the red background should be reserved for open major/critical issues.

    Currently, a closed issue has a "text-decoration: line-through" which is fine, but with a red background which to me signals "danger, danger" (Example: "#3443762" on 📌 Allow to disable (dynamic) CDN loading of libraries in general Active ) In stead, a fixed closed issue should have a grey background in my opinion, to signify that the issue is calm/resolved.

    But it's all up to individual taste.

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024