Alles klar. Danke, dass ziehen wir gerade.
joachim namyslo → created an issue.
joachim namyslo → created an issue. See original summary → .
joachim namyslo → created an issue.
joachim namyslo → created an issue.
I know. I do not have a clue how to prove it. Suppose someone comes across this and has some Ubuntu/Debian server where Drupal Cms is running and automatic updates are enabled. Tell me if you got the same error when automatic updates is enabled. I posted that issue in case it doesn't happen exclusively when I set up a server.
So that Drupal CMS and automatic updates could be used on Ubuntu and Debian, too. So maybe someone tries to set up Drupal CMS on Ubuntu 22.04 with Drupal Core 11.6 and composer in /usr/local/bin.
I turned the module off for now, but maybe it's not just me getting this.
So I tried everything now. Even switching the whole server from Ubuntu 22.04 to Debian bookworm 12. And the error persists. So it is very unlikely that 3 different systems are all misconfigured. So what can I do to get automatic update to find Composer. That's very seldom
hm, I did that and it seems to me that everyting looks fine when I execute that via ssh only.
That is the reason why I reopened the Issue. I have no intention of annoying anyone with this, I would much rather know why the error message regarding the readiness test simply cannot be eliminated.
Because when you execute that via ssh everyting is fine. But when I try to re run redyness checks via the status report page link drupal is telling me that there is an error.
I updated the site with composer so now it is Drupal 11.16 with all latest module versions. But the rediness check still fails and the message simply does not give me any indication as to which requirement is not met so that the readiness check can pass again without errors. To be honest, I am a little at a loss.
In the meantime, I have also moved the page from the WSL to a normal web server with Ubuntu 24.04.2 LTS, PHP 8.3.20 (cli) (built: Apr 10 2025 21:33:50) and Mysql Ver 15.1 Distrib 10.11.11-MariaDB. The error message appears there as well.
That is the reason why I reopened that issue. Here is the output from the command mentioned in #9
🕙[ 21:46:36 ] onUbuntu ➜ /usr/bin/composer validate --check-lock --no-check-publish --with-dependencies --no-ansi --working-dir=/var/www/cms
./composer.json is valid, but with a few warnings
See https://getcomposer.org/doc/04-schema.md for details on the schema
# General warnings
- The version field is present, it is recommended to leave it out if the package is published on Packagist.
- require.drupal/project_browser : unbound version constraints (@beta) should be avoided
- require.drupal/webform : unbound version constraints (@beta) should be avoided
asm89/stack-cors is valid
carbonphp/carbon-doctrine-types is valid
chi-teck/drupal-code-generator is valid
clue/stream-filter is valid
commerceguys/addressing is valid
composer/installers is valid
composer/semver is valid
composer/spdx-licenses is valid
consolidation/annotated-command is valid
consolidation/config is valid
consolidation/filter-via-dot-access-data is valid
consolidation/log is valid
consolidation/output-formatters is valid
consolidation/robo is valid
consolidation/site-alias is valid
consolidation/site-process is valid
davedevelopment/stiphle is valid
dflydev/dot-access-data is valid
doctrine/annotations is valid
doctrine/collections is valid
doctrine/deprecations is valid
doctrine/inflector is valid
doctrine/lexer is valid
dragonmantank/cron-expression is valid
drupal/add_content_by_bundle is valid
drupal/address is valid
drupal/addtocal_augment is valid
drupal/ai is valid, but with a few warnings
# General warnings
- No license specified, it is recommended to do so. For closed-source software you may use "proprietary" as license.
drupal/ai_agents is valid
drupal/ai_image_alt_text is valid
drupal/ai_provider_anthropic is valid, but with a few warnings
# General warnings
- require.wpai-inc/anthropic-sdk-php : unbound version constraints (>=0.1.0) should be avoided
drupal/ai_provider_openai is valid, but with a few warnings
# General warnings
- require.openai-php/client : unbound version constraints (>=v0.10.1) should be avoided
drupal/attribution is valid, but with a few warnings
# General warnings
- License "GPL-2-or-later" is not a valid SPDX license identifier, see https://spdx.org/licenses/ if you use an open license.
If the software is closed-source, you may use "proprietary" as license.
drupal/autocomplete_deluxe is valid
drupal/automatic_updates is valid
drupal/autosave_form is valid
drupal/better_exposed_filters is valid
drupal/book is valid
drupal/bpmn_io is valid
drupal/captcha is valid
drupal/checklistapi is valid
drupal/coffee is valid
drupal/content_planner is valid, but with a few warnings
# General warnings
- License "GPL-2.0+" is a deprecated SPDX license identifier, use "GPL-2.0-or-later" instead
drupal/core is valid
drupal/core-composer-scaffold is valid
drupal/core-project-message is valid
drupal/crop is valid
drupal/ctools is valid
drupal/custom_book_block is valid
drupal/dashboard is valid
drupal/drupal_cms_accessibility_tools is valid, but with a few warnings
# General warnings
- The version field is present, it is recommended to leave it out if the package is published on Packagist.
- require.drupal/core : unbound version constraints (>=10.3) should be avoided
drupal/drupal_cms_admin_ui is valid, but with a few warnings
# General warnings
- The version field is present, it is recommended to leave it out if the package is published on Packagist.
- require.drupal/core : unbound version constraints (>=10.3) should be avoided
drupal/drupal_cms_ai is valid, but with a few warnings
# General warnings
- The version field is present, it is recommended to leave it out if the package is published on Packagist.
- require.drupal/core : unbound version constraints (>=10.4) should be avoided
drupal/drupal_cms_anti_spam is valid, but with a few warnings
# General warnings
- The version field is present, it is recommended to leave it out if the package is published on Packagist.
- require.drupal/core : unbound version constraints (>=10.4) should be avoided
drupal/drupal_cms_authentication is valid, but with a few warnings
# General warnings
- The version field is present, it is recommended to leave it out if the package is published on Packagist.
- require.drupal/core : unbound version constraints (>=10.3) should be avoided
drupal/drupal_cms_blog is valid, but with a few warnings
# General warnings
- The version field is present, it is recommended to leave it out if the package is published on Packagist.
- require.drupal/core : unbound version constraints (>=10.4) should be avoided
drupal/drupal_cms_case_study is valid, but with a few warnings
# General warnings
- The version field is present, it is recommended to leave it out if the package is published on Packagist.
- require.drupal/core : unbound version constraints (>=10.4) should be avoided
drupal/drupal_cms_content_type_base is valid, but with a few warnings
# General warnings
- The version field is present, it is recommended to leave it out if the package is published on Packagist.
- require.drupal/core : unbound version constraints (>=10.4) should be avoided
drupal/drupal_cms_events is valid, but with a few warnings
# General warnings
- The version field is present, it is recommended to leave it out if the package is published on Packagist.
- require.drupal/core : unbound version constraints (>=10.4) should be avoided
drupal/drupal_cms_forms is valid, but with a few warnings
# General warnings
- The version field is present, it is recommended to leave it out if the package is published on Packagist.
- require.drupal/core : unbound version constraints (>=10.4) should be avoided
drupal/drupal_cms_google_analytics is valid, but with a few warnings
# General warnings
- No license specified, it is recommended to do so. For closed-source software you may use "proprietary" as license.
- The version field is present, it is recommended to leave it out if the package is published on Packagist.
- require.drupal/core : unbound version constraints (>=10.4) should be avoided
drupal/drupal_cms_image is valid, but with a few warnings
# General warnings
- The version field is present, it is recommended to leave it out if the package is published on Packagist.
- require.drupal/core : unbound version constraints (>=10.4) should be avoided
drupal/drupal_cms_news is valid, but with a few warnings
# General warnings
- The version field is present, it is recommended to leave it out if the package is published on Packagist.
- require.drupal/core : unbound version constraints (>=10.4) should be avoided
drupal/drupal_cms_olivero is valid, but with a few warnings
# General warnings
- The version field is present, it is recommended to leave it out if the package is published on Packagist.
drupal/drupal_cms_page is valid, but with a few warnings
# General warnings
- The version field is present, it is recommended to leave it out if the package is published on Packagist.
- require.drupal/core : unbound version constraints (>=10.4) should be avoided
drupal/drupal_cms_person is valid, but with a few warnings
# General warnings
- The version field is present, it is recommended to leave it out if the package is published on Packagist.
- require.drupal/core : unbound version constraints (>=10.4) should be avoided
drupal/drupal_cms_privacy_basic is valid, but with a few warnings
# General warnings
- The version field is present, it is recommended to leave it out if the package is published on Packagist.
- require.drupal/core : unbound version constraints (>=10.4) should be avoided
drupal/drupal_cms_project is valid, but with a few warnings
# General warnings
- The version field is present, it is recommended to leave it out if the package is published on Packagist.
- require.drupal/core : unbound version constraints (>=10.4) should be avoided
drupal/drupal_cms_remote_video is valid, but with a few warnings
# General warnings
- The version field is present, it is recommended to leave it out if the package is published on Packagist.
- require.drupal/core : unbound version constraints (>=10.4) should be avoided
drupal/drupal_cms_search is valid, but with a few warnings
# General warnings
- The version field is present, it is recommended to leave it out if the package is published on Packagist.
- require.drupal/core : unbound version constraints (>=10.4) should be avoided
drupal/drupal_cms_seo_basic is valid, but with a few warnings
# General warnings
- The version field is present, it is recommended to leave it out if the package is published on Packagist.
- require.drupal/core : unbound version constraints (>=10.4) should be avoided
drupal/drupal_cms_seo_tools is valid, but with a few warnings
# General warnings
- The version field is present, it is recommended to leave it out if the package is published on Packagist.
- require.drupal/core : unbound version constraints (>=10.4) should be avoided
drupal/drupal_cms_starter is valid, but with a few warnings
# General warnings
- The version field is present, it is recommended to leave it out if the package is published on Packagist.
- require.drupal/core : unbound version constraints (>=10.4) should be avoided
drupal/easy_breadcrumb is valid
drupal/easy_email is valid
drupal/easy_email_express is valid, but with a few warnings
# General warnings
- License "GPL-2.0+" is a deprecated SPDX license identifier, use "GPL-2.0-or-later" instead
drupal/easy_email_standard is valid, but with a few warnings
# General warnings
- License "GPL-2.0+" is a deprecated SPDX license identifier, use "GPL-2.0-or-later" instead
drupal/easy_email_text_format is valid, but with a few warnings
# General warnings
- License "GPL-2.0+" is a deprecated SPDX license identifier, use "GPL-2.0-or-later" instead
drupal/easy_email_types_core is valid, but with a few warnings
# General warnings
- License "GPL-2.0+" is a deprecated SPDX license identifier, use "GPL-2.0-or-later" instead
drupal/easy_email_types_default is valid, but with a few warnings
# General warnings
- License "GPL-2.0+" is a deprecated SPDX license identifier, use "GPL-2.0-or-later" instead
drupal/eca is valid
drupal/editoria11y is valid
drupal/estimated_read_time is valid
drupal/field_group is valid
drupal/filter_perms is valid, but with a few warnings
# General warnings
- License "GPL-2.0+" is a deprecated SPDX license identifier, use "GPL-2.0-or-later" instead
drupal/focal_point is valid
drupal/friendly_captcha_challenge is valid
drupal/friendlycaptcha is valid, but with a few warnings
# General warnings
- License "GPL-2.0+" is a deprecated SPDX license identifier, use "GPL-2.0-or-later" instead
- require.drupal/captcha : unbound version constraints (>=1 || <=2) should be avoided
drupal/geocoder is valid
drupal/geofield is valid, but with a few warnings
# General warnings
- License "GPL-2.0+" is a deprecated SPDX license identifier, use "GPL-2.0-or-later" instead
drupal/gin is valid
drupal/gin_login is valid, but with a few warnings
# General warnings
- License "GPL-2.0+" is a deprecated SPDX license identifier, use "GPL-2.0-or-later" instead
drupal/gin_toolbar is valid, but with a few warnings
# General warnings
- License "GPL-2.0+" is a deprecated SPDX license identifier, use "GPL-2.0-or-later" instead
drupal/google_tag is valid
drupal/honeypot is valid
drupal/jquery_ui_autocomplete is valid, but with a few warnings
# General warnings
- No license specified, it is recommended to do so. For closed-source software you may use "proprietary" as license.
drupal/jquery_ui_button is valid, but with a few warnings
# General warnings
- No license specified, it is recommended to do so. For closed-source software you may use "proprietary" as license.
drupal/jquery_ui_checkboxradio is valid, but with a few warnings
# General warnings
- No license specified, it is recommended to do so. For closed-source software you may use "proprietary" as license.
drupal/jquery_ui_controlgroup is valid, but with a few warnings
# General warnings
- No license specified, it is recommended to do so. For closed-source software you may use "proprietary" as license.
drupal/jquery_ui_datepicker is valid, but with a few warnings
# General warnings
- No license specified, it is recommended to do so. For closed-source software you may use "proprietary" as license.
drupal/jquery_ui_menu is valid, but with a few warnings
# General warnings
- No license specified, it is recommended to do so. For closed-source software you may use "proprietary" as license.
drupal/jquery_ui_resizable is valid, but with a few warnings
# General warnings
- No license specified, it is recommended to do so. For closed-source software you may use "proprietary" as license.
drupal/key is valid
drupal/klaro is valid, but with a few warnings
# General warnings
- No license specified, it is recommended to do so. For closed-source software you may use "proprietary" as license.
drupal/klaro_js is valid
drupal/leaflet is valid, but with a few warnings
# General warnings
- License "GPL-2.0+" is a deprecated SPDX license identifier, use "GPL-2.0-or-later" instead
drupal/linkit is valid
drupal/login_emailusername is valid
drupal/mailsystem is valid
drupal/media_library_importer is invalid, the following errors/warnings were found:
# General errors
- name : Does not match the regex pattern ^[a-z0-9]([_.-]?[a-z0-9]+)*/[a-z0-9](([_.]|-{1,2})?[a-z0-9]+)*$
- name : Media Library Importer is invalid, it should have a vendor name, a forward slash, and a package name. The vendor and package name can be words separated by -, . or _. The complete name should match "^[a-z0-9]([_.-]?[a-z0-9]+)*/[a-z0-9](([_.]?|-{0,2})[a-z0-9]+)*$".
# General warnings
- License "GPL-2.0+" is a deprecated SPDX license identifier, use "GPL-2.0-or-later" instead
drupal/media_thumbnails is valid
drupal/media_thumbnails_video is valid, but with a few warnings
# General warnings
- License "GPL-2.0+" is a deprecated SPDX license identifier, use "GPL-2.0-or-later" instead
- require.drupal/media_thumbnails : unbound version constraints (>=2.0) should be avoided
- require.php-ffmpeg/php-ffmpeg : unbound version constraints (>=0.14.0) should be avoided
drupal/menu_link_attributes is valid
drupal/metatag is valid
drupal/moderation_sidebar is valid
drupal/module_filter is valid
drupal/nouislider_js is valid, but with a few warnings
# General warnings
- License "MIT License" is not a valid SPDX license identifier, see https://spdx.org/licenses/ if you use an open license.
If the software is closed-source, you may use "proprietary" as license.
drupal/pathauto is valid, but with a few warnings
# General warnings
- require.drupal/token : unbound version constraints (*) should be avoided
- require.drupal/ctools : unbound version constraints (*) should be avoided
drupal/plyr is valid, but with a few warnings
# General warnings
- License "GPL-2.0+" is a deprecated SPDX license identifier, use "GPL-2.0-or-later" instead
drupal/prismjs is valid
drupal/project_browser is valid
drupal/queue_ui is valid, but with a few warnings
# General warnings
- License "GPL-2.0+" is a deprecated SPDX license identifier, use "GPL-2.0-or-later" instead
drupal/reading_progress_bar is valid
drupal/recipe_installer_kit is valid, but with a few warnings
# General warnings
- require.drupal/core : unbound version constraints (>=10.4) should be avoided
drupal/redirect is valid
drupal/robotstxt is valid
drupal/sam is valid, but with a few warnings
# General warnings
- License "GPL-2.0+" is a deprecated SPDX license identifier, use "GPL-2.0-or-later" instead
drupal/scheduler is valid, but with a few warnings
# General warnings
- Key _comment is a duplicate in /var/www/cms/web/modules/contrib/scheduler/composer.json at line 44
drupal/scheduler_content_moderation_integration is valid
drupal/search_api is valid
drupal/search_api_autocomplete is valid
drupal/search_api_exclude is valid, but with a few warnings
# General warnings
- License "GPL-2.0+" is a deprecated SPDX license identifier, use "GPL-2.0-or-later" instead
drupal/selective_better_exposed_filters is valid, but with a few warnings
# General warnings
- License "GPL-2.0+" is a deprecated SPDX license identifier, use "GPL-2.0-or-later" instead
drupal/seo_checklist is valid
drupal/simple_sitemap is valid
drupal/sitemap is valid
drupal/smart_date is valid
drupal/smart_trim is valid
drupal/svg_image is valid
drupal/symfony_mailer_lite is valid
drupal/tagify is valid
drupal/token is valid
drupal/token_or is valid
drupal/trash is valid
drupal/views_slick_animate is valid, but with a few warnings
# General warnings
- License "MTL" is not a valid SPDX license identifier, see https://spdx.org/licenses/ if you use an open license.
If the software is closed-source, you may use "proprietary" as license.
drupal/webform is valid
drupal/yoast_seo is valid
drush/drush is valid
egulias/email-validator is valid
enshrined/svg-sanitize is valid
evenement/evenement is valid
geocoder-php/common-http is valid
geocoder-php/nominatim-provider is valid
goalgorilla/rtseo.js is valid, but with a few warnings
# General warnings
- License "GPL-3.0" is a deprecated SPDX license identifier, use "GPL-3.0-only" or "GPL-3.0-or-later" instead
- The version field is present, it is recommended to leave it out if the package is published on Packagist.
grasmash/expander is valid
grasmash/yaml-cli is valid
guzzlehttp/guzzle is valid
guzzlehttp/promises is valid
guzzlehttp/psr7 is valid
html2text/html2text is valid
illuminate/collections is valid
illuminate/conditionable is valid
illuminate/contracts is valid
illuminate/macroable is valid
illuminate/support is valid
itamair/geophp is valid, but with a few warnings
# General warnings
- License "GPL-2.0+" is a deprecated SPDX license identifier, use "GPL-2.0-or-later" instead
laravel/prompts is valid
league/commonmark is valid
league/config is valid
league/container is valid
league/html-to-markdown is valid
masterminds/html5 is valid
mck89/peast is valid
mtownsend/read-time is valid
mtownsend/xml-to-array is valid
nesbot/carbon is valid
nette/schema is valid
nette/utils is valid
nikic/php-parser is valid
openai-php/client is valid, but with a few warnings
# General warnings
- require.psr/http-factory-implementation : unbound version constraints (*) should be avoided
pear/archive_tar is valid
pear/console_getopt is valid
pear/pear-core-minimal is valid
pear/pear_exception is valid
phootwork/collection is valid
phootwork/lang is valid
php-ffmpeg/php-ffmpeg is valid
php-http/discovery is valid
php-http/guzzle7-adapter is valid
php-http/httplug is valid
php-http/message is valid
php-http/multipart-stream-builder is valid
php-http/promise is valid
php-tuf/composer-stager is valid
phpowermove/docblock is valid
psr/cache is valid
psr/clock is valid
psr/container is valid
psr/event-dispatcher is valid
psr/http-client is valid
psr/http-factory is valid
psr/http-message is valid
psr/log is valid
psr/simple-cache is valid
psy/psysh is valid
ralouphie/getallheaders is valid
revolt/event-loop is valid
sebastian/diff is valid
simshaun/recurr is valid
spatie/temporary-directory is valid
symfony/cache is valid
symfony/cache-contracts is valid
symfony/clock is valid
symfony/console is valid
symfony/css-selector is valid
symfony/dependency-injection is valid
symfony/deprecation-contracts is valid
symfony/error-handler is valid
symfony/event-dispatcher is valid
symfony/event-dispatcher-contracts is valid
symfony/filesystem is valid
symfony/finder is valid
symfony/http-foundation is valid
symfony/http-kernel is valid
symfony/mailer is valid
symfony/mime is valid
symfony/polyfill-ctype is valid
symfony/polyfill-iconv is valid
symfony/polyfill-intl-grapheme is valid
symfony/polyfill-intl-idn is valid
symfony/polyfill-intl-normalizer is valid
symfony/polyfill-mbstring is valid
symfony/polyfill-php80 is valid
symfony/polyfill-php81 is valid
symfony/polyfill-php83 is valid
symfony/polyfill-php84 is valid
symfony/process is valid
symfony/psr-http-message-bridge is valid
symfony/routing is valid
symfony/serializer is valid
symfony/service-contracts is valid
symfony/string is valid
symfony/translation is valid
symfony/translation-contracts is valid
symfony/validator is valid
symfony/var-dumper is valid
symfony/var-exporter is valid
symfony/yaml is valid
tijsverkoyen/css-to-inline-styles is valid
twig/twig is valid
voku/portable-ascii is valid
webmozart/assert is valid
willdurand/geocoder is valid
wpai-inc/anthropic-sdk-php is valid
yethee/tiktoken is validreopened the issue because I got this even on a regular Ubuntu Server without WSL so that still seems to be valid.
Hello dear Drupal Community.
first of all I would like to thank Catch for taking the time to reference the issue I created yesterday.
I already thought so and therefore just took 25 € out of my wallet to test Drupal CMS on Plek. I can tell you with certainty that the error disappears as soon as you (if you can, because you have root access) delete the file composer.phar in the directories
./usr/lib/plesk-9.0/
./opt/psa/admin/plib/modules/composer/resources/composer/
./opt/psa/var/modules/composer/
has been updated to the current version 2.8.8. For many of you, this can probably only be done by the service provider.
Plesk wird nämlich auch heutzutage noch mit Composer version 2.2.5 2022-01-21 17:25:52 ausgeliefert. This version of composer is too old to work with Drupals Automatic Update Module and that is the root cause of the issue. Updateing composer would fix that. But this is something the control panel vendors or yor servcie providers have to do.
On the software side, you can only intercept this with a nice error message. You can find a suggestion for such an error message in the referenced issue.
joachim namyslo → created an issue.
joachim namyslo → created an issue.
joachim namyslo → created an issue.
Ist erledigt vielen Dank
Also hab mir dass jetzt mal kurz angesehen und musste leider feststellen, dass zwar der ober e Punkt, also die Shipping-Methods tatsächlich Versandarten meint, dass ich aber noch nicht so genau weiß, was der Untere Punkt, also die Shipping Types machen. Dies sind auch in keiner Dokumentation weder Version 1 noch Version 2 von Commerce dokumentiert.
Dass bedeutet ich muss mich jetzt durch die englische Demo wurschteln und versuchen herauszufinden, was durch diese erzeugt wird, um eine Benennung zu finden. Aktuell tippe ich auf Versandbestätigungen. Das ist aber nur ein Educated Guess., wie man so schön sagt und leider noch nicht begründet. Wenn dem so ist, müssen wir das auch hier noch irgendwo dokumentieren, weil sonst bestimmt wieder irgendjemand vorbeikommt, der's gut meint und das ganze wieder abändert :-D
Das ist jetzt so lange keinem aufgefallen, dass es auch noch ein paar Tage liegen bleiben kann, bis ich mir die englischsprachige Demo mal genauer ansehen kann. Solltest du wissen, was unter dem Punkt Shipment Types genau konfiguriert werden kann, sag einfach bescheid.
Hallo Renato,
kannst du mich bitte an diesem Punkt noch mal abholen. Die deutsche Post sagt ja offiziell Versandart.
- Päckchen
- Paket
- Brief
-usw.
Das Wort Methode beschreibt die Art und Weise wie man etwas tut
Wie genau unterscheiden sich die beiden Begriffe in Drupal Commmerce. Gibt es visuelle Beispiele (Screenshots, Videos) die das Problem illustieren?
Andernfalls müsste ich die komplette Distro installieren und mir dass ansehen. Ich hoffe du kannst hier weiterhelfen.
Grüße
Aktuell hinzugekommene Übersetzungen brauchen Review
https://localize.drupal.org/translate/languages/de/translate?project=pro...
Updates brauchen Review
https://localize.drupal.org/translate/languages/de/translate?project=kla...
joachim namyslo → created an issue.
Hallo Jan,
ich hab in der ersten Review nur zwei kleine Anmerekungen.
1. https://localize.drupal.org/translate/languages/de/translate?sid=2985416
Der Bindestrich ist eine Kann-Regel im Deutschen, wenn es darum geht deutsche Wörter miteinander zu verbinden.
Gott sei dank, denn auf diese Weise zusammengebundene Wörter sehen immer so deplatziert in der UI von Drupal aus. Also solange du nicht wirklich den alten Klassiker: Donau-Dampfschiffs-Fahrt-Kapitäns-Mützen-Aufdruck. verbinden musst, um die Lesbarkeit des Wortes zu gewährleisten, lass den Bindestrich weg. Es brennt beim Lesen in den Augen. (Voricht: Subjektive Meinung).
Eine weselntlich aufgeklärtere Meinung zu dem Thema könnt ihr hier nachlesen.
https://web.archive.org/web/20220629124720/https://www.textschoepfung.de... Es ist so schade, dass es diese Seite nur noch so gibt. Ich finde die sollte zur Pflichtlektüre eines jeden Übersetzers in diesem Projekt gehören. Deswegen verlinke ich sie hier noch mal.
Ansonsten habe ich die letzte nicht übersetzte Zeichenfolge, den Modulnamen einfach mitübernommen.
Es gibt in der Community die einen, die sagen, Modules müssen nie ganz übersetzt werden, weil zum Beispiel Modulnamen im Englischen und im Deutschen gelich sind und dadurch nur die Datenbank der Website die die eine Übersetzung importiert nur unnötig aufgeblkät wird. Deswegen gibt es das Modul: l10n-Tools ( https://www.drupal.org/project/l10n_tools → )
Und es gibt mich, der an die armem Übersetzer hier auf dem Übersetzungsserver denkt, die die Verantwortung dafür haben, dass neben dem Kernsystem alle von der Community bereitgestellten Zusatzmodule möglichst zu 100 % übersetzt sind, damit ihre Nachfolger, im Falle einer Aktualisierung der Strings eines Moduls, mit diesem möglichst wenig Aufwand haben.
Deswegen habe ich mir erlaubt, auch den Modulnamen mit zu übersetzen, was dafür sorgt, dass es für alle Originalzeichenfolgen innerhalb des Moduls eine Übeersetzung gibt. Und den Statusbalken für des Modula auf glatte 100 % hebt.
PS: Der Jan weeis dass natürlich, aber ich weiß ja nie, wer über diese Issues fällt, deswegen wollte ich das hier noch mal erwähnen.
Ich denke ich werde am Samstatg eine kurze UI-Review durch installation des Moduls und import der Übersetzungsvorschläge in einer frischen Drupal-Installation druchführen und mir die Zeichenfolgen noch mal innerhalb des Kontexts der Benutzeroberfläche ansehen. Wenn jemand schneller ist und etwaige ungereimtheiten hier meldet, bin ich auch nicht böse, dann hab ich am Samstag weniger zu tun..
Vielen Dank für die tollen Übersetzungsvorschläge.
First point: The installer. This belongs in a separate issue. I know that this would also go beyond the scope. If there is already an issue for this, please link to it on the right-hand side.
Nevertheless, I would like to briefly note here that the installer is the first point of contact with Drupal for many users. If we continue to allow the display language to be mixed between English and other languages (e.g. when selecting a time zone [country/city/state]), then users are likely to continue to wonder why, on the one hand, we advertise with first-class multilingual support but, on the other hand, show during installation that this does not always work. Everything else belongs in a separate issue.
Second point: Configuration translations (primarily views but also menu labels and descriptions).
As far as views and basically all other configuration translations are concerned, I understand that we are currently displaying the English originals here, even if a website is installed in a language other than English, but as an end user, I simply do not accept this.
If I put myself in the shoes of an international agency, I would say something like the following:
“We want labels of views, titles, filter options and the like to continue to be available in English even on sites installed in Spanish, for example, because our multinational employees must be able to make configurations on a site whose default language is Spanish. Therefore, it would be good if we could first import English-language values here, which would then have to be translated manually.”
I have read this elsewhere on Drupal.org, unfortunately, I can no longer find the reference issue.
From an agency's point of view, this is certainly true. However, as an end user, I will contradict this statement and say something like the following:
1. I have installed Drupal in my native language so that I understand what I am triggering when I activate or deactivate an option in Drupal.
2. I activate a module or recipe for Drupal that adds a new view, a new menu or a new dashboard and notice that I, as an administrator, or even at the frontend (for example, when a view does not yet contain any content or I activate a filter within the view), am suddenly shown English texts.
a. I don't understand this.
i. For one thing, I didn't install the site in English.
ii. Furthermore, there is a translation for the Drupal user interface in my language
iii. Furthermore, the translation of the relevant character string is available there.
iv. Nevertheless, the view provided by the newly added recipe/module is still partly in English.
1. My conclusion is: Drupal's multilingual support is not as good as it is made out to be.
2. So I'll just sit down and translate such standard messages and button texts myself, so that Drupal at least looks like it supports multilingualism perfectly on my website.
3. Now I have to spend time on something that the responsible translators have already done. What's the point? Why is that so?
Example: This page does not contain any content, yet. (Text if there is no Content in a View.
Add a Blog Post
Filter --> Button Label (Apply) ect. (Filter options in general, Buttons for exposed Filters, ect.)
This is exactly what many end users experience when they first start using Drupal.
This applies to view components, menu names, and much more in Drupal.
Guys, I understand both worlds. Really!
But we have to do something about it. From the view point of an end unser it is unacceptable for Drupal to display English strings in the user interface when it is displayed in a different display language.
Especially not if translations are already available for a particular part of Drual on localize.drupal.org. We as a community are no longer being properly informed about the fact that there could be a plausible reason for this. This is due to the expectations of many end users, who in the age of AI simply assume that it should no longer be the case that they encounter situations within a software in which there is a mix of different languages in the display language of a user interface, if this has not been explicitly specified by the end user.
Similarly, this can be applied, for example, to menu names and link labels within menus.
If a menu is named Welcome, as in the case of the Drupal CMS Dashboard recipe, or in the case of Drupal Corr Main Navigation, then as an end user I expect the name of the respective menu and its description to be in the default display language of the site that was selected when the website was installed.
Unfortunately, Drupal still doesn't do this well, even in version 11. We need to be careful here and write tests to help developers identify such problems early on.
Third and last point: We urgently need guidelines for developers on how to write translatable original strings, as well as technical control routines.
If you take a look at the translation server, you'll find a number of original strings that look something like this:
<div class=“messages messages--info”>Your CivicTheme (for Starshot) version: @version</div>
The point is that we do not get such translations translated because of the API function
https://api.drupal.org/api/drupal/core%21modules%21locale%21locale.modul...
not translated.
These are rejected when importing translations into Druapal because of the above-mentioned function that simply does not allow div tags. This means that Drupal is not 100% translatable by default, for the sake of security.
Developers who are not aware of this may inadvertently cause such translations to end up on the server. If we want to keep Drupal future-proof, then we need a solution that checks submitted original strings against the tags contained in the function locale_string_is_safe at the latest in the publication process of a module or theme and rigorously advises developers to modify the affected strings so that they are translatable before the POT file for a module can be deployed to the translation server.
This is half the battle with this problem. The other half is to find such strings in modules that have already been published and to point out to the maintainers which of your modules or themes contains original strings that could be improved.
At least since Drupal 7, these errors have become commonplace and as much as I like translating Drupal to make it more accessible to newcomers and interested parties, it is becoming increasingly difficult to keep track of which project maintainer has been informed that there is an incorrectly written original string in their module and whether or not the problem has been fixed. I can only speak for myself, but I can't do it in my free time. There are simply too many of the same kind of issues to manually track them.
I can imagine that especially the last point, which tends to fall into the areas of infrastructure and documentation teams, does not necessarily fit into this track. But I don't know where or with whom I should talk about it if I don't bring it up here. This is a big problem and one that we have been putting off since Drupal 7 and have not been able to get under control at any level. That's why I don't want to leave it unmentioned here.
Update.
It seems the business logig is there, And the issue occoures beacause the text arrea field looses focus after code was insertet. So if you don't feel the logig behind that should be changed this should be documented at least.
The Issue can be solved by
1. Insert code
2. Click into the text area again.
3. user the right or left arrow key depending on your reading direction. to get your corser back
4. hit return.
Theese are additional steps after inserting code while if a paragraph would be added here it'll more obvious to most users that they have to click below the code insert to continue writing.
joachim namyslo → created an issue.
Maybe symphonies approach can help here?
https://symfony.com/doc/current/translation.html
They have a way to handle yml files according to their docs as well and Drupal is based on it, isn't it?
Review am 03.03.2025 17:30 GMT
Found out that the copy button is allready supported by the javascript lib itself. Is it possile to replace the js files for individual themes within the module and add toolbar and copy to clipboard so we have this functionallity on board out of the box, please?
yes, but it depends on RAM, CPU Cores and HDD Space on your system drive, because WSL stores Linux there. So if one of theese ressources is week, it may be not the best option for you. It depends highly on your hardware setup.
Plus I am on Windows 11. Windows 10 is near eol so I wouldn't even give it a try anymore. But that's me.
Localy I am useing WSL wíth this hardware:
OS: Microsoft Windows 11 Pro, Version 10.0.26100
CPU: AMD Ryzen 9 5950X 16-Core Processor
RAM: 128.0 GB
Storage (3): HDD - 14.6 TB,SSD - 931.5 GB,+1 more
GPU: NVIDIA GeForce RTX 3090
To be honest, I haven't really been able to compare the speed of the WSL. Unfortunately, I don't have 3 computers with 5 different operating systems. I can only tell you that the WSL is performant enough for me. It runs in the background and when I want to do something with Druapl, it starts up. When I switched over, it was even faster than Virtualbox. I can't say whether this is still the case.
I used to develop with 32 GB RAM system memory using Virtualbox without any problems. Maybe it will be more performant in your case. But I can't say anything about that.
What I do know for sure is that it is probably not a good idea to run the WSK on a system with less than 16 GB RAM. WSL is definitely slow on a computer with 8 GB ram, for example. But that shouldn't surprise anyone these days. I mean, my cell phone already has 12 GB of RAM and I only carry that around in my pocket in case it rings and don't develop Drupal websites on it
But since even Docker uses WSL2 for Windows, I don't think WSL itself is slow. There should be enough developers here in the community who can confirm or deny this.
For my part, I love being able to install the same packages with the same commands as I use when I work on my server or on the servers of customers.
joachim namyslo → created an issue.
OK
In the end, it doesn't matter whether it works or not. We have had WSL since Windows 10, and it works wonderfully and natively provides everything you need to run all kinds of web applications directly on Windows.
There is no longer any good reason to use this type of software. Without a single tweak.
I'm fine with it if it works for some of you. Newcomers who first have to configure their stack to make Drupal work often blame Drupal and for this reason we shouldn't support such software at all.
The solution is in #26. This is the explanation for 26.
joachim namyslo → created an issue.
joachim namyslo → created an issue.
Any news here?
Das einzige mal,, dass das so übersetzt wurde war im Source-Sting. Ich hab das jetzt geändert. Sonst habe ich diese Art authenticate zu übersetzen kein einziges mal im ganzen Projekt, weder im Core, noch in den Übersetzungen der Zusatzmodule gefunden. Deswegen mache ich den Issue jetzt wieder zu.
https://localize.drupal.org/translate/languages/de/translate?project&sta...
joachim namyslo → created an issue.
joachim namyslo → created an issue.
The configuration php_value assert.active 0 in an .htaccess file or server configuration disables the execution of PHP assertions. This means that all calls to the assert() function in PHP are ignored and immediately return true without actually evaluating the condition. This is useful for disabling assertions in production environments, as they are typically only used for debugging and development purposes.
Background on assert.active
Function of assert(): The assert() function is used to check conditions in code. If the condition fails, it can trigger a warning or perform an action, such as terminating the script. However, assertions are not a substitute for regular error handling but serve as a debugging tool.
assert.active: This setting controls whether assertions are executed at all. When set to 0, all assertions are ignored, improving performance and avoiding unnecessary checks in production systems.
Changes in PHP 8.3
Starting with PHP 8.3, the setting assert.active along with related options like assert.bail, assert.warning, and assert.callback has been deprecated. Instead, it is recommended to use the zend.assertions setting:
zend.assertions=1: Assertions are active.
zend.assertions=0: Assertions are compiled but ignored at runtime.
zend.assertions=-1: Assertions are completely removed and not compiled (recommended for production environments).
Example Transition to zend.assertions
To replace the deprecated assert.active=0 setting with the new approach, you should update the configuration file as follows:
text
; Old method
; assert.active = 0
; New method
zend.assertions = -1
Conclusion
Using php_value assert.active 0 is a common way to disable assertions in older PHP versions. However, in newer versions (from PHP 8.3 onwards), it is recommended to use zend.assertions=-1 instead, as the old settings are no longer supported and may be removed in future versions.
joachim namyslo → created an issue.
Dankeschön ich geh heute Abend noch mal drüber.
joachim namyslo → created an issue. See original summary → .
Ich habe diesbezüglich mit @KingDutch kurz über Slack gesprochen. Die Übersetzungen für die Ampel-Funktion beim bewerten der einzelnen Seiten kommen aus der Original Bibliothek von Wordpress. Die Systeme mit denen Wordpress und Drupal übersetzungen verarbeiten, sind so inkompatibel ,dass es nicht möglich ist, die Übersetzungen bereitzustellen, ohne das komplette Projekt zu forken. Die Betreuung des Originals inklusive regelmäßigen Aktualisierungen durch Drupal-Entwickldr liegt jedoch außerhalb der Möglichkeiten, weswegen die Hauptfunktion des Moduls, also die Bewertungsampel weiterhin für alle nur in Englisch zur Verfügung steht.
Erneute Review mit Korrekturen. Jetzt 100 % ok
So I looked at this again and reset the translations in my installation of Drupal and imported them fresh. The module is 100% translatable. Many thanks for actively patching it. We can close the issue
The placeholder shown above is still displayed in the Ui and the placeholder %level is not replaced with text. Unfortunately, placeholders cannot simply be removed from strings because the translation server does not allow the affected string to be saved without placeholders in superset form. The placeholder must therefore either be reactivated or removed. Otherwise it will remain exactly as it is.
The correction notes are now in order.
I have found a single passage that cannot be translated. It is the string
https://localize.drupal.org/translate/languages/de/translate?sid=2913733
However, the translation is available and approved. That's why I find it strange.
As for the original issue, we can close it. The module can now be translated without any problems (except for the string mentioned)
Let me check if %headingExample isn't shown anymore when translations are live. If it is still there, we need to fix it. Until we confirm it, we can change it to postponed. If the bug exists the translations containing %headingExample must be changed manually in each language by maintainers and that deed wouldn't be the best solution.
Since Microsoft and canonical invented the SSL it should be fully ok to drop windows support when wsl isn't used. Even PHP windows binaries will run down soon. Just because they are not needed anymore. Now we can use all that with a pretty stable walk layer.
Tested Windows + WSL + Debian 12 + Drupal CMS 1.0 today. It works perfectly.
Well,
I sat down again and did a bit of debugging. Since Adam suspected that it could be the Windows subsystem for Linux. Instead of Ubuntu in my WSL, I spawned a Debiaian container. Ta-da, suddenly the WSOD is gone. If I can now find out whether the Ubuntu provided for WSL uses a different Bash version than Debian 12 bookworm, which is what I'm currently using, then that would confirm the theory that this is a bug related to Bash. That wouldn't be good, because we can't tell every host out there which Bash version to install to make the Automatic Update Module work. However, it will take some time before I have a final result. I'll be in touch again then.
By the way, I installed exactly the same packages and modules on Debian as listed above. I even used the same package source.
Debian Linux JosPC 5.15.167.4-microsoft-standard-WSL2 #1 SMP Tue Nov 5 00:21:55 UTC 2024 x86_64 GNU/Linux
Bash Version
bash --version
GNU bash, version 5.2.15(1)-release (x86_64-pc-linux-gnu)
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Update will follow as soon as I have reinstalled Ubuntu 22.04 and checked the Bash version and the behavior on the Drupal page mentioned above.
No, the strings got extracted when payout release a new version
I can change it manually for now, but it should be fixed, because other language teams might find this confusing when the issue got closed. So we need to take care and see when it is gone if new strings available on l.d.o
This is not the WSL, I am not sure. The part of the error message that is a mystery to me is
... failed.\n\nExit Code: 2(Misuse of shell builtins)
Maybe the code to execute Composer validate is currently being passed incorrectly
Refferences:
1. https://access.redhat.com/solutions/196563
2, https://tldp.org/LDP/abs/html/exitcodes.html
That is almost perfect,
I quickly made suggestions and imported them locally into Drupal CMS.
Apparently, some placeholders are not recognized.
https://localize.drupal.org/translate/languages/de/translate?sid=2913738
Here is an example string:
https://localize.drupal.org/translate/languages/de/translate?sid=2913738
Apart from that, everything looks excellent, and the administration area's configuration page is now completely translatable.
joachim namyslo → created an issue.
Regarding the object for German.
I'm not sure if that's a good thing. Drupal supports 115 languages. Of these, some translations are less active others more. Thanks to our dedicated team members, we are often the first to notice this. Most of the time these kinds of bugs are valid to all languages Drupal supports. That's why I'm not sure if an extra object for a specific language makes sense here. I'll Compare the behavior of the two module versions as soon as possible and give feedback as promised.
That's a good one. Actually I don't t know but I can test it manually and reply here, if that. Helps. Don't worry about destroying any translations work, please we can re-translate that real quick. The smaller the peaces thee easier it'll be. Especially if there is just text in those additional strings. It's really late here.So testing and replying will take a while.
Hello lemoni,
thank you for reporting this issue. I'm pretty sure I messed this up. The reason this string couldn't be imported is that the opening quotation mark in the link to the image style configuration page created by the module's example code is missing.
But since this is a translation issue, it's better to report the error in the issue queue of the respective language. In this case, here: https://www.drupal.org/project/issues/de?categories=All →
Almost nobody does this in Germany, I don't know why, but it is so :-D
As you know, there are 2 columns on the translation server: the original is on the left and the translation into the respective language is on the right.
If the error is only in the right column, then it belongs in the above-mentioned issue queue. If you find an error in the left column, i.e. in the original string, then you have to report the issue in the issue queue of the relevant module.
I have replied to you here:
https://www.drupal.org/project/de/issues/3417589#comment-15939064 →
and also credited you here:
https://www.drupal.org/project/de/issues/3153285
📌
Image Widget Crop
Fixed
. Because anyone who reports or fixes bugs deserves recognition without a doubt.
Basically, the localization server always needs a little time before it makes the file in which a translation has been changed available for import again. I changed the string again earlier and now have to wait and see if the import goes without errors. As soon as I know, I will of course give you feedback or, if necessary, make further adjustments. After all, that's what I'm here for.
So we can say: review in progress. Depending on how quickly the server recreates the affected file, we may be able to close the issue in just 45 minutes. Sometimes within a day.