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.
I'm a bit sad that I have to reopen the issue here. I thought the error was with us and that we had forgotten to translate the module 100% before checking for non-existing translations, but unfortunately, that is not the case. In the German translation of Drupal, the module is 100% translated and yet it still displays English texts even when the display language for Drupal is set to German. As the two screenshots above show, English texts exist both in the module's popup dialogue and in the configuration form in the Drupal administration area.
Therefore, I unfortunately have to reopen the issue here.
joachim namyslo → created an issue.
It's not that simple.
There has to be a hint for data transfer as soon as an administrator wants to store a key to activate an AI. This is indeed an issue for all modules that access external data sources. That's why the issue is in good hands here. At the latest before activating the connection between Drupal and the AI service, the site operator should have a corresponding passage in his privacy policy. To do this, however, they must know that we transfer data to third parties as soon as the key has been saved.
I'm just saying this to make it easier to understand. This will certainly require corresponding interfaces from the Ai module to Klaro and possibly even to the GPR module. That's why the issue fits here. A note that you should check your privacy policy before activating a Ki provider is the minimum.
I think when it comes to inexperienced users who want to try out Drupal and get to grips with the CMS, a clear visual dividing line between the frontend and the administration area is very helpful to know directly which part of the page you are currently on. This is exactly where this approach plays a role. That's why I can certainly understand the approach. However, I am also aware that not every user will prefer dark mode. But offering users the chance to try out dark mode as part of a guided tour, for example, could help here. I don't think it's the best solution to do this as a matter of principle.
Pointing out the difference between light mode and dark mode and letting the user decide what they would like is, I think, a better approach. Incidentally, you could also make the whole thing dependent on the user's system settings. There are already 1 or 2 issued in Gin for this.
Maybe we can document somewhere how to enable it via crush, then? So anyone who like to do so can combine it with a drush si.
Vielen Dank @lemobni für den Hinweis in #3417589: Nicht importierbare Übersetzungen (disallowed/malformed HTML) heilen → Credits sind raus.
Richtig irgendwann letztes Jahr hat deepL beschlossen, dass es sinnvoll wäre Orthographische Anführungszeichen zu verwenden. Das ist es, das machen wir hier auch seit Jahren, aber natürlich ist das untenstehende Anführungszeichen nach dem Href= in der Zeichenfolge völliger Quatsch. So gut die Ki von DeepL mittlerweile darin ist Rechtschibfehlerfreie brauchbare Vorschläge für Übersetzungen zu produzieren , so sehr erfordert es immer noch eine Human Review wegen genau solcher Kleinigkeiten, die auch mir leider noch viel zu oft durchrutschen. Danke für die Korrektur. Ich lass den String zu.
joachim namyslo → created an issue.
That's a very good idea.
I always do the same when I install Drupal because it's a lot less painful for the eyes when you're sitting in front of a 38-inch screen. I think that would be a very good default setting.
Hello, I just stumbled across this issue and it's been like this for a good 13 years. If you knew how many times I've answered such questions at the Drupal Center in Germany. And the problem is always the same. Software like Wamp, Xampp and the like have never worked with Drupal and that's not because of Drupal but because of these software packages.
You have two options:
1. You use DDEV but you have to learn at least the basics of Docker, which, admittedly, is not necessarily what you want if you just want to run a website.
2. Install the WSL, put Ubuntu, Apache, Mysql and PHP on top of it.
The last method has several advantages
1. You get an environment that is similar to DDEV
2. You can use many tutorials for Ubuntu as a guide and don't need to know much to set up a stack
3. You get an environment with which you can transfer your finished website to a server at your web host when it is ready
5. You can very accurately replicate the system resources of the web server on which your website will ultimately run
6. If your website requires certain command line tools, for example for image optimization, you can easily install them later
7. Drush and Composer work out of the box without you having to edit path variables in Windows.
DDEV is, of course, also a completely legitimate option if you don't want to deal with configuring a web server or a development environment. The initial setup of DDEV is even faster than the pure WSL setup. However, the learning curve becomes even steeper if you first have to familiarize yourself with DDV. It won't make any difference if you've never worked with Linux before, whether you use DDEV or a pure WSL setup.
Microsoft didn't introduce WSL for nothing. Tools like Wamp and XAMPP date from a time when the Windows subsystem didn't yet exist, and today they should no longer be used to work with Drupal, because they bring with them problems for which Drupal, as the actual software you want to use, simply can't do anything.
To help you with your actual problem, we would have to
installing Wampp
installing Drupal 9 and somehow trying to recreate your bug,
finding the source of the error and then building a solution.
Please believe me when I say that you'll be faster if you say goodbye to WAMPP and instead switch to DDV or a pure WSL setup.
That's a very good point.
From the last 13 years, I know that all Drupal developers I've encountered during that time prefer reading English texts rather than translating. Users who are just starting to explore software like Drupal are very grateful when you provide them with information about the software in their native language. These are two completely different points of view. I would like to know whether we host the documentation directly on drupal.org or use a static page generator like Vitepress.
I don't think we can easily activate the multilingual features of Drupal for drupal.org. Nevertheless, I would be happy if we could localize the documentation for Drupal CMS.
The question that concerns me here is whether this would really work if we did it through the documentation on Drupal.org. If the answer to that question is yes, then nobody needs any new system to continue offering the user guide in multiple languages.
Done :,-)
For the German translation of Drupal I have now replaced the tag u with em or b, so that there are no warning messages when importing the translations. However, as there are 114 other languages for Drupal, the source code of the module should still be adapted promptly in the relevant places.
Vorschläge sind drin.
Although the issue is now closed, I feel the need to contribute some context here.
A non-imported string within a translation, regardless of the language, always has a very negative connotation.
In order for translators to be able to translate a module 100% into another language, strings like should not be inside t() when a module is published. Translations are often made by beginners who may not know that all html tags that are not in https://api.drupal.org/api/drupal/core%21modules%21locale%21locale.modul... are rejected when imported into Drupal.
Therefore, in well-written modules, this should not be declared as a translation in the first place, just like div class=...
Once such a string has been read by the Potx module, it must remain unsuperseded, which means that the module in question cannot be translated 100%.
Basically, such errors as in this case are
1. to be reported in the issue que affected language and
2. to adapt the relevant place in the codec of the module concerned so that translators have the opportunity to translate the affected texts and the non-importable translation can be removed by the project supervisors of the respective language, without a part of the UI necessarily having to remain English if the language affected by the error has been activated as the display language on a website.
Therefore, the statement that this is merely a warning that can simply be ignored is not correct.
Drupal currently supports over 100 languages. Therefore, a string that can be rejected during import because there is a possibility that it can be overridden, allowed and rejected during import is always a source of over 100 potential errors.
The workaround we have chosen here is to use HTML entities instead of tags during translation. This suppresses the warning message during import.
https://localize.drupal.org/translate/languages/de/translate?sid=1752228
In the best case scenario, the string should not end up on the translation server at all.
Das Modul Drupal Experience Builder → wird es 1) Website-Erstellern ohne Drupal-Erfahrung ermöglichen, ihre gesamte Website mit Hilfe ihres Browsers zu gestalten und zu erstellen, ohne dass sie Code schreiben müssen, der über grundlegendes HTML, CSS und Template-Markup (z.B. Twig) hinausgeht, UND 2) wird das Modul Content-Erstellern ermöglichen, Inhalte auf jedem Teil der Seite zu erstellen, ohne auf Entwickler angewiesen zu sein.
Im Gegensatz zu konkurrierenden Tools eignet es sich besser für die kanalübergreifende Wiederverwendung von Inhalten und die Verwaltung von Inhalten in großem Maßstab, da es die Stärken von Drupal (wie strukturierte Daten und fein abgestufte Zugriffskontrollen) nutzt, um Daten- und Designkonsistenz zu erreichen.
Mit Drupal können Autoren, die Inhalte erstellen, ein einziges CMS verwenden, um Inhalte in einem Headless- und einem gekoppelten Kontext zu verwalten, und Site-Builder werden in der Lage sein, groß angelegte Designänderungen wie Rebranding vorzunehmen und groß angelegte Inhaltsoperationen wie Importe, Exporte und Migrationen durchzuführen.
Das Modul soll im Juli 25 in Drupal CMS eingeführt werden. Bis dahin können wir mit der Übersetzung beginnen. Je früher dies passiert desto schneller können wir am Ende auf neue Zeichenfolgen reagieren, da nur noch neu hinzugefügte UI-Strings übersetzt werden müssen. Im Mai 25 sollten wir also schon mal mit der Übersetzung und einer vollständigen Review des Moduls durch sein.
joachim namyslo → created an issue.
joachim namyslo → created an issue.