🇩🇪Germany @kufliievskyi

I confirm that the template fix from the #21 comment works for me also. Looks like the most simple solution.

@poker10 Thank you for the reply. I've just opened an MR for that.
This MR fails with the errors which seem to be not related to the issue itself.
So I will keep this with the same status "Needs work" so someone can check.

The same question applies to the gin_toolbar module, but I've found only one header occurrence in it.
Don't want to create one more ticket at the moment, because the task requirements are quite debatable.
So in case someone wants to test both package updates, I've attached 2 simple patches for both gin/gin_toolbar.

In order to test them together this code snippet could be used:

{
  "patches": {
    "drupal/gin": {
      "Improve administrative gin theme heading semantics by replacing h tags with a <div>" : "./patches/gin/3492096-gin-improve-header-hierarchy.patch"
    },
    "drupal/gin_toolbar": {
      "Improve administrative gin_toolbar heading semantics by replacing h tags with a <div>" : "./patches/git_toolbar/3492096-gin-toolbar-improve-header-hierarchy.patch"
    }
  }

I appreciate it if someone with an accessibility background could leave a comment/review it. Thank you in advance for any comments.

kufliievskyi → created an issue.

kufliievskyi → created an issue.

kufliievskyi → created an issue.

Re-rolled the patch 26 against the new release(3.6), branch 8.x-3.x.
Works on Drupal 10.3.0 with Gin admin theme.

Thanks for the patch. I confirm that patch #6 fixes the issue. Tested on Drupal 10.3.0.

I've also checked this module on Drupal 10.3.0 installation. Confirm that #MR !1 works as expected.

@rcodina I have also noticed the issue in the tests/src/Functional/MigrateUiFieldGroupTest.php file while executing the tests.
The error I saw is this one:

1) Drupal\Tests\field_group_migrate\Functional\MigrateUiFieldGroupTest::testFieldGroupMigrate
Undefined array key "Drupal\sqlite\Driver\Database\sqlite"

/var/www/html/web/modules/contrib/field_group/contrib/field_group_migrate/tests/src/Functional/MigrateUiFieldGroupTest.php:135
/var/www/html/web/modules/contrib/field_group/contrib/field_group_migrate/tests/src/Functional/MigrateUiFieldGroupTest.php:157
/var/www/html/web/modules/contrib/field_group/contrib/field_group_migrate/tests/src/Functional/MigrateUiFieldGroupTest.php:59
/var/www/html/vendor/phpunit/phpunit/src/Framework/TestResult.php:728

But it seems to be not related to the fix and issue. I have just added

$class_name = substr(strrchr($driver, '\\'), 1);
$form = $drivers[$class_name]->getFormOptions($connection_options);

Instead of at line 135 in field_group/contrib/field_group_migrate/tests/src/Functional/MigrateUiFieldGroupTest.php
:

$form = $drivers[$driver]->getFormOptions($connection_options);

@rcodina Could you please specify the error you see in the tests? Or could probably someone else test it also?

The patch on #26 works well for me.

@marcoliver Everything works great for me.

Checked this PHPStan fixes. I haven't noticed any issues.
Executed the automation tests locally including Behat testing and manually.
All works as expected.
Also, no PHP errors have been found in the logs.

Reviewed. This fix works on the D10 website.
No issues were found.

Tried to reproduce this error, but had no luck. Probably that error was more server-specific and was caused because of the PHP execution time limit on the server.
I propose to close this task as not actual. Could be reopened later if it appears for someone else.

Confirm that I also noticed this on the 10.2.2 site and the patch fixed it.

Hi everyone!

I think this issue could be considered as a composer version constraint question.

Caret's "^" symbol allows the version to go up as expected.

When you see a caret constraint like ^3.0, it signifies that Composer is allowed to install any version of the package that is compatible with the specified version, but not including the next major version. The caret constraint follows the Semantic Versioning (SemVer) rules.

For example:

3.0.0 is allowed.
3.1.0 is allowed.
3.1.5 is allowed.
3.2.0 is allowed.
4.0.0 is not allowed.

https://getcomposer.org/doc/articles/versions.md#caret-version-range-

As a solution to the initial question (to support both Drupal 8 and Drupal 9), it's possible to use "~3.0" notation.
composer require 'drupal/permissions_by_term:~3.0'

With the tilde (~) operator, Composer will allow any version equal to or greater than 3.0.0 and less than 3.1.0. This indicates that only the minor version can vary within the 3.0 major version.

Here are some examples of what versions would be allowed:

3.0.0 is allowed.
3.0.1 is allowed.
3.0.5 is allowed.
3.1.0 is not allowed.

I suggest also closing this issue.

Environment:

Checked on the 3.1.x-dev branch, commit #a3bd434 (see screenshots).

Drupal version: 9.5.3

Tested using:

- Unit tests
- Behat tests
- Manually through the admin panel

Screenshots attached.

bin/phpunit --log-junit phpunit-report.xml --do-not-cache-result web/modules/contrib/permissions_by_term/tests
bin/behat --config=behat_dev.yml --colors --stop-on-failure ./web/modules/contrib/permissions_by_term/tests/src/Behat/Features

I suggest closing this issue because of the lack of description at the moment.

Testing steps

• Follow the testing section steps in the README.md module file.
• Run Behat execution command.

Behat execution command example:

bin/behat --config=behat.yml --colors --stop-on-failure ./web/modules/contrib/permissions_by_term/tests/src/Behat/Features

kufliievskyi → created an issue.

Checked https://git.drupalcode.org/project/permissions_by_term/-/merge_requests/..., PHPUnit tests are working.
Screenshot attached.
No code functionality is changed, so I suggest it's possible to merge it with no risk.

kufliievskyi → created an issue.