šŸ‡©šŸ‡ŖGermany @Peter Majmesku

šŸ‡©šŸ‡ŖDüsseldorf
Account created on 19 April 2010, about 15 years ago
#

Merge Requests

More

Recent comments

šŸ‡©šŸ‡ŖGermany Peter Majmesku šŸ‡©šŸ‡ŖDüsseldorf

peter majmesku → created an issue.

šŸ‡©šŸ‡ŖGermany Peter Majmesku šŸ‡©šŸ‡ŖDüsseldorf

Fixed in the current release.

šŸ‡©šŸ‡ŖGermany Peter Majmesku šŸ‡©šŸ‡ŖDüsseldorf

I could not push into the existing MR. Even with requested push access. What do you mean with issue summary?

šŸ‡©šŸ‡ŖGermany Peter Majmesku šŸ‡©šŸ‡ŖDüsseldorf

Looks fine. I fixed spelling. Improved the explanation and line breaks. Can this small change could be merged, please?

šŸ‡©šŸ‡ŖGermany Peter Majmesku šŸ‡©šŸ‡ŖDüsseldorf

I can confirm that the patch from #20 does also work, if applied against version 4.2.2.

šŸ‡©šŸ‡ŖGermany Peter Majmesku šŸ‡©šŸ‡ŖDüsseldorf

A litte bit late. :) That would not make the module so simple. There is already the site e-mail. That's enough.

šŸ‡©šŸ‡ŖGermany Peter Majmesku šŸ‡©šŸ‡ŖDüsseldorf

peter majmesku → created an issue.

šŸ‡©šŸ‡ŖGermany Peter Majmesku šŸ‡©šŸ‡ŖDüsseldorf

Duplicate of https://www.drupal.org/project/sites_migrator/issues/3513367 ✨ Support menu migration from the domain module Active

šŸ‡©šŸ‡ŖGermany Peter Majmesku šŸ‡©šŸ‡ŖDüsseldorf

Hi @robbiehobby!

Thanks for testing. I've created a new release (1.2.0) with that patch: https://www.drupal.org/project/entity_definition_update/releases/1.2.0 →

šŸ‡©šŸ‡ŖGermany Peter Majmesku šŸ‡©šŸ‡ŖDüsseldorf

The circumstances are different. The MR is against the 4.x-dev branch. There it works. Against version 4.2.2 it just does not apply. Because there are various changes in the 4.x-dev branch which differ from the 4.2.2 release.

I do recommend to merge the changes in 4.x-dev and then create an new patch release (e.g. 4.2.3).

šŸ‡©šŸ‡ŖGermany Peter Majmesku šŸ‡©šŸ‡ŖDüsseldorf

This changes currently do not work. If I do open the config page at /admin/config/search/simplesitemap, then I do get this error:

PHP message: Uncaught PHP Exception Symfony\Component\DependencyInjection\Exception\AutowiringFailedException: "Cannot autowire service "Drupal\simple_sitemap\Manager\Generator": argument "$generator" of method "Drupal\simple_sitemap\Form\StatusForm::_construct()", you should configure its value explicitly.

Tested with version 4.2.2 of simple sitemap.

šŸ‡©šŸ‡ŖGermany Peter Majmesku šŸ‡©šŸ‡ŖDüsseldorf

peter majmesku → created an issue.

šŸ‡©šŸ‡ŖGermany Peter Majmesku šŸ‡©šŸ‡ŖDüsseldorf

The MR has been merged. Thanks!

šŸ‡©šŸ‡ŖGermany Peter Majmesku šŸ‡©šŸ‡ŖDüsseldorf

Testing notes:

1. Enable the modules first:
1. ddev drush en sites_group -y
2. ddev drush en sites_migrator -y
3. ddev drush cr
2. Migrate the config
1. ddev drush sites-migrator:migrate-menu-config main
3. Enable Menüs for your site: /admin/group/types/manage/site/content
1. Note: here you might see an error "bundle null error". There might be a broken entity, because it has no bundle. That could be postponed. After you oben the site config anew, you'll see the enabled menu.
4. MIgrate the content
1. ddev drush sites-migrator:migrate-menu-content main 1 group_main "Test main navigation"
5. Now you'll see the migrated content in your new menu: /group/1/menu/1/edit

šŸ‡©šŸ‡ŖGermany Peter Majmesku šŸ‡©šŸ‡ŖDüsseldorf

peter majmesku → created an issue.

šŸ‡©šŸ‡ŖGermany Peter Majmesku šŸ‡©šŸ‡ŖDüsseldorf

For me this looks like a possible solution. Thanks for providing your changes.

Can anyone of the maintainers please take a look?

šŸ‡©šŸ‡ŖGermany Peter Majmesku šŸ‡©šŸ‡ŖDüsseldorf

I have fixed the pipelines meanwhile. There were some incompatibilities with older PHP versions, PHPCS and PHPStan errors etc. I've cleaned that. The pipeline for the latest release is fine. See https://git.drupalcode.org/project/permissions_by_term/-/commit/890eff8c...

šŸ‡©šŸ‡ŖGermany Peter Majmesku šŸ‡©šŸ‡ŖDüsseldorf

Drupal 11 version is already released.

šŸ‡©šŸ‡ŖGermany Peter Majmesku šŸ‡©šŸ‡ŖDüsseldorf

Merge request review is easier than patch review. Just hit the "create issue fork" button at the top of this page.

šŸ‡©šŸ‡ŖGermany Peter Majmesku šŸ‡©šŸ‡ŖDüsseldorf

Okay, thanks for your input. I do understand, that there is a mismatch between the config and permission setting. Then there should be a permission and config check in the merge request. This should be combined in one if-case. Feel free to provide a merge request and link it here. I can review it.

šŸ‡©šŸ‡ŖGermany Peter Majmesku šŸ‡©šŸ‡ŖDüsseldorf

@tyapchyc First of all: thanks for working on this.

See my comments in your MR. We need a test which proves any fix here. PHPCS validation is currently failing. PHPCBF might help here.

šŸ‡©šŸ‡ŖGermany Peter Majmesku šŸ‡©šŸ‡ŖDüsseldorf

Hi pemson18, sorry - I do not follow. The config is global. This means that the config controls the form for all users. I think that's the intended behavior. Please provide more context, if you mean anything else.

šŸ‡©šŸ‡ŖGermany Peter Majmesku šŸ‡©šŸ‡ŖDüsseldorf

This does also work in the latest version. Please apply the patch into the project. Otherwise it is bloating the logs.

šŸ‡©šŸ‡ŖGermany Peter Majmesku šŸ‡©šŸ‡ŖDüsseldorf

I do not experience any issue here. If I switch the setting on or off via the settings form, I do see the expected behavior. The functionality works like designed.

See attached screenshots for clarification.

If you do experience an issue here:
* Please provide step-by-step instructions for the ability to reproduce this issue on a plain Drupal site with PbT installed.
* If you do have code changes: please create a issue fork with a merge request. That way code changes can be easily discussed via in-code comments.


šŸ‡©šŸ‡ŖGermany Peter Majmesku šŸ‡©šŸ‡ŖDüsseldorf

Dou cannot just add a return statement here. It breaks the entire function. Also how any error can be reproduced here? I have tested this.

šŸ‡©šŸ‡ŖGermany Peter Majmesku šŸ‡©šŸ‡ŖDüsseldorf

I've added the changes to the new patch version release 3.1.36: https://www.drupal.org/project/permissions_by_term/releases/3.1.36 →

Please test the updates and reopen this issue and create a comment, if you stumble upon any issue with this update.

šŸ‡©šŸ‡ŖGermany Peter Majmesku šŸ‡©šŸ‡ŖDüsseldorf

Thanks for your patch. I have reviewed it.

1. permissions_by_term_form_node_form_alter: Here you stopping the function via your return statement at the top of the function. That way you are removing all other functionality. E.g. the form access controlling.
2. In the `SettingsForm.php` the default value for the "hide_terms_permissions_info_in_node_form" setting is true. But actually the value is not set, if the setting has not been saved manually, yet.

šŸ‡©šŸ‡ŖGermany Peter Majmesku šŸ‡©šŸ‡ŖDüsseldorf

peter majmesku → created an issue.

šŸ‡©šŸ‡ŖGermany Peter Majmesku šŸ‡©šŸ‡ŖDüsseldorf

If I do install group_content_menu_bundles with the issue fork, which is just requiring menu_item_extras in version 3.1.0, then I do get that error:

drush en group_content_menu_bundles -y
The following module(s) will be installed: group_content_menu_bundles, menu_item_extras

// Do you want to continue?: yes.

In SqlContentEntityStorageSchema.php line 1843:

The SQL storage cannot change the schema for an existing field (bundle in menu_link_content entity) with data.

Failed to run drush en group_content_menu_bundles -y: exit status 1

Do you know any solution for this already?

šŸ‡©šŸ‡ŖGermany Peter Majmesku šŸ‡©šŸ‡ŖDüsseldorf

I've encountered this issue, as I liked to install a groups config via recipe, before the group module was installed. Installing the group module upfront helped.

šŸ‡©šŸ‡ŖGermany Peter Majmesku šŸ‡©šŸ‡ŖDüsseldorf

Simple IP login is now compatible with Drupal 11.

šŸ‡©šŸ‡ŖGermany Peter Majmesku šŸ‡©šŸ‡ŖDüsseldorf
šŸ‡©šŸ‡ŖGermany Peter Majmesku šŸ‡©šŸ‡ŖDüsseldorf

Nice! šŸ’ŖšŸŽ‰šŸ„³

šŸ‡©šŸ‡ŖGermany Peter Majmesku šŸ‡©šŸ‡ŖDüsseldorf

Thanks again for testing. I feel that we are close. :)

I've resolved your notices. The return type declarations are reverted to the previous state, where they are not causing errors. Please test again.

šŸ‡©šŸ‡ŖGermany Peter Majmesku šŸ‡©šŸ‡ŖDüsseldorf

I found a solution regarding to custom exposed filters and the pager counter, which might help you.

There is this Pager-ID field in the views pager settings. After trying a couple things, I've tried to set a different numeric ID there, too. Afterwards this pager and other pagers worked correctly. The description of this field also already suggests, that it can help, if there are "problems". So there might be some side effects, which can be worked around by this field setting. Maybe this information helps others also.

Lost a couple of hours with this not quite intuitive pager behavior in views...

šŸ‡©šŸ‡ŖGermany Peter Majmesku šŸ‡©šŸ‡ŖDüsseldorf

@harlor: Thanks for your hints and the suggested changes. šŸ‘ I've tested the module manually on a local Drupal playground site and there were no errors. The tests are all green. Please review.

šŸ‡©šŸ‡ŖGermany Peter Majmesku šŸ‡©šŸ‡ŖDüsseldorf

@harlor: I resolved all your notices. Please review.

šŸ‡©šŸ‡ŖGermany Peter Majmesku šŸ‡©šŸ‡ŖDüsseldorf
šŸ‡©šŸ‡ŖGermany Peter Majmesku šŸ‡©šŸ‡ŖDüsseldorf

Makes sense. šŸ‘ We should ditch everything, which could be API breaking, after creating the first stable release.

šŸ‡©šŸ‡ŖGermany Peter Majmesku šŸ‡©šŸ‡ŖDüsseldorf

@harlor: I have answered on your notices. Could you please review again?

šŸ‡©šŸ‡ŖGermany Peter Majmesku šŸ‡©šŸ‡ŖDüsseldorf

Ah, I've seen your notices for the merge request. Let me check them.

šŸ‡©šŸ‡ŖGermany Peter Majmesku šŸ‡©šŸ‡ŖDüsseldorf

The static code analysis is also tests. It's tests without explicit written tests. That way the Drupal coding standards are proven. You are loosing nothing here. I would like to ask you kindly about merging.

šŸ‡©šŸ‡ŖGermany Peter Majmesku šŸ‡©šŸ‡ŖDüsseldorf

After I installed the validator dependency from the following issue, I could see the progress in my database table: https://www.drupal.org/project/opigno_scorm/issues/3281986 šŸ› opis/json-schema dependency missing Needs review

šŸ‡©šŸ‡ŖGermany Peter Majmesku šŸ‡©šŸ‡ŖDüsseldorf

I cannot reproduce that. Installed a fresh Drupal site and I do not see this error:

āžœ  drupal-10-pbt d drush en permissions_by_term -y
>  [notice] Message: The content access permissions have been rebuilt.
>
 [success] Module permissions_by_term has been installed. (Help - Permissions - Configure)
āžœ  drupal-10-pbt d drush cr
 [success] Cache rebuild complete.
āžœ  drupal-10-pbt d launch
āžœ  drupal-10-pbt d composer show | grep drupal/core
drupal/core                              10.4.1  Drupal is an open source content management platform powering millions of websi...
drupal/core-composer-scaffold            10.4.1  A flexible Composer project scaffold builder.
drupal/core-project-message              10.4.1  Adds a message after Composer installation.
drupal/core-recommended                  10.4.1  Core and its dependencies with known-compatible minor versions. Require this pr...
āžœ  drupal-10-pbt   

You might check your individual Drupal website. Maybe this error is tight to individual implementations. If you are able to break down the error, then you could a provide a step-by-step instruction to reproduce the error in a basic Drupal 10 site. There is no error visible after a ordinary module installation.

šŸ‡©šŸ‡ŖGermany Peter Majmesku šŸ‡©šŸ‡ŖDüsseldorf

I do also confirm that the changes from the MR do work for my project.

You must be careful, that you really install the ^2.3 version and not just the latest version. Because the latest version of opis/json-schema cannot be auto-loaded via composer.

šŸ‡©šŸ‡ŖGermany Peter Majmesku šŸ‡©šŸ‡ŖDüsseldorf

peter majmesku → created an issue.

šŸ‡©šŸ‡ŖGermany Peter Majmesku šŸ‡©šŸ‡ŖDüsseldorf

Added tests in the related issue: https://www.drupal.org/project/form_decorator/issues/3499316 šŸ“Œ Add test for example module Active

I am considering this issue here as a duplicate now.

šŸ‡©šŸ‡ŖGermany Peter Majmesku šŸ‡©šŸ‡ŖDüsseldorf
šŸ‡©šŸ‡ŖGermany Peter Majmesku šŸ‡©šŸ‡ŖDüsseldorf

peter majmesku → created an issue.

šŸ‡©šŸ‡ŖGermany Peter Majmesku šŸ‡©šŸ‡ŖDüsseldorf

I am done with my changes. Please review. I made the following changes:

* Fixed Drupal coding standards and Drupal practices
* Implemented static code analysis via PHPStan and PHPCS
* Added testing via PHPUnit. The test proves if a new form field is attached via form_decorator_example with the API that form_decorator provides
* Spellchecker via cspell

šŸ‡©šŸ‡ŖGermany Peter Majmesku šŸ‡©šŸ‡ŖDüsseldorf

peter majmesku → created an issue.

šŸ‡©šŸ‡ŖGermany Peter Majmesku šŸ‡©šŸ‡ŖDüsseldorf

@hydra: Merged in the current 1.x branch and made the pipelines pass. Please review.

šŸ‡©šŸ‡ŖGermany Peter Majmesku šŸ‡©šŸ‡ŖDüsseldorf

Thanks for your explanation!

šŸ‡©šŸ‡ŖGermany Peter Majmesku šŸ‡©šŸ‡ŖDüsseldorf

I read your list for reproduction. If there is just a term related with the node, but no permissions for the term are set, then there is no permission restriction.

šŸ‡©šŸ‡ŖGermany Peter Majmesku šŸ‡©šŸ‡ŖDüsseldorf

Hi crutch, it looks like your database server reached limits. Yes, PbT needs some resources on the database site. Even we do have already optimized here really a lot. From your report I do not see, how PbT could be optimized more, to help you out.

It might be a good approach to check the database server resources and configs there.

max_statement_time setting in your my.cnf could be a place to optimize your database server settings. E.g.:

[mysqld]
max_statement_time = 300 # 5 minutes

However, database server optimization is not in the scope of the PbT module. That is a different topic.

šŸ‡©šŸ‡ŖGermany Peter Majmesku šŸ‡©šŸ‡ŖDüsseldorf

peter majmesku → created an issue.

šŸ‡©šŸ‡ŖGermany Peter Majmesku šŸ‡©šŸ‡ŖDüsseldorf

I've implemented the GitLab CI pipeline configuration. It handles the static code analysis via PHP_CodeSniffer and PHPStan. This required some code and documentation changes to comply with the standards. All pipelines now pass. The code validation jobs are allowed to fail; this is the default behavior. I recommend always making sure that the jobs succeed. This essentially eliminates all syntax, spelling, and coding standard violations. Please review.

šŸ‡©šŸ‡ŖGermany Peter Majmesku šŸ‡©šŸ‡ŖDüsseldorf

Great! Thanks for the new minor release. šŸ„³šŸŽ‰

šŸ‡©šŸ‡ŖGermany Peter Majmesku šŸ‡©šŸ‡ŖDüsseldorf

> We won't fix the phpcs issues in this branch anymore. A new version is coming with a new UI and fixed coding styles :)

I would like to see code style issues handled via pipeline. There are not many violations which need manual coding, so this could be resolved relatively quick. Drafted a MR for this in #3496183 (Static code analysis) → . So you could merge the pipeline config into your branch with the UI, if you like. However, I am pausing work on this issue for now. Just let me know, when it's reasonable to continue with this.

Do you like the current code changes, regarding the select form widget? Would be nice, if we could close this issue.

šŸ‡©šŸ‡ŖGermany Peter Majmesku šŸ‡©šŸ‡ŖDüsseldorf

Thanks for your feedback! I did the requested changes. Your mentioned docblock comments and newline stuffs etc. is fixed. I also replied to your questions.

The phpcs stuff could be handled in https://www.drupal.org/project/slots/issues/3496183 ✨ Static code analysis Active so it could be just pointed by the CI pipeline. I run PHPCS against the module and there are already lots of other violations against the Drupal coding standard. Most of them could be fixed automatically. So I executed phpcbf to fix them, too.

The comments I wrote manually. However, I am not a friend of this docblock comments. I am more for good variable names, readable and also validated code. Doc comments can easily get legacy and misleading over time.

šŸ‡©šŸ‡ŖGermany Peter Majmesku šŸ‡©šŸ‡ŖDüsseldorf
šŸ‡©šŸ‡ŖGermany Peter Majmesku šŸ‡©šŸ‡ŖDüsseldorf

peter majmesku → created an issue.

šŸ‡©šŸ‡ŖGermany Peter Majmesku šŸ‡©šŸ‡ŖDüsseldorf

Hi hydra! I've done the refactoring, based on your feedback. There's also a merge request now. Please check.

šŸ‡©šŸ‡ŖGermany Peter Majmesku šŸ‡©šŸ‡ŖDüsseldorf

Thx again for the exchange. šŸ‘ I've introduced the key-value store. The SlotsService::buildSlot() didn't brought up all slots, which are rendered on one particular page. Therefor the Slots module is now collecting the slot ids via SlotBlock::build() method. Please review the changes.

šŸ‡©šŸ‡ŖGermany Peter Majmesku šŸ‡©šŸ‡ŖDüsseldorf

You need to enter the slot_id as a condition value

Thanks for the hint! šŸ‘ I've improved the code within the issue fork and now it works. You can select the slot block via its readable block id:

After saving the block content, the content will appear in the slot:

See the related code changes here: https://git.drupalcode.org/issue/slots-3495680/-/commit/440778a95942f877...

I mailed you my contact data :)

I have not received anything, yet. Checked the contact function on d.o for my correct e-mail address and took a look into my spambox. I'll email you my e-mail address.

šŸ‡©šŸ‡ŖGermany Peter Majmesku šŸ‡©šŸ‡ŖDüsseldorf

See my issue fork changes. Please review and give feedback.

I modified the form element type from machine name to select and provided the slot configs as options. At least the selection part in the custom block content does work now:

After I do save the block content, the placeholder text for the slot still appears:

Maybe anyone of the maintainers can check, why the block display via the selected slot does not work?

šŸ‡©šŸ‡ŖGermany Peter Majmesku šŸ‡©šŸ‡ŖDüsseldorf

peter majmesku → created an issue.

šŸ‡©šŸ‡ŖGermany Peter Majmesku šŸ‡©šŸ‡ŖDüsseldorf

> If you'd like to contribute, let's get in touch!

Sure, I've sent you a PM via your user profile.

šŸ‡©šŸ‡ŖGermany Peter Majmesku šŸ‡©šŸ‡ŖDüsseldorf

I've tested slots and they look really promising. In my previous project, we anticipated blocks that were intended to be filled in the future.

However, I strongly advocate for improving the form display widgets for the slot selector in the custom block type. Typing a unique ID into a text field every time feels somewhat "hackish" and isn't intuitive enough for content editors, in my opinion. It would be great if the site builder could choose either a select or autocomplete widget here for custom blocks.

šŸ‡©šŸ‡ŖGermany Peter Majmesku šŸ‡©šŸ‡ŖDüsseldorf

Thanks for sharing this information. I am really not able to reproduce your issue. I've also installed link_attributes and the exlink modules. Then I added a linkfield to my node. I was able to edit the node, without any exception.

Maybe you can solve your issue by checking the PHP version. Please make sure, that you are using a supported PHP version. I recommend using the latest stable PHP version: 8.3. The oldest supported PHP version is 8.1.

I have seen, that you are working with XAMPP on Windows. I really recommend using DDEV: https://ddev.com/. On Windows you can use DDEV via WSL2. This works pretty well.

šŸ‡©šŸ‡ŖGermany Peter Majmesku šŸ‡©šŸ‡ŖDüsseldorf

I cannot reproduce this. The error comes from Drupal core and not the PbT module. It could help, if you could check if there is more debug information in your log.

* Do you have any link or url specific contrib modules installed?
* important: Which field types does this node have? Is there the link field type?
* Does this error come up on other node types?
* Is this node protected by PbT via term relation?

šŸ‡©šŸ‡ŖGermany Peter Majmesku šŸ‡©šŸ‡ŖDüsseldorf

Yes, the dependencies are resolved via cache flush (e.g. "drush cr"). I re-checked this by signing in into a newly installed Drupal 11 site with PbT installed. It worked. The error can't be reproduced. Therefor I am closing this issue.

šŸ‡©šŸ‡ŖGermany Peter Majmesku šŸ‡©šŸ‡ŖDüsseldorf

Do you see the error on a specific page? I have tested the module. Please provide details.

šŸ‡©šŸ‡ŖGermany Peter Majmesku šŸ‡©šŸ‡ŖDüsseldorf

Hi f2boot, I followed your description and tried to reproduce your issue.

However, it works on my end.

* I activate the "Require all terms granted" setting
* I do relate a media entity with terms
* I do set permissions for that terms
* I do access the file, which is related to my media, directly
* I try the access as guest user and admin user
* I do experience the expected result

Please notice, that files must be stored in the private filesystem to get secured. Also you must write your own hook_file_download() implementation.

E.g:

/**
 * Implements hook_file_download().
 */
function fancy_module_media_document_file_download(string $uri) {
  $files = \Drupal::entityTypeManager()
    ->getStorage('file')
    ->loadByProperties(['uri' => $uri]);

  foreach ($files as $file) {
    $multipleMedia = \Drupal::entityTypeManager()
      ->getStorage('media')
      ->loadByProperties(['field_media_file.target_id' => $file->id()]);

    $oneMedia = reset($multipleMedia);

    if ($oneMedia instanceof \Drupal\media\MediaInterface) {
      /** @var \Drupal\permissions_by_entity\AccessChecker $accessChecker */
      $accessChecker = \Drupal::service('permissions_by_entity.access_checker');
      $isAllowed = $accessChecker->isAccessAllowed($oneMedia);

      if (!$isAllowed) {
        throw new \Symfony\Component\HttpKernel\Exception\AccessDeniedHttpException();
      }
    }
  }

}

You can find more detailed description about securing documents in your filesystem by PbT in the documentation: https://www.drupal.org/docs/extending-drupal/contributed-modules/contrib... →

šŸ‡©šŸ‡ŖGermany Peter Majmesku šŸ‡©šŸ‡ŖDüsseldorf

Updated example for hook_file_download().

šŸ‡©šŸ‡ŖGermany Peter Majmesku šŸ‡©šŸ‡ŖDüsseldorf

Unfortunately I am not able to reproduce it.

* Installed a new D11 site with PbE installed.
* Set "Require all terms granted" setting
* Referenced two terms to this media: admin role only, editor role only
* Referenced the media to a node
* Afterwards I was able to view the node and the related media as admin user

šŸ‡©šŸ‡ŖGermany Peter Majmesku šŸ‡©šŸ‡ŖDüsseldorf

Does this error also occur with version 3.1.35? Please check.

šŸ‡©šŸ‡ŖGermany Peter Majmesku šŸ‡©šŸ‡ŖDüsseldorf

Please do me a favor and test the latest patch release. Feel free to re-open this issue, if you stumble upon any Drupal 11 related issues.

šŸ‡©šŸ‡ŖGermany Peter Majmesku šŸ‡©šŸ‡ŖDüsseldorf

Created release 3.1.35 → which is now supporting Drupal 11.

Production build 0.71.5 2024