🇩🇪Germany @c-logemann

Because we have clear status codes for issues the title doesn't need to reflect it. It's even harder to read the issue overview.

The status "Needs work" was argued to translations which are not focus of this issue and were fixed as reported at #8 and #9. So switching back to "Needs review".

Thanks @thomas kaisuka for testing. I think the result is an argument for RTBC.

Bis auf "internal:/" ist jetzt alles übersetzt.

Ich schau mal welche Strings ich auf die Schnelle bestätigen kann.

Leaving issue open to figure out if we can be compatible to d10 or if there are other problems which need to be solved on another way,

This was a mistake as kind of step back from D11 to D10 code which is now a problem on D11. So will undu this change.

c-logemann → created an issue.

This solution is based on entity_reference_uuid but was at one point to near which caused an error and on one point different related to joining data. So I removed the wrong join and changed the main join to users_field_data instead of users table like entity_reference_uuid is doing.

> If someone needs reverse relationships we can also implement this.

Just recognized that I need this by myself. So follow up is here: ✨ Create views reverse relationships Active

c-logemann → created an issue.

I created only normal relationships. If someone needs reverse relationships we can also implement this.
A new update hook is changing the field definitions.

It seems that it's easy to define our own views relatioships. But also the field definition is not as easy to replace as I thought. I will try to get this fixed by an updated hook or this will be the next and hopefully last breaking change.

c-logemann → created an issue.

c-logemann → created an issue.

Oh, was already connected as parent issue. Sorry for the noise.

joachim namyslo → credited c-logemann → .

There are still D7 LTS Projects active and you can use old Drupal versions secure behind server based protections e.g. as static content generator. For this we still run D6, D7 and D8 systems with older PHP versions. So why not archive instead of deleting?

Just after discovering HTMX a view months ago I saw a good descriptive German video on Youtube including a long critical part about software concepts and why HTMX is not good as a base of a complete frontend
application. That's maybe true but that's not my usually need.

I call myself a Drupal-Symfony-PHP Developer with a good toolbox on server level. So I first try to solve problems with Drupal and use other Server stuff if faster etc. But everytime I need some dynamic HTML parts in Drupal I always struggle with AJAX and JS at all and need the help of others. But I only needed under one hour to start with HTMX including using the module from zero to a functional solution for an internal project.
From my perspective I cannot really help as much in this issue as I like because I'm not good at Javascript. I think I'm one of the ideal target Drupal developers of this change because using HTMX feels like a true Drupal concept for me. And which library is managing this behind the API doesn't matter for me as long as it stays lightweight. So maybe some other JS Frameworks came along and maybe also adopt this syntax. But the concept of HTMX stays and is named well in my opinion.

So I think the critic about the name "HTMX" I cannot share. Extending HTML is the main idea as I understood in seconds. That concept of @1cg is what I'm very thankful of. So maybe it's helpful here to make a difference in the discussion about the concept and the library with the same name. So we can decide to implement the concept and than try to get the best technical implementation in core. I believe this is also the HTMX library but nothing I cannot really say with my lack of experience in JS frameworks etc.

Ich bin schon etwas müde, deshalb mache keine Änderungen mehr. Aber mir ist aufgefallen, daß "fieldset" mal mit "Feldgruppe" und mal mit "Feldset" übersetzt wird.

"authenticate" scheint schon lange mit "legitimieren" übersetzt zu sein. Finde ich aber nicht passend. Siehe auch: https://dict.leo.org/englisch-deutsch/authenticate

Because the password reset link in user.module ist generated on mail sending for token security reasons I decided to not use normal tokens when altering user mails.

New Configuration Text in README.md:

To avoid serial uid in onetime login links and use the uuid based routes of this module you need to change configuration.
Replace serial entity ids in core mail token of all mail templates at /admin/config/people/accounts:
- `[user:one-time-login-url]` > `*u3id-one-time-login-url*`
- `[user:cancel-url]` > `*u3id-cancel-url*`
Be aware of other modules overridng core user mails and tokens like easy_mail.
Because of replacement at mail process we don't need to be compatible to core token replacement.

c-logemann → created an issue.

@alex.mazaltov Do you mean the diff or patch export option of the merge request?
It's at the dropdown menu of the "code" Button on each MR.
For the MR mentioned above it's this:
https://git.drupalcode.org/project/filefield_sources/-/merge_requests/5....
https://git.drupalcode.org/project/filefield_sources/-/merge_requests/5....

Example of how to use with Composer patches and lenient:
https://www.drupal.org/project/boost/issues/3428282#comment-15948406 📌 Automated Drupal 11 compatibility fixes for boost Needs review

Added next child issue: 🐛 Crawling broken on D11 Active

c-logemann → created an issue.

After the fixing of both issues above I tried as next step with demo_umami to crawl with "node: article, page, recipes" and got this error:
Deprecated function: Creation of dynamic property Drupal\boost\BoostCacheGenerate::$config is deprecated in Drupal\boost\BoostCacheGenerate->__construct() (line 53 of modules/contrib/boost/src/BoostCacheGenerate.php).

Logger is currently not used. So removing from Drush class is quick fix.

@joseph.olstad

Have you started using it?

No, it's currently more a hobby project of myself and part of a product idea I have but not started yet. So boost is currently in no website of myself, my company or any of the customer projects we maintain. If somebody wants to push with money there would be a possibility as a normal contract with Nodegard to bring this boost also to my normal job additionally to my freetime.

I added child Issues for fixing:

• 🐛 ypeError: DrushCommands::logger() Active
• 🐛 ArgumentCountError: Too few arguments to function Drupal\Core\Form\ConfigFormBase::__construct() Active

c-logemann → created an issue.

c-logemann → created an issue.

I tried to install in a fresh Core 11.1.1 after drush site:install demo_umami with drush en boost and got this error:

TypeError: Drush\Commands\DrushCommands::logger(): Return value must be of type ?Drush\Log\DrushLoggerManager, Drupal\Core\Logger\LoggerChanne  
  l returned in Drush\Commands\DrushCommands->logger() (line 77 of /var/www/h-kee7x/dev/dyn/boost/vendor/drush/drush/src/Commands/DrushCommands.  
  php). 

Additionally on Config page admin/config/development/performance/boost there is this error:

ArgumentCountError: Too few arguments to function Drupal\Core\Form\ConfigFormBase::__construct(), 1 passed in web/modules/contrib/boost/src/Form/BoostSettingsForm.php on line 72 and exactly 2 expected in Drupal\Core\Form\ConfigFormBase->__construct() (line 44 of core/lib/Drupal/Core/Form/ConfigFormBase.php).

I believe this errors are not limited to D11 but should be fixed in other Issues.

For testing via composer.

Install patch management:
composer require cweagans/composer-patches

For using D10 projects in D11 :
composer require mglaman/composer-drupal-lenient

Add to "extra" section in main composer.json:

   "drupal-lenient": {
            "allowed-list": [
                "drupal/boost"
            ]
        },
        "patches": {
            "drupal/boost": {
                "Automated Drupal 11 compatibility fixes for boost, #3428282": "https://www.drupal.org/files/issues/2024-05-30/boost.1.x-dev.rector.patch"
            }
        },

To get the automated patch working, we need the dev version.
composer require drupal/boost:1.x-dev@dev

The MR created by the bot was based on a wrong branch so I closed that one because !17 is also there.

Thanks @joseph.olstad for creating a fresh one and adding the patch of the bot.

c-logemann → created an issue.

c-logemann → created an issue.

I think we have different opinions about stable code.

c-logemann → created an issue.

c-logemann → created an issue.

c-logemann → created an issue.

c-logemann → created an issue.

I also reduced role machine name and mail to max of Drupal itself.

c-logemann → created an issue.

I have tested this new change and decided to merge. If someone gets in trouble with existing content and config please open an issue.

The change is really small and seems to work well. But I can say that transforming installed module especially with existing data isn't easy. So sadly I currently have to say: The best way is to uninstall and install again. Maybe the easiest way to handle existing data is to export them maybe in a json file and then reimport e.g. with migrate.

c-logemann → created an issue.

I just successfully created an "uuid only entity" with just using "entity_keys = { "id" = "uuid", ...". That's awesome and many thanks to everybody who made this possible. I will use this from now on many upcoming contrib and custom entities.

But when there is already content and other code handling with the serial ID? On some other uuid discussions I read many comments of people loving the old serial user and node IDs. For users I created the module "u3id" to handle a mixed usage. So I see a need of mixed usage and transformation of existing content etc. How to start in contrib/custom and how at core entities?

For testing via composer.

Install patch management:
composer require cweagans/composer-patches

For using D10 marked projects in D11:
composer require mglaman/composer-drupal-lenient

Add to "extra" section in main composer.json:

        "drupal-lenient": {
            "allowed-list": [
                "drupal/entity_reference_uuid"
            ]
        },
        "patches": {
            "drupal/entity_reference_uuid": {
                "Automated Drupal 11 compatibility fixes for entity_reference_uuid, #3430230": "https://www.drupal.org/files/issues/2024-03-17/entity_reference_uuid.2.1.0.rector.patch"
            }
        },

To get the automated patch working, we need the dev version.
composer require 'drupal/entity_reference_uuid:2.0.x-dev@dev'

In other words: The bot is right that there is no more needed than just fixing "core_version_requirement" compared to D10.

Since 📌 Automated Drupal 10 compatibility fixes Needs review is already fixed I think we can close this issues.

Successfully manually tested the patch on Drupal CMS RC incl. creating uuid reference fields via UI to terms, users and nodes.

Please commit and create a new release D11 compatible because some of my contrib and custom modules depending on this module.

Ich habe das jetzt mal nur überflogen. Gerade weil das Wort "Issue" sehr mehrdeutig ist ist es selbst im "Problem"-Kontext mehr als ein Bericht, sondern bezeichnet auch einen Vorgang/Prozess, siehe diese Issue hier in der ich gerade ein Kommentar schreibe. In Gitlab werden dieses Issues mit "Ticket" übersetzt. Das wiederum erschwert mir die Kommunikation mit unseren Kunden. D.h. da hätte ich sehr gerne, daß "Issue" nicht übersetzt wird.
Ein "Problem-Bericht" könnte somit nicht ausreichend sein, wenn ein Bearbeitungs-Kontext vorliegt – worüber ich mir bei diesem Modul nicht sicher bin, da ich mir das nicht so genau angeschaut habe.

Ich bin mir generell nicht sicher ob diverse Übersetzungen, die möglichst viel Begriffe eindeutschen nicht eher die eher ein Konfusionsrisiko darstellen und damit auch kontraproduktiv zur Idee sein können, Leute "zurückzugewinnen". Ich weiß nicht genau, warum welche Nutzergruppen den Wechsel zu Drupal 8+ (d.h. der Symfony Welt) nicht mitgegangen sind. Aber die meisten Äußerungen, die ich z.B. auf Drupalcenter gelesen habe, gingen Richtung Komplexität (z.B. Composer und beim Code bezüglich der Symfony Strategien).

I created the event page: https://www.drupal.org/community/events/drupalcamp-frankfurt-2017-2017-0... →

It wasn't easy to find all speakers because some usernames changed, But I think I found and added all organizers, helper, speakers, and sponsors.

c-logemann → created an issue. See original summary → .

I don't want to get this fix messed up. But just a note to improve translations. There is currently there is lot's of unneeded html inside the t():

$help_text .= $this->t('<a href="@url_used_attribute_list@" class="use-ajax" data-dialog-options="{&quot;width&quot;:800}" data-dialog-type="modal">See all the attributes used</a>.', [
          '@url_used_attribute_list@' => $url_used_attribute_list,
        ]);

It would be better to only put "See all the attributes used" inside t().

c-logemann → created an issue.

Seems to be related to Issue 🐛 "RuntimeException: Adding non-existent permissions to a role is not allowed." after module deinstallation Active and it's probably duplicate.

We have the same problem with global search block on core 10.2.* and better_exposed_filters 6.0.6. and patch #12 solves it. We also have facets but not the problems as reported by @malcomio.

@jan kellermann Ich habe die beiden in #22 verlinkten Übersetzungen bestätigt.

Gerade wenn eine Website in einem hobby- oder ehrenamtlichen Kontext betrieben wird, sollte ein Modul nicht den Eindruck erwecken, einen Datenschutzbauftragten zu ersetzen, wenn man mit dieser Website datenschutzrelevante Daten erfasst. Denn Websites deren Betreiber:innen an Marketing-Analysen etc. wenig bis kein Interesse haben, können sich oft Cookies und dieses Modul sparen. Aber ich bin Dienstleister und wir haben mit Kunden zu tun, die ausgefeilte Daten wollen. Insofern habe ich auch ein Interesse an Module, die dabei helfen, die "Wünsche" von Datenschutzbeauftrauftragten zu erfüllen.
Das letzte "problematische" Core Cookie (has_js oder so) wurde aus dem Drupal 7 entfernt und seit Drupal 8 braucht der Core nur noch Session Cookies (da kann man sich im Formular die Zustimmung holen). Alle anderen sind überwiegend technisch nicht notwendig und dienen vor allem Zwecken zu denen man eben Datenschutz-Erklärungen und Zustimmung benötigt. Ich persönlich halte viele Hinweise (auf allen möglichen Websites) zu angeblich technisch notwendigen Cookies für – sage ich mal – mindestens fragwürdig. Das gilt auch für irgendwelche Begründungen, daß man ja ein berechtigtes Interesse hat. Ich hoffe, die Video-Aufzeichnun der Session von Joachim Nickel ist bald verfügbar. Da ging es auch darum, wie man Besucher in Shop eher zum Bleiben und Kaufen animiert, in dem man die Voraussetzungen dafür schafft, die Consent-Geschichte nicht zu früh zu starten zu müssen usw.

Because there are no significant changes between 8.1.x and 3.0.x and zero changes between 2.0.x and 4.0.x it was not necessary to mark the source branches as "unsupported", leading to unneeded security confusion.

Because there is no difference between last 2.0.x and and current 4.0.x I just changed the target branch to 4.0.x in MR and for this issue.

Hier ist ein Hinweis, den Joachim Nickel in seiner Session auf dem zurück liegenden Drupalcamp in Berlin machte ganz sinnvoll: Entscheidend ist anscheinend, was die/der jeweilige Datenschutzbeauftragte "meint" auch bezüglich Einstellungen und Konfigurationen z.B. der Tracking Tools. Daraus würde ich schlussfolgern, daß wir hier keine einheitliche Übersetzung schaffen können, mit denen alle Datenschutzbeauftragten "glücklich" sind. D.h. im Grunde ist es denke ich für jeden Website-Betreiber mit "Cookie Spaß" ratsam, die Texte mit der/dem eigenen Beauftragten abzustimmen und bei Bedarf die jeweiligen Übersetzungen individuell anzupassen. Das lässt Drupal ja zu und dann sollte man darauf achten bei Übersetzungs-Updates diese nicht zu überschreiben.
Sich bei dieser Übersetzung aber ein wenig an anderen Standard Tools zu orientieren, reduziert aber vllt. die Wahrscheinlichkeit individuell die Texte anpassen zu müssen.

@Munavijayalakshmi Thanks for fixing and @das-peter thanks for the review.
The patch also looks fine for me so I commit it.

@smustgrave Thanks for committing. If I find some time I plan to check for some more scenarios on the file permissions. And in any case it is still a good idea to get test coverage.

I just found this Issue and wondering why the contrib module " EntityReference UUID → " isn't mentioned here. This already uses "target_uuid" . I use it for example for a base field definition in my contrib module " grant → ". But it also have an UI for Field API. I hope EntityReference UUID will find its way into core.