🇩🇪Germany @Peter Majmesku

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

Released in 1.0.0-alpha5: https://www.drupal.org/project/sites_migrator/releases/1.0.0-alpha5 →

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

There is a Drupal 10 and 11 release now: https://www.drupal.org/project/simple_comment_email_notification/release... →

There is a Drupal 10 and 11 release now: https://www.drupal.org/project/simple_comment_email_notification/release... →

peter majmesku → created an issue.

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

peter majmesku → created an issue.

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 →

peter majmesku → created an issue.

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).

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.

peter majmesku → created an issue.

The MR has been merged. Thanks!

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

peter majmesku → created an issue.

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

Can anyone of the maintainers please take a look?

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...

Drupal 11 version is already released.

This is now part of the 3.1.37 patch release: https://www.drupal.org/project/permissions_by_term/releases/3.1.37 →

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

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.

@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.

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.

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

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.

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.

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.

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.

peter majmesku → created an issue.

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?

peter majmesku → created an issue.

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.

Simple IP login is now compatible with Drupal 11.

Nice! 💪🎉🥳

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.

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...

@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.

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

Makes sense. 👍 We should ditch everything, which could be API breaking, after creating the first stable release.

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

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

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.

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

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.

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.

peter majmesku → created an issue.

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.

peter majmesku → created an issue.

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

peter majmesku → created an issue.

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

Thanks for your explanation!

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.

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.

peter majmesku → created an issue.

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.

Great! Thanks for the new minor release. 🥳🎉

> 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.

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.

peter majmesku → created an issue.

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

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.

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.

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?

peter majmesku → created an issue.

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

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

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.

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.

This issue is outdated. Please use the latest version (3.1.35). https://www.drupal.org/project/permissions_by_term/releases/3.1.35 →

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?

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.

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

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... →

Updated example for hook_file_download().

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

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

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.

Created release 3.1.35 → which is now supporting Drupal 11.

@somersoft, mark_fullmer, erutan, bradallenfisher:

I’ve made several changes, and the module is now installable on Drupal 11. I conducted a few tests, and everything worked as expected. However, I’m not finished yet. Could you please do some testing and provide feedback in the meantime?

peter majmesku → made their first commit to this issue’s fork.

peter majmesku → created an issue.

peter majmesku → created an issue.

MeToo 👍🏻