@raffaelj

> Is it also happening with the latest Git version?

I don't know, but I guess so. If I remember correctly, the latest version requires Drupal 11. I can't install Drupal 11 (in my local docker test setup), because it requires SQLite >=3.45. Now I'm waiting for 🐛 database driver crashes during install (dependency not autoloaded) Needs review to get merged. Than I'll have a working throw-away dev setup for D11 again.

During my quick test with this module, it looked like it is not capable of translating admin/settings pages of self written modules locally. So I also lost interest in digging deeper.

When this module is compatible with D10 again or when I have a working D11 setup, I might have another look.

> Can we get test coverage added for the new exception being introduced.

@smustgrave I don't think, this is needed. And if so, I can't wrap my head around how I could test it. I think, it's a misunderstanding because of my wording in #6 and because I should have commited my changes in a different order.

What I did:

1. moved a view lines of code in `Database.php` to throw an Exception at the right moment (was wrong before)
2. fixed test, that never caught the bug, because the test has a different autoloading mechanism, than a production system

What I should have done:

1. Fix `UrlConversionTest` to mimic production system, which now throws Exceptions, that weren't caught before. Of course, this commit wouldn't have passed the CI pipeline.
2. Fix `Database.php`, so no Exceptions are thrown anymore.

No new Exception is introduced. An existing Exception is only moved a few lines below to throw at the right moment. But I should have commited (and written) the changes in a different order to complement my thought process.

Because commits are squashed on merge, this can stay in this order.

raffaelj → created an issue.

Using external services might actually be an option. Thanks for your input.

Gravity Forms (WordPress plugin)

Using WordPress for forms defeats the purpose of using Drupal in the first place. It looks like Gravity Forms is closed source. And I had a quick look at their demo page and the signup form has basic accessibility issues (label is not associated to input). When they can't do the minimum basics, I don't have any reason to trust their paid services.

Formspree (for HTML forms)

Also closed source. But I like the general idea of using a non-Drupal service for form handling. That other service could even live on the same server and could be written in any programming language. As long as that tool speaks JSON, Drupal could communicate via webhooks or even with calling it directly via eval().

Google Forms (simple and easy)

Google is a privacy nightmare. If I wouldn't care about privacy, I could have used the webform module already.

Typeform (interactive forms)

It's from Spain (Europe), so there is a chance, that they actually take GDPR seriously. But it also seems to be closed source.

So it looks like all your suggestions are closed source. Typeform and Google Forms must be embedded from a third party provider and are probably unusable if JavaScript breaks (or is disabled). I don't understand, why you added Gravity Forms. I got some inspiration from Formspree and Typeform. Besides that, I still think, that basic forms handling (including a form builder) should be part of Drupal core.

I'm shocked, that this issue exists for 10 years. I discovered it recently while forking the contact module → and didn't find the time until now to report it as a security issue with a proper proof of concept. I guess, I can mark this as done now.

Sorry for the rant. To add something productive: In case this issue persists for some more years, I wrote the module disable_libraries → , which can be used to globally disable the core/drupal.form library.

I found the root cause of this edge case bug. All existing modules (even if not installed) where already autoloaded in `core/tests/bootstrap.php`. So it was never possible to throw this Exception during unit tests. I reverted the autoloading of core drivers in the responding test. With that change, also all tests of the driver_test module failed during the class_exists call. With my provided fix all tests pass again.

I'll have another look at the issue fork tomorrow.

raffaelj → created an issue.

raffaelj → created an issue.

@joachim-namyslo:

Wenn du in deinem Modul gendern möchtest. kann ich das auch nicht verhindern. [...] Deswegen wäre es nett, wenn auch du einfach das generische Maskulinum verwendest

OK. Damit kann ich arbeiten. Ich habe noch keine Entscheidung gefällt, ob ich das generische Maskulinum nutzen möchte. Ich habe aber nun ein grobes Verständnis über die technischen und personellen Hürden und den Ist-Zustand zum Thema.

> Deswegen sieht die so alt aus. Einfach weil sie es ist.

Mit veraltet meinte ich, dass der letzte Commit 13 Jahre her ist. Das sieht nicht so aus, als ob da etwas Relevantes für Drupal 10/11 drin wäre.

> Die Repo mit der MKDocks-Version der Richtlinie liegt auf dem Server des Drupal e.V und ist aktuell nicht von außen zugänglich.

Verstehe. Ein öffentliches Repo wäre für ein Open-Source-Projekt natürlich passender...

Hab mittlerweile auch noch anders formulierte Duplikate der Seiten gefunden - hier verlinkt unter "Informationen für Einsteiger:": https://localize.drupal.org/translate/languages/de

Das ist alles sehr verwirrend...

> Eventuell kriegen wir sie aber auf unsere Gitlab-Instanz und können zukünftig GithubPages verwenden, dann wären Merge-Requests möglich.

Meinst du git.drupalcode.org oder gibt es noch eine extra Drupal-e.-V.-Instanz?

Und warum Github Pages bei Gitlab?

Mir würden auch einfach Markdown-Dateien auf git.drupalcode.org ausreichen. Gitlab konvertiert die automatisch zu HTML und die Ordnerstruktur ist das Inhaltsverzeichnis. Keine Build-Steps, keine Duplikate und Issue-Tracker für das Docs-Repo ist inklusive. Außerdem keine Verwirrung mehr, ob ich mich gerade auf `localize.drupal.org` oder auf `localize.drupal.de` befinde.

Ich will ja niemanden verpflichten. Mein Problem ist nur gerade, dass ich meine kürzlich publizierten Module übersetzen und das gerne im ersten Durchlauf allen Richtlinien entsprechend richtig machen möchte.

Wenn ich das jetzt richtig überblickt habe, gibt es nur einen Branch "de-DE-formal". Und es gibt kein Berechtigungssystem auf Modul-Ebene. Das heißt, wenn ich mein Modul auf Deutsch anbieten möchte muss ein Mod meine Übersetzungen durchwinken.

Bei WordPress z. B. habe ich mir Moderator-Rechte für ein von mir erstelltes Plugin geben lassen und kann dort Gendern, wie es mir gefällt. Für alle anderen Plugins muss ein Mod meine Änderungen bestätigen.

Um das abzukürzen: Wenn ich "users" mit "Benutzer*innen" übersetze - wird die Übersetzung angenommen?

Wo ist denn das Repo? Dann kann ich beim nächsten Typo einen Merge-Request schicken.

Das hier scheint ja die Übersetzungen (und nicht die Docs) zu beinhalten (sieht außerdem veraltet aus): https://git.drupalcode.org/project/de

Kamt ihr schon zu einer Einigung zu einem einheitlichen Stil beim Gendern? Ich schaue mich hier gerade um mit dem Ziel, meine Module zu übersetzen. Ich habe ziemlich viele "users"-Strings und generisches Maskulinum fühlt sich falsch an.

Grundsätzlich: Ob "*" oder ":" ist mir persönlich egal - bin aber auch ein weißer, mittelalter Mann. Screen-Reader kommen wohl mittlerweile mit beiden gut klar. "*" scheint bevorzugt, da nicht-binäre Menschen im Schriftbild inkludiert werden. Im Zweifel nehme ich auch generisches Femininum. Inkonsistent gendern ist auch OK.

Eine Grundrichtung wäre aber sinnvoll. So in die Richtung:

- Niemand muss gendern. Sowohl generisches Maskulinum, als auch generisches Femininum sind erlaubt.
- Beim Gendern aber bitte erst neutrale Form versuchen,
- und wenn das nicht passt grundsätzlich "*".

Ein Teil ungegendert und ein Teil mit Sternchen wäre gut verständlich. Ein Teil ungegendert, ein Teil mit Doppelpunkt und ein Teil mit Sternchen hingegen wäre verwirrend.

raffaelj → created an issue.

I decided to create a fork of the core contact module to address my needs: Formable → . It's only a dev release right now, but I'm open for any feedback.

This theme is now released on drupal.org, so these kinds of issues shouldn't happen anymore. I still don't know, how to automate releases, but I got used to the manual process.

comparing commit history of 10.3.x branch with 11.x branch (2024-06-30)

• [x] manual diff \Drupal\Core\Asset\LibraryDiscoveryCollector --> no changes
• [x] manual diff \Drupal\Core\Theme\ThemeInitialization --> no relevant changes (only deprecated code was removed

setup a local Drupal 11 test instance and run tests - This was a pain and took me multiple hours because of: 🐛 PHPUnit 10 behaves differently when invoked outside web root Needs review

mkdir test && cd test
composer create-project drupal/recommended-project:11.0.0-beta1@beta .
composer require --dev drupal/core-dev
composer require drush/drush

mkdir -p web/modules/contrib
git clone https://git.drupalcode.org/project/disable_libraries.git web/modules/contrib/disable_libraries

mkdir -p db
./vendor/bin/drush site:install --yes --db-url="sqlite://../db/test.sqlite"
# save password for later... 725ViHSaE2

./vendor/bin/drush pm:install disable_libraries

cp ./web/core/phpunit.xml.dist ./web/core/phpunit.xml
sed -i -E 's~<env name="SIMPLETEST_DB" value=""/>~<env name="SIMPLETEST_DB" value="sqlite://../../db/kernel-test.sqlite"/>~g' ./web/core/phpunit.xml

sed -i -E 's~"drupal/core": "^10"~"drupal/core": "^10 | ^11"~g' web/modules/contrib/disable_libraries/composer.json
sed -i -E 's~core_version_requirement: ^10~core_version_requirement: ^10 | ^11~g' web/modules/contrib/disable_libraries/composer.json

cd web
../vendor/bin/phpunit -c core/phpunit.xml modules/contrib/disable_libraries/tests/src/Kernel/LibraryDisablerTest.php
../vendor/bin/phpunit -c core/phpunit.xml modules/contrib/disable_libraries/tests/src/Unit/LibraryDisablerTest.php

• [x] unit tests
• [ ] kernel tests

Kernel test passed for some reason when running from host system (sqlite3 v3.39.2), but failed when running from dev docker image (sqlite3 v3.40.1). Both should have failed because v3.45 is required. Because the kernel test doesn't test anything important (yet), this can be ignored.

So this module is compatible with Drupal 11.

Compatibility notice added in 0.1.4 - https://git.drupalcode.org/project/disable_libraries/-/commit/9add8dc78f...

@bnjmnm Thanks for the workaround.

This isn't really a a bug

I would classify it as a bug, because Drupal is highly configurable and the script should check, if the node exists. But because I only noticed it in a fresh test installation, where the "announcements" module wasn't disabled already, I can live without the fix.

Partially overwriting a core jQuery library, that probably gets replaced with a vanilla JS implementation, feels fragile. Also my goal was to reduce bloat and not to add more (JS) libraries.

Now my "fix" is the advice to uninstall the announcements module when using my drinimal base theme. It's good enough for now...

No problem. My current workaround is to use the photoswipe → module, which provides the url formatter and takes care of cache contexts for image sizes. Because I don't want the photoswipe lightbox JS, I disabled it with the disable_libraries → module and replaced it with a different implementation. It's good enough for now...

Maybe I'll write my own url formatter at some time, so I don't have to install (and disable) photoswipe anymore.

My older try, without any other modules, had problems with automatically generating image sizes, with caching and with reliability. This is why I moved to a gallery module instead. For reference - this is where I stopped trying to "fix" this via preprocess function:

/**
 * Convert thumbnail, that links to media edit page to link to image style url instead
 *
 * TODO: image style is not generated automatically, hotfix in settings.php:
 * $config['image.settings']['allow_insecure_derivatives'] = TRUE;
 * @see https://www.drupal.org/forum/support/post-installation/2015-06-16/image-styles-not-generating
 */
function my_theme_preprocess_image_formatter(&$variables) {

  // Login check is not relevant. I thought, it would affect the media library
  // view or the view while editing multi value media/image field in a node
  // if ($variables['logged_in']) return;

  $url = $variables['url'] ?? null;
  if (!$url) return;
  // is not linked to media
  if ('entity.media.canonical' !== $url->getRouteName()) return;

  $fid = $variables['item']->getValue()['target_id'];
  $file = \Drupal\file\Entity\File::load($fid);

  // TODO: get multiple image sizes
  $uri = $file->getFileUri();

  // TODO: use better fitting image style
  // TODO: add check, if style exists
  // TODO: add check, if style is possible on current image
  $style = \Drupal\image\Entity\ImageStyle::load('max_1300x1300');

  $imageStyleUri = $style->buildUrl($uri);

  $newUrl = \Drupal\Core\Url::fromUri($imageStyleUri);

  $variables['url'] = $newUrl;

  // TODO: cache context

}

And because it's not fair to talk in public about people without their knowledge, I informed Rajan about this thread in #3445444-10: Unit/Kernel tests are incompatible with Drupal 11 → .

@rajan-kumar2026: This still doesn't fix anything. You can't just randomly change version numbers and expect to fix incompatibilities between versions.

I'm not in the mood right now to teach you the very basics of composer version constraints, how .info.yml files act as an abstraction for composer usage in Drupal land, how PHP and Drupal work in general and what unit tests are. Please ask your coworkers to give you some basic tutorials.

I assigned myself now to make it clear, that I want to fix this issue myself. But I'm not in a hurry, because there are more than two months left before Drupal 11 will be released.

After properly testing this module for compatibility, it's time to update composer.json and .info.yml with the new version constraint.

Besides that: I don't think it's fair to talk publicly about you without your knowledge. Because of your low quality contributions, I thought you would try to game the system for credit farming. Now I think, that you just want to help, but that Drupal is a bit too complicated for your first steps in open source contributions. See: #3445549: Credit farming of rajan-kumar2026 →

While skimming some more issues I also found a few, that looked valid or where Rajan actually reacted to feedback. When I opened this issue, I was sick and in a bad mood, so I didn't even see good intentions as an option. Now I share @adaperno's and @vishalkadam's conclusion.

I still think, that Rajan's contributions do more harm than good, but I also don't have a better idea for handling such cases other than teaching.

I want to avoid public shaming and it doesn't look like abusive behavior anymore. So... How to move on? Should I change the issue title and summary?

I had a quick look at todays actions. The user continues to post random screenshots and core_version_requirement merge requests without reading the issue. It's not "only" gaming the system. This is harmful spam and a lot of noise in a huge amount of projects.

I also thought again about the very low quality contributions (CSS and PHP) I saw yesterday. It always does something, but never the right thing. My guess: This person is not employed for programming and it smells hard like chatbot usage.

raffaelj → created an issue.

The page should have a section about how to flag/report abusive behavior. Is it the same as reporting spam via site moderator's issue queue?

Like here: https://www.drupal.org/docs/develop/issues/issue-procedures-and-etiquett... →

Background: I have a strong evidence about a user, I want to avoid public shaming and I expected to find some information about how to handle such cases on this page.

@rajan-kumar2026: Well... Thanks for your effort, I guess?

You created a merge request with the automatically generated patch from 📌 Automated Drupal 11 compatibility fixes for disable_libraries Active , which marks this module as compatible with Drupal 11. But this issue is about incompatible unit tests with extracted notes from the linked patch and diff files in that issue.

Before I mark this module as compatible with v11, I have to manually test it and I have to fix at least the two mentioned issues.

I'm sorry, if this sounds rude, but... Are you credit farming? Because you obviously didn't read the issue summary.

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.

See https://www.drupal.org/project/disable_libraries/issues/3445444 📌 Unit tests are incompatible with Drupal 11 Active

raffaelj → created an issue.

I'm sorry, but this is not possible right now and I don't want to implement it.

It would in a first step also help to get a list of all detected external libraries.

I can imagine two ways for this list:

1. Create log while disabling external libraries during initial load (before caching)
2. Parse all modules and active themes on a settings page (after caching)

I'm against 1, because I want to avoid a database write during initialization (for performance). Point 2 would require a lot of work, but could be useful. I have to think about...

It would be great if I could convert fixed CDN use of contrib modules into a local call to a folder where I downloaded the libraries - without having to change the code of the module/theme itself.

I'm against this option for a few reasons:

There are modules already for library management, e. g. Libraries API → or Library Manager → . But I didn't test any of these modules, so I can't tell if they are compatible with this module.

My main motivation for writing this module was to prevent the insane amount of random CSS files or jQuery sneaking into my theme. Globally disabling external libraries is only a safety measure against modules, that enable CDNs by default. If I ever want to manage or replace external libraries, I would first try one of the existing modules. If they don't work, I could write a new module named "replace_libraries", so the "disable_libraries" module won't get bloated.

Besides that, I don't want to fix symptoms. If you use modules, that enable CDNs by default, you should open an issue and explain, why this is bad. Maybe the author just never thought about the privacy and security impacts and is willing to learn. If not, you should ask yourself, if you can trust code from authors, who don't value consent.

For example the PhotoSwipe → module version 4 enables CDNs by default (and disable_libraries disables them). Since version 5.0, it is opt-in, so they appear trustworthy.

The webform → module tells a different story. GDPR and CDN related issues are known for years and I would never recommend using it. But it is the de facto standard form builder module for Drupal and I have to use it until an alternative exists. With disable_libraries I have a safety net during this time frame.

raffaelj → created an issue.

Did you find a solution? I'm stuck at the same point right now.

moved documentation of md2drupal.sh to my snippets repo: https://codeberg.org/raffaelj/drupal-snippets/src/branch/main/md2drupal

moved documentation of md2drupal.sh to my snippets repo: https://codeberg.org/raffaelj/drupal-snippets/src/branch/main/md2drupal

> Changing to 11.x as the current development branch.

What's the recommended way to work with a changed dev branch? Should I merge the 11.x branch into my current issue fork or should I create a new issue fork?

> This may be border if it needs test coverage but the scenario makes me feel it may

OK. I have to learn, how to write JS tests for Drupal first. So this may take a while...

## Notes to myself

### Possible JS test solutions:

* https://www.drupal.org/docs/develop/automated-testing/types-of-tests#s-f... →
* https://www.drupal.org/docs/develop/automated-testing/browser-testing-us... →
* https://www.drupal.org/docs/develop/automated-testing/javascript-testing... →

### Tutorial:

* https://www.drupal.org/docs/automated-testing/phpunit-in-drupal/phpunit-... →

### Test cases

* required modules: "announcements"
* run test as authenticated user
* run test on page, where the current theme is not the admin theme, e. g. `<front>`
* either create click event on "Announcements" button before JS tests or run JS directly
* test default setup with default theme (stable9 or stark should work) --> assert `document.querySelector('[data-off-canvas-main-canvas]') !== null`
* dynamically inject theme, that disables `off_canvas_page_wrapper` via `MY_THEME_element_info_alter`
* test default setup with injected theme --> assert JS error thrown
* test changed behaviour with my fix --> assert `document.querySelector('[data-off-canvas-main-canvas]') === null` && assert no JS error thrown

Maybe I get some attention after discovering the "Needs review" status update feature :-)

Today I finally understood the contribution system and what the heck this "Marketplace" thingy is. Watching the keynote from 2014 helped a lot to get a basic understanding.

and you should also grant yourself credit

This feels weird. I'm the maintainer and the one who has the power to click that "Merge" button. I won't bloat the commit message with my own name.

@ressa: Thanks. I'll merge your changes tomorrow.

And I have no idea, how the credit system works, yet... I assume, that you are credited automatically without me clicking anything...

I digged a bit deeper and wrote a module to disable libraries in general. As a bonus feature it disables the CDN usage of webform, too. Feel free to check it out: https://www.drupal.org/project/disable_libraries/ →

@Anybody Your workaround in #8 re-introduced "No such file or directory in _locale_parse_js_file()" warnings in multilingual setups - see: 🐛 disabling CDN causes php warnings with webform in multilingual setup Fixed . I published a different method in my new disable_libraries module.

raffaelj → created an issue.

I had a quick look using the dev release. Now pressing Enter works as expected and the repair button is much more understandable with the added context. Thanks for the fix.

Nice.

One last recommendation: Make notes. Drupal is very complicated (mostly for good reasons). When you revisit the project in a few weeks or months the weird bugs and Drupalisms won't be obvious anymore.

Now don't forget to check for the correct write permissions after all these tests - https://www.drupal.org/docs/administering-a-drupal-site/security-in-drup... →

And please prepend "[Solved] " to the title of this thread - https://www.drupal.org/docs/administering-a-drupal-site/troubleshooting-... →

composer.json is in the same folder where web or your renamed www folder is. Also run the composer commands from the same folder where your composer.json is. I would recommend to experiment a bit with composer first to get a feeling about the folder structure. Install a fresh drupal, update it, change it and inspect the folder structure. Then use this knowledge to update the existing installation.

You already found the bug with the missing write permission, which is complicated for experienced users, too.

And I would recommend to test the symlink variant, which avoids changing any default folders.

Any other ideas?

I forgot about the installer-paths section.

    "extra": {
        "drupal-scaffold": {
            "locations": {
                "web-root": "www/"
            },
            /* ... */
        },
        "installer-paths": {
            /* change "web/..." to "www/..." */
            "web/core": [
                "type:drupal-core"
            ],
            /* ... */
        },
    },

Not sure, if something breaks when you change this with an existing installation. When you install Drupal with composer create-project --no-install drupal/recommended-project . you can change all the settings in composer.json to match your setup and to e. g. remove unused modules before downloading them. When everything is correct, run composer install --no-dev.

Alternatively you could keep the original folder structure and use symlinks to prevent messing things up. I use one setup on a shared host with:

root folder www or in my case /var/www/virtual/$USER/ (not publicly accessible, but Apache has read/write access)

html/ (DOCUMENT_ROOT, publicly accessible, symlink to drupal-setup/web)
drupal-setup/
            config/
            web/
                index.php
                ...
            tmp/
            vendor/
            composer.json
            update.sh
            ...

On a different shared host I had to use a graphical user interface to point a domain to a folder, but the setup is pretty much the same:

home folder (~)

default-website/ (DOCUMENT_ROOT of example-a.com, publicly accessible)
drupal-setup/
            config/
            web/ (DOCUMENT_ROOT of example-b.com, publicly accessible)
                index.php
                ...
            tmp/
            vendor/
            composer.json
            update.sh
            ...

Can you share (parts of) your composer.json?

Just guessing... if you have "drupal/core-recommended": "10.2.3" in your required section without the ^ character, the version is fixed and won't update. Using "drupal/core-recommended": "^10.2.3" instead will update to versions >=10.2.3, <11.0.0. See also: https://getcomposer.org/doc/articles/versions.md#writing-version-constra...

I do not have a web folder but a www instead. Is that part of the problem?

Maybe... Did you change the scaffold mapping in your composer.json?

    "extra": {
        "drupal-scaffold": {
            "locations": {
                /* original */
                /*"web-root": "web/"*/
                /* change to new location */
                "web-root": "www/"
            },
        },
    }

If not, you probably installed the update into the (not used) web folder.

Yes, but I want to receive updates for scaffolding files. So I use a combination of all methods already. My current composer.json looks like this (comments are added for clarity, JSON files don't allow comments):

{
    /* ... */
    "require": {
        "composer/installers": "^2.0",
        "drupal/core-composer-scaffold": "^10.1",
        "drupal/core-recommended": "^10.2",
        "drush/drush": "^12.4",
        /* ... */
    },
    /* ... */
    "config": {
        "allow-plugins": {
            "composer/installers": true,
            "drupal/core-composer-scaffold": true,
        /* ... */
        },
        /* ... */
    },
    "extra": {
        "drupal-scaffold": {
            "locations": {
                "web-root": "web/"
            },
            "file-mapping": {
                /* disable overwriting dev file */
                "[web-root]/sites/development.services.yml": false,
                /* add content from local file to web/.htaccess after receiving updated scaffolding file */
                "[web-root]/.htaccess": {
                    "append": "patches/htaccess-append-deflate"
                }
            }
        },
    /* ... */
    }
}

The missing piece is the hardening of web/sites/default with the workaround of adding the write permission before updating.

In a comment inside update.sh above is a link to the docs with this workaround:

https://www.drupal.org/docs/develop/using-composer/starting-a-site-using... →

which in turn links to the related issue 🐛 Composer scaffolding fails when permissions on default.settings.yml or default.settings.php is not writable. Needs work

This comes from the core scaffolding files, which are replaced when running updates. I only disabled the overrides for a few files via composer.json.

You have to add the write permission to web/sites/default instead of web/sites/default/files. Than composer is able to write into that folder.

While developing I use $settings['skip_permissions_hardening'] = TRUE; in my web/sites/default/settings.local.php to keep the current write permissions.

For updating I use a small bash script update.sh in the root folder that takes care of the write permission before running composer:

#!/bin/bash

# enable maintenance mode
drush state:set system.maintenance_mode 1 --input-format=integer
drush cache:rebuild

# prevent `Could not delete .../web/sites/default/default.services.yml`
# see https://drupal.stackexchange.com/questions/290296/composer-require-fails-because-it-cant-delete-default-services-yml/290297#290297
# see https://www.drupal.org/docs/develop/using-composer/starting-a-site-using-drupal-composer-project-templates#s-workaround
chmod u+w web/sites/default

# update dependencies
composer update

# re-harden site folder after update
chmod u-w web/sites/default

# run pending updates
drush updatedb --yes

# disable maintenance mode
drush state:set system.maintenance_mode 0 --input-format=integer
drush cache:rebuild

@ressa, @anybody: I agree, that these changes should be part of the webform module, but I don't see this coming:

1. From looking at the history of the issue queue, I deduced that the core maintainer/owner @jrockowitz doesn't see loading third party code (from venture capital backed ad companies) as a problem.
2. Multiple GDPR related issues were closed as "won't fix" or as "works as designed".
3. The config form to opt-out is hidden in a sub tab. While navigating to this page, the third party providers are already contacted. Also that form has bugs, which makes it appear unimportant ( 🐛 Pressing Enter key on config/advanced form causes repair instead of save Active ).
4. Disabling CDN usage broke over and over again in the past (e. g.: #3199336: Tippy 6 is always loaded from the CDN even if there is a local copy, because webform_library_info_alter is not rewriting its directory from the 5 version to the 6 version → , #3254856: CKEditor Codemirror is still loaded from the CDN even if the library exists in /libraries. → , #3316667: Tippy.js is loaded via CDN even when disabled → ).
5. To be honest: I don't care about GDPR. But I care about privacy and consent. Personally I can protect myself by using Firefox addons like uBlock Origin and LocalCDN. When running code on client projects it's another story. Now I have to protect the privacy of my clients and of their website visitors. And my clients have to care about GDPR. Using code from people, who don't value consent means, that I have to be very careful with every update. Otherwise some new code with GDPR violations could sneak in.
6. Disabling CDN usage by default would be a breaking change. It would involve a config change to use included_libraries instead of excluded_libraries and the CDN keys would move from webform.libraries.yml to a preprocess or alter hook.
7. The whole module feels a bit bloated: too much JavaScript, 1346 lines of code in webform.libraries.yml, thousands of files (to be fair, the biggest footprint are the tests folders)

From there I concluded, that it's not worth investing my time in improving this module. It just happens to be the de facto standard form builder module and I have to use it until an alternative exists. Because I can't trust code from developers who don't value consent, I decided to reduce the risks with config overrides via contrib module.

If there was a clear statement from @jrockowitz, that privacy has a high value, I might come back and could help fixing these issues.

After sending a merge request, all tests are passed, but there is one warning I don't understand:

If the last pipeline ran in the fork project, it may be inaccurate. Before merge, we advise running a pipeline in this project. Learn more

I skimmed the linked help page, but it just looks like generic information about how to setup CI pipelines.

Can I ignore it? If not, I need some guidance on how to resolve it.

raffaelj → created an issue.

@ressa convinced me in the forum → to give this module a second try. After finding a few bugs and another GDPR violation ( 🐛 YouTube thumbnails are embedded on help page (performance, low bandwidth, GDPR compliance) Closed: works as designed ), I started to set some sane defaults via contrib module. This module acts as my learning module right now and it is hosted outside of drupal.org, but maybe it's interesting for others how I reduced the risk of GDPR violations.

The module: rljutils

The interesting bits (commits):

• disable CDN usage of webform module
• added config override for webform module to disable ads and third party content
• added fallback CSS for webform if codemirror lib is disabled

More fixes and overrides might follow soon...

Side note: I added the webform module to the list of problematic modules for GDPR compliance: #3075653-26: Drupal modules that may require extra work to be GDPR compliant →

I had another look. This time with an open dev console in my Firefox and many errrors. For some reason the errors are only on the English version, not in the German one.

Uncaught TypeError: drupalSettings.user is undefined
     http://localhost:8080/core/modules/contextual/js/contextual.js?v=10.2.3:23
     http://localhost:8080/core/modules/contextual/js/contextual.js?v=10.2.3:314
contextual.js:23:27
Uncaught TypeError: Drupal.contextual is undefined
     http://localhost:8080/core/modules/contextual/js/models/StateModel.js?v=10.2.3:17
     http://localhost:8080/core/modules/contextual/js/models/StateModel.js?v=10.2.3:130
StateModel.js:17:49
Uncaught TypeError: Drupal.contextual is undefined
     http://localhost:8080/core/modules/contextual/js/views/AuralView.js?v=10.2.3:11
     http://localhost:8080/core/modules/contextual/js/views/AuralView.js?v=10.2.3:59
AuralView.js:11:47
Uncaught TypeError: Drupal.contextual is undefined
     http://localhost:8080/core/modules/contextual/js/views/KeyboardView.js?v=10.2.3:11
     http://localhost:8080/core/modules/contextual/js/views/KeyboardView.js?v=10.2.3:62
KeyboardView.js:11:50
Uncaught TypeError: Drupal.contextual is undefined
     http://localhost:8080/core/modules/contextual/js/views/RegionView.js?v=10.2.3:11
     http://localhost:8080/core/modules/contextual/js/views/RegionView.js?v=10.2.3:75
RegionView.js:11:48
Uncaught TypeError: Drupal.contextual is undefined
     http://localhost:8080/core/modules/contextual/js/views/VisualView.js?v=10.2.3:11
     http://localhost:8080/core/modules/contextual/js/views/VisualView.js?v=10.2.3:109
VisualView.js:11:48
Uncaught TypeError: drupalSettings.path is undefined
     http://localhost:8080/core/modules/toolbar/js/toolbar.menu.js?v=10.2.3:15
     http://localhost:8080/core/modules/toolbar/js/toolbar.menu.js?v=10.2.3:256
toolbar.menu.js:15:31
Uncaught TypeError: pathInfo is undefined
     http://localhost:8080/core/modules/toolbar/js/escapeAdmin.js?v=10.2.3:16
     http://localhost:8080/core/modules/toolbar/js/escapeAdmin.js?v=10.2.3:45
escapeAdmin.js:16:5
Unknown property ‘enable-background’.  Declaration dropped. advanced:1:19
Unknown property ‘-moz-osx-font-smoothing’.  Declaration dropped. advanced:1:3006
Uncaught TypeError: path is undefined
    attach http://localhost:8080/core/misc/active-link.js?v=10.2.3:25
    attachBehaviors http://localhost:8080/core/misc/drupal.js?v=10.2.3:166
    attachBehaviors http://localhost:8080/core/misc/drupal.js?v=10.2.3:162
     http://localhost:8080/core/misc/drupal.init.js?v=10.2.3:32
    listener http://localhost:8080/core/misc/drupal.init.js?v=10.2.3:20
    domReady http://localhost:8080/core/misc/drupal.init.js?v=10.2.3:26
     http://localhost:8080/core/misc/drupal.init.js?v=10.2.3:31
     http://localhost:8080/core/misc/drupal.init.js?v=10.2.3:34
active-link.js:25:42
Uncaught SyntaxError: "" string literal contains an unescaped line break advanced:1:88

Some broken HTML markup caused all the contextual errors.

web/modules/contrib/webform/src/Form/AdminConfig/WebformAdminConfigAdvancedForm.php

Line 103 (unclosed "a" tag):

- 'This behavior is disabled when the <a href=":href">Tippy.js library is disabled</a.'
+ 'This behavior is disabled when the <a href=":href">Tippy.js library is disabled</a>'

Of course now the German translation is missing, because it was translated from the broken markup, but with correct closing tag. Now also all the fancy options aren't displayed italic anymore. Nice.

Now I'm left with

Uncaught SyntaxError: "" string literal contains an unescaped line break advanced:1:88

in the English and the German version.

web/modules/contrib/webform/src/Form/AdminConfig/WebformAdminConfigAdvancedForm.php

Line 319:

- . PHP_EOL
+ . '\r\n'

Now both, the English and the German page ask for confirmation (with line break). Pressing the Enter key triggers that confirmation message.

This only fixes the broken HTML. Triggering the confirm alert prevents damage, but is completely out of context. The actual issue should be resolved by moving the repair step into a different form.

This also shows why relying purely on JavaScript isn't the best idea. It can break and than native HTML should do the job.

Side note: This broken code is just another example why enabling all JS libraries by default is a bad idea and enabling CDN usage by default is an even worse idea.

Today this problem happened to me as well.

Setup: Drupal 10.2.3
Languages: de, en
Default language: de
Urls have language code prefixes, e. g. /en/admin/structure/types/manage/issue
Initial installation via drush (Drupal 10.1.?):

drush site:install --yes --db-url="..." --locale="de" --site-name="..." --config-dir="..." --site-mail="..." --account-mail="..." --account-name="..."

I created the content type with the /en/... route and tried to translate the body afterwards. I also created a field with the /en/... route and tried to translate that afterwards.

Both variants resulted in the mentioned error message: "The configuration objects have different language codes so they cannot be translated".

Deleting the new content type and the new field and recreating them with the /de/... route worked.

Now I know, that I must configure such things in the default language. But I actually like using the user interface in German to know how it looks to clients, but always configure in English to get untranslated error messages, that can be copied into a search engine.

The webform module has CDNs enabled by default to load multiple JavaScript libraries. Disabling CDN usage in general is not possible without a custom module. Installing libraries locally disables the CDN usage, but if a future update adds a new CDN based library, there is a risk, that it will be loaded from a CDN by accident. Possibly anonymous users and registered users are affected.

It also loads many YouTube thumbnails on it's help page by default. Disabling is possible, but hidden in sub tab "Advanced" under the "Config" tab. It doesn't affect anonymous users, but registered users.

While trying to opt-out on the config pages, data from third party providers is already loaded. So configuring via drush config:set or via settings.php is necessary before opening any webform route after a fresh installation.

So both violations are opt-out instead of opt-in. Opting out is hidden in nested config pages and/or need workarounds with custom modules and config overrides to reduce the risk of exposing personal data from anonymous and registered users.

GDPR related issues were closed as "won't fix" or as "works as designed" in the past, e. g. 🐛 YouTube thumbnails are embedded on help page (performance, low bandwidth, GDPR compliance) Closed: works as designed and 📌 Allow to disable (dynamic) CDN loading of libraries in general Active . So it doesn't look like the author is interested in GDPR compliance. After skimming more issues, it looks like there actually was some work already to improve GDPR compliance in certain cases. But partially compliant equals to not compliant in this case.

Privacy invasive settings should be opt-in instead of opt-out.

And as mentioned above, the help text makes no sense anymore.

removed a line break in initial post that caused ugly markup

raffaelj → created an issue.

Workaround:

set "Video display" to "hidden" in "Advanced" sub tab under "Configuration" tab (admin/structure/webform/config/advanced). Now the lines "This screencast..." without the "Watch video" button below don't make any sense anymore, but at least the third party content is gone.

Setting "Video display" to "link" still loads all YT thumbnails and the "Watch video" button is a link now, that opens the YT video on the same page.

To make sure, that nobody enables it again in the future, a config override in settings.php helps:

$config['webform.settings'] = [
  'ui' => [
    // prevent loading YT thumbs on help tab
    'video_display' => 'hidden',
  ],
];

raffaelj → created an issue.

Thanks for clarifying in the docs.

If you use the order of elements as a guide, since Composer is mentioned first, before CDN -- my take would be that Composer was recommended over CDN.

This still doesn't solve the problem, that composer is a bad choice for managing JS libs. If I go that route, I'll probably try to add some logic to my update.sh, which already takes care of fixing write permissions before running composer update or running drush updatedb --yes and drush cache:rebuild afterwards. This way I could use npm for JS lib version management or delete all unneded files after downloading repositories.

changed id "summary-resolution-discovery" (duplicate) to "summary-resolution-onboarding"

I thought there was a another issue besides #2857160: Allow POST via RestWS API → however it was the only one I could find on my quick search as well.

Maybe #3227737: [Meta] GitLab Acceleration Initiative → and #3143620: DrupalSpoons bot → ?

Today I found some existing REST API functionality: https://www.drupal.org/drupalorg/docs/apis/rest-and-other-apis →

Only read access is allowed.

So the docs and #2857160: Allow POST via RestWS API → say, that It's read-only. But even if write access was enabled, this wouldn't solve the password management problem (no access token support).

But the api is really interesting for debugging and to get a better understanding of the internal field structure.

Side note: Both api endpoints for a project page contain user ids in the flag_project_star_user field, which should be hidden for privacy reasons:

https://www.drupal.org/api-d7/node/3419729.json →
https://www.drupal.org/api-d7/node.json?field_project_machine_name=theme... →

Thanks. Your tip with the BUEditor pointed me in the right direction. The route of all evil is the codefilter module → or rather it's prism submodule, which changes the behaviour of the native <code> html element.

to drive discussion of change to features on drupal.org , you'd generate an issue.

Sure. But I needed a conversion script before opening an issue to be able to convert private notes in markdown to something that is compatible with drupal.org.

Now I'm not sure, if this issue belongs to the codefilter module or to the infrastructure issue queue... I have a feeling, that restoring native HTML functionality is a breaking change with millions of existing posts and issues, that have wrong markup.

raffaelj → created an issue.

raffaelj → created an issue.

Unlike the other services, we do not allow deleting or replacing releases, so you know you will be able to deploy the same code indefinitely.

Just tested it with git push origin :0.1.2 and broke my complete git access. No git push or git clone to any repo was possible anymore. Logging in and accepting the ToS fixed the broken git access. The error message could have been a bit more elaborative.

git push origin :0.1.2
remote:
remote: ========================================================================
remote:
remote: You (@raffaelj) must accept the Terms of Service in order to perform this action. To accept these terms, please access GitLab from a web browser at https://git.drupalcode.org.
remote:
remote: ========================================================================
remote:
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

Good to know.

We do get occasional support requests for deleting accidental releases, which we do not allow. If everything were more automated, I expect there would be more accidental releases.

I get the point. But configuring the webhook is a decision (with somewhat advanced knowledge) to care about git tags and to automate the release process. With some fine tuning, only tags with version strings on branches with version strings could be released automatically.

It doesn't have to be fully automated. Running two different commands would be fine too. Any alternative, that doesn't require logging in and filling out a form (without markdown support and with non-conformant html support) would be great.

git push origin 0.1.3
./deploy.sh
# either with OS key ring integration or
# with manually entering password e. g. via auto type feature from KeePassXC

Besides calling a curl command to trigger a new release, deploy.sh could also contain some logic to parse CHANGELOG.md with the help of md2drupal.sh → . .gitattributes takes care about removing that file from packages/releases.

I use the technique above for a WordPress plugin I maintain to convert git tags to SVN branches.

added link to missing notes section, that was mentioned in the initial post

converted markdown lists in initial post to html lists for better readability

About using CDN's, it is actually recommended to NOT use them on several Drupal documentation pages [...] Please correct it, where you found the opposite recommendation for CDN's, or supply a link here.

I was a bit suprised and glad to read this and I wondered, where I read it in the first place a few months ago... Now I found a reference:

Bundling or duplicating third party libraries into Drupal.org repositories is strongly discouraged – see Policy on 3rd party assets on Drupal.org → for clarification of policy.

Instead, you should include third party libraries through either Composer, by using a CDN (Content Delivery Network), or by using the Libraries API module.

https://www.drupal.org/docs/develop/git/setting-up-git-for-drupal/drupal... →

I think, I read about it while doing research about MIT and SIL Open Font License compatibility with GPL-2.0-or-later. Bundling JS libraries with a theme or a module is a licensing problem.

Composer is not designed to work well with JS libs. It's a php package manager. All variants I found are workarounds. Maintenance and version management becomes more complicated and/or complete git repositories are downloaded into web/libraries.

Somehow I overlooked the Libraries API module - probably because I confused it with the module.libraries.yml api. Or maybe I skipped it as an option, because it doesn't provide an automated workflow for version management of JS libs.

So it is not recommended to use CDNs. But I understand discouraging bundling of JS libs as an implicit recommendation to provide and use CDN based solutions by default.

About Webform being bloated ... Well, this is open source, and no one is stopping you from creating a few MRs, and start slimming it down :)

A fresh installation comes with 17,1 MiB, 2.187 files, 672 sub-folders. Using the variant with wikimedia/composer-merge-plugin added another 29MB of JS folders (tested 2023-09, numbers may differ today). webform.libraries.yml has 1346 lines of code with 13 CDN based libraries. With each new update I must be afraid that some random new library will be added, that isn't installed downloaded already via composer or Library API - and is now loaded via CDN.

Good luck slimming this down.

To be able to communicate with users on drupal.org without headaches I wrote a markdown to drupal conversion script.

input.md:

# Issue title

I found a bug.

* list
  * with nested list

[link text_with_underscores should not become emphasis]()

```
code with default highlighting
```

```text
code with text highlighting
```

```js
code with js highlighting
```

```html
code with html highlighting
```

It’s a multi step process:

1. Basic markdown conversion
2. prevent double encoding of code blocks and inline code
3. fix syntax highlighting for JS

Basic markdown conversion

• -task_lists - Drupal doesn’t support <input type="checkbox" />
• -auto_identifiers - prevent headline ids <h2 id="markdown">Markdown</h2>
• --no-highlight - prevent converting code to <span> elements
• --wrap=none - Drupal doesn’t support \n inside <a> tags

pandoc -r markdown-task_lists-auto_identifiers --no-highlight --wrap=none -w html input.md > output.html

prevent double encoding of code blocks and inline code

For some reason Drupal changed the behavior of the native html element <code> to something weird with syntax highlighting. To restore the native behaviour, it must be converted to <code class="language-php">. Disabling syntax highlighting is not possible (or gets overwritten when switching between plain text and rich text editor).

# <pre class="html"><code> --> <pre><code class="language-html language-php">
sed -E 's/<pre class="([a-z]+)"><code>/<pre><code class="language-\1 language-php">/g' output.html > output2.html

# <code> --> <code class="language-php">
sed -E 's/<code>/<code class="language-php">/g' output2.html > output3.html

fix syntax highlighting for JS

sed -E 's/<code class="language-js/<code class="language-javascript/g' > final.html

As a one liner:

pandoc -r markdown-task_lists-auto_identifiers --no-highlight --wrap=none -w html input.md | sed -E 's/<pre class="([a-z]+)"><code>/<pre><code class="language-\1 language-php">/g' | sed -E 's/<code>/<code class="language-php">/g' | sed -E 's/<code class="language-js/<code class="language-javascript/g' > output.html

As a build command for kate editor:

pandoc -r markdown-task_lists-auto_identifiers --no-highlight --wrap=none -w html "%f" | sed -E 's/<pre class="([a-z]+)"><code>/<pre><code class="language-\1 language-php">/g' | sed -E 's/<code>/<code class="language-php">/g' | sed -E 's/<code class="language-js/<code class="language-javascript/g' > "%n".html

As a bash script named md2drupal.sh:

#!/bin/bash

# usage: ./md2drupal.sh input.md > output.html

pandoc -r markdown-task_lists-auto_identifiers --no-highlight --wrap=none -w html "$1" | sed -E 's/<pre class="([a-z]+)"><code>/<pre><code class="language-\1 language-php">/g' | sed -E 's/<code>/<code class="language-php">/g' | sed -E 's/<code class="language-js/<code class="language-javascript/g'

Now the content of output.html can be copied into a plain text editor field of Drupal. Issues don’t have a rich text editor option, so plain text is the default. For forum posts click on “Switch to plain text editor” below the text field, then copy the code.

Checking the preview before saving a post looks good for forum posts. Issue post previews have a CSS bug with ul {padding:0;list-style:none}, so it looks broken. The actual saved post has the right markup and is displayed with the correct CSS.

The text above was generated from a markdown file.

Generated output from input.md:

Issue title

I found a bug.

• list
  • with nested list

link text_with_underscores should not become emphasis

code with default highlighting

code with text highlighting

code with js highlighting

code with html highlighting

It looks like lists actually work, but the CSS for unordered lists in the issue preview is broken.

• test
• test
• test

Thanks for the hint, but I'm talking about the forum we are using right now.

raffaelj → created an issue.

raffaelj → created an issue.

Sorry, but there is not much I can do about that.

This happens when the http server of the git host is down due to maintenance or denial of service. If composer fails to download from https://codeberg.org/raffaelj/drupal-theme-drinimal.git, it falls back to using git with git@codeberg.org:raffaelj/drupal-theme-drinimal.git. In that case you would need an account on codeberg.org and either login with username and password or skip that step with a SSH key.

So normally - in case of a short maintance downtime - try it again after a few minutes.

If it doesn't fix itself, check the Codeberg status page or their Mastodon account to see if they are hit by a DDoS or if there is a planned downtime.

The real fix might be to move the repository from codeberg.org to git.drupalcode.org. But I still don't know, how to automate the release process.

I didn't look through the whole list yet, but devel and webprofiler are definitely game changers.

@joseph.olstad Yeah, I also hope that this is just a forgotten issue and drupal.org runs on modern systems. This issue being open just leaves too much room for speculation...

Just to be sure - is this the module that powers everything on https://www.drupal.org/project/*?

And if so, does this mean, that drupal.org still runs on PHP 5.6, which reached EOL on 2018-12-31?

Initially I was testing and digging how to automate a module release. Than I noticed, that the project module needs v7 and that drupal.org still runs with v7. Now I'm a little bit concerned about security issues...

Thanks. This sounds interesting. For hiding regions or blocks based on conditions I would have used twig templates of preprocess functions. Good to know, that there are other options.

Can you eleborate on use cases for the context module? I read the project description multiple times and I don't get it. It looks like the visibility rules of blocks. Is it maybe obsolete in current Drupal versions?

Some people may need some XML sitemap module but I prefer manual crawling requests in Google Search Console over relying on a sitemap but if you have more than 100 webpages yeah in many cases a sitemap is nice and can help.

Sure, it depends on the size of your site. But it's also useful for automated and manual tests. I have a script that runs a lighthouse test on all pages listed in the sitemap so I can fix errors on localhost before publishing. But I'm actually rethinking how useful a XML sitemap is. To match WCAG AA and AAA, a site map should be provided. To avoid duplication, a HTML sitemap might be the better choice.

Some people may need some meta tags module but in many cases I think a good <H1> tag and a good opener passage and a good URL alias are enough. I think metatags are to some extent a thing of the past with all the artificial intelligence anlysis of webpages from search engines nowadays.

I agree on using semantic markup and text written for humans instead of duplicating content in <meta> tags. But I strongly disagree on the "AI" part. Google and Bing are eating themselve by subsidizing expensive and energy hungry chat bots, that are heavily used for polluting the internet with SEO spam and misinformation. Providing machine readable markup and meta tags helps curating the web with alternative software.

The link to Advanced CSS/JS Aggregation → is broken. You wrote dgo.ti instead of dgo.to.

Also it looks like advagg is mostly obsolete (and partially incompatible) since Drupal 10.1.0 - see: 📌 Document which parts of the module are still relevant after aggregation changes in 10.1.0 Needs review

I played a bit with test projects - and again documented all quirks and confusing settings. My current conclusion: Releasing on drupal.org needs too much manual work.

Initial test in a sandboxed project with some notes in `README.md`: https://git.drupalcode.org/sandbox/raffaelj-3419542

Second test as full project with many notes in `README.md`: https://git.drupalcode.org/project/theme_test_not_sandboxed

Anyways - I reserved the project name, so nobody can grab "drinimal" before I finish the first release.

The docs of the sandbox feature are a bit confusing and it feels wrong to pollute the drupal.org registry with a test theme and a planned theme. But I guess, it's good enough for now. When I find some more time during the next weeks I'll open a few issues with my findings.

raffaelj → created an issue.

I don't know if "too much" got removed for others to use your Drinimal theme ... maybe some parts or components were removed, because you didn't need them, but others might expect them to be there?

Maybe I removed too much, maybe some core markup is just some D7 legacy code and maybe the current twig architecture doesn't match the modularity enough to inject markup only if needed... I'll use it as a base for future projects and try to investigate if it breaks something.

But if it could be usable for a wider audience, you might even consider sharing it under Drinimal → , which is available

I already thought about publishing it on drupal.org and I checked if the name is available before deciding about the final name "drinimal". I also spent hours on reading about GPL and how licensing works in the Drupal eco system. So it should be ready to be published in the official repository.

But:

• The theme still has some opinionated changes (e. g. the language switcher), that should be moved to a module.
• Drupal issues don't have markdown support.
• I don't fully understand how the patch and contribution system works. I'm more familiar with the "Merge Request" (or in Github slang "Pull Request") workflow, with the @mention system and with automatic linking of git commit messages and the issue tracker.

For now I'm happy with a simple composer require "raffaelj/drupal-theme-drinimal:@dev" (It is published on packagist.org). After testing it for a few more weeks, doing some more cleanup and setting an initial version to 0.1.0 I'll think again about publishing it on drupal.org.

@ressa Thanks again for your help. You were interested in the resulting HTML and I finished moving to Drupal a few days ago. The old site is offline now, so a comparison isn't possible anymore. But I documented and published nearly everything I've changed.

Current website: https://www.rlj.me/en

Source code of

• minimal base theme: https://codeberg.org/raffaelj/drupal-theme-drinimal
• active theme: https://codeberg.org/raffaelj/drupal-theme-rljdotme
• module for opinionated modifications: https://codeberg.org/raffaelj/drupal-rljutils

@Kent8 From your description it is impossible to guess, if it has anything to do with this issue. So you should solve that one first (and maybe open a new issue for this case) to be able to read the missing error message.

Uncaught TypeError: Cannot read properties of null

This means that no <div data-drupal-messages> and no <div data-drupal-messages-fallback> exists. Besides that core/misc/message.js should check for the existence of the fallback this could be because (just guessing):

• Your theme or a module disabled these message placeholders (like I did in a minimal base theme)
• You disabled "Primary admin actions" or "status messages" in your block layout

I can also confirm that patch #39 solves the issue.

In my case I experienced redirects for aggregated CSS an JS files from `/sites/default/files/css/css_{hash}` to `/de/sites/default/files/css/css_{hash}` with a 301 status code after rebuilding the cache on a multilingual site - only on front page, that is redirected from `/` to `/{lang}`.

Because I don't want to wait (and 301s are browser cached), I added the code from #39 to a custom module and use it in production now. Thanks @jhuhta.

Thanks @alexpott - You saved my day.

After adding your change to \Drupal\editor\Entity\Editor::calculateDependencies() (and adding a missing ")") I was able to debug my test setup:

[notice] Update started: ckeditor5_post_update_list_multiblock
>  [error]  The editor "webform_default" has the filter format "webform_default" but the filter format does not exist 
>  [error]  Update failed: ckeditor5_post_update_list_multiblock 
 [error]  Update aborted by: ckeditor5_post_update_list_multiblock 
 [error]  Finished performing updates. 

So it was an editor format from an uninstalled module, that I tested a while ago.

After running drush config:delete editor.editor.webform_default I was able to run drush updatedb without errors.