🇩🇪Germany @c-logemann

In 8+ version we there can be change to also cache ajax calls. But for everything we need someone to realize. Closing the issie for now.

It seems the questions how to solve this situation are answered. Closing for now.

I think this support request is outdated. The answer is: Yes, this can be done with boost but only for guest user.

@rp7
> Appears DER doesn't (always) automatically remove its database triggers

Because DER is using database triggers which are more complicate to handle especially in common managed hosting setups is the main reason why we wanted to get rid of it.

If there is a need for more views integration we can also implement this in linkchecker. Please open a follow up Issue for this and other missing features and merge requests are always welcome.

On the other side a domain based caching path inside is maybe enough for many multisite setups.

The solution for domains in cache file path is similar as on old D7 version. In this way multi domain is possible. But when thinking of multisite (which I didn't used since more than a decade) this can be solved with individual base caching paths configured in each multisite database. So I think we don't need extra support for this when setting a custom path ist working well. This needs a separate Issue I think. So let's focus on multi domain in this issue.

c-logemann → changed the visibility of the branch C-Logemann-1.0.x-patch-6d1c to hidden.

c-logemann → created an issue.

@davidiio
It is really easier to review code by just reading with the issue branches. But it's possible to check without installing. I think the core pint of the solution is this function:

/**
   * {@inheritdoc}
   */
  public function delete(\Drupal\Core\Entity\EntityInterface $entity) {
    foreach ($this->languageManager->getLanguages() as $langcode => $language) {
      $path = $this->pathAliasManager->getAliasByPath('/node/' . $entity->id(), $langcode);
      $uri = $this->boostCacheFile->getUri( '/' . $langcode . $path);
      if (!file_exists($uri)) {
        \Drupal::logger('boost')->error('Delete route @uri can not be done.',
          [
            '@uri' => $uri,
          ]
        );
        continue;
      }
      $this->boostCacheFile->delete($uri);
    }
  }

You start at entity hooks that works for all entity types but end up in a hard code node path alias solution?
This will lead to unwanted cache file deletions like this: Somebody is changing term/5 and your code will delete the boost cache alias for node/5.

I will not say that the code to retrieve entity paths is already perfect but it is open for alle aliased paths incl. terms for example.

I just wanted to test the patch on a cloned system but there the error was gone. The clone does not include caching information which would be very hard because of redis. So I just did a cache rebuild on the productive system and the error is gone.
My first plan was to hopefully repair the prod system with the patch and trying to switch between patched and unpatched code and analyze the two nodes in the trash list. But now it seems that the problem is more complex. Maybe this report helps others to understand a little bit more.

"Library Version" ist im Original schon eine Kurzform für "software library version". Das könnte man besser als "Version der Softwarebibliothek" übersetzen, wenn man denn möchte. Aber "Version" ist zu ungenau, insofern habe ich als Vorschlag "Library Version" eingereicht. An anderer Stelle steht dann aber wieder Bibliothek, wie ich dann bemerkt habe. Das sollte denke ich noch konsistent gemacht werden.

Ähnlich bei "Download", das meiner Meinung nach nicht übersetzt werden muss. Es gibt aber im Moment einen verwirrenden Mix aus beidem.

ich gehe das mal durch

Our customer just got the same problem. I will report when I found out more.

I just read again #3. I think I don't got i on the first read correct. As I understand now it that the captcha module should protect the site when there is a a lot site views like bots do. I'm not sure if this is possible in a non problematic way on direction of client and as a solution working only in one Drupal which should be protected in this way.
In any case firewall and ban are doing a complete access deny in Drupal and fail2ban on server firewall. But I think it's an interesting idea. To realize something like it would be easier without fail2ban but easier outside of the protected Drupal system where people are redirected to for example by an access protection module like firewall could be (patches welcome). And the other application would allow a kind of unlocking via captcha protected form with "telling" the protect Drupal to allow access again.

c-logemann → created an issue.

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'