🇨🇦Canada @bsuttis

@smustgrave I rebased again (2 new commits since yesterday) and latest test is now green: https://git.drupalcode.org/issue/drupal-3384600/-/pipelines/310491

@smustgrave what's the protocol when the fails appear to be non-MR related? For example, https://git.drupalcode.org/issue/drupal-3384600/-/jobs/3051456 shows a fail in Drupal\Tests\Core\Recipe\RecipeQuickStartTest::testQuickStartRecipeCommand

Is this an indication the 10.4.x branch that was rebased on is not up-to-date? Or a problem with the 10.4.x branch? I'm pretty sure I rebased on its latest commit at the time (dc4a5f9e0a0).

@catch confirming I rebased and removed the deprecation code for the 10.4.x branch. There are failing tests but they aren't related to these changes.

@pearls I had an issue that I thought was similar to yours and the MR fixes my issue.

In my logs were:
Warning: Undefined array key 0 in wordfilter_entity_display_build_alter() in line 182
Warning: Trying to access array offset on value of type null in wordfilter_entity_display_build_alter() in line 182

I guess yours is a separate issue. I was unable to reproduce yours on core 10.3.5/php 8.2.

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

Confirming MR 51's changes fix the issue for me as well.

@vladimiraus I found the patch at https://www.drupal.org/project/taxonomy_manager/issues/3474919 🐛 Form element taxonomy_manager_tree broken RTBC fixed the broken functionality.

The MR patch here (#3467549) combined with the MR patch there (#3474919) has it working via CDN in my tests.

To use the fancytree library locally, I find I still have to edit my project's main composer.json like so:

...
        "merge-plugin": {
            "include": [
                "docroot/modules/custom/*/composer.json",
                "docroot/modules/contrib/taxonomy_manager/composer.libraries.json"
            ],
        },
...

(note: I have wikimedia/composer-merge-plugin installed)

and then run composer require fancytree/fancytree -W to install it locally to /docroot/libraries. Is this the correct process?

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

Given @Berdir and @catch's profiling comments and my updates to the deprecation (10.4-to-11.1), I'm setting this to NR.

I wrote a test for the deprecation before seeing the latest comment above. I won't commit it but am including it here in case.

I added it to core/modules/comment/tests/src/Kernel/CommentTypeValidationTest.php. Do let me know if there's a better location.

<?php

declare(strict_types=1);

namespace Drupal\Tests\comment\Kernel;

use Drupal\comment\Entity\CommentType;
use Drupal\Core\Entity\EntityTypeInterface;
use Drupal\Core\Entity\EntityTypeManagerInterface;
use Drupal\KernelTests\Core\Config\ConfigEntityValidationTestBase;
use Drupal\user\Entity\EntityPermissionsRouteProviderWithCheck;

/**
 * Tests validation of comment_type entities.
 *
 * @group comment
 */
class CommentTypeValidationTest extends ConfigEntityValidationTestBase {

  ...[code omitted]...

  /**
   * Test route provider deprecation.
   *
   * @covers \Drupal\user\Entity\EntityPermissionsRouteProviderWithCheck
   *
   * @group legacy
   */
  public function testEntityPermissionsRouteProviderWithCheck(): void {
    $this->expectDeprecation('Drupal\user\Entity\EntityPermissionsRouteProviderWithCheck is deprecated in drupal:10.4.0 and is removed from drupal:12.0.0. Use EntityPermissionsRouteProvider instead. See https://www.drupal.org/node/3384745');

    // Mock the constructor parameters.
    $prophecy = $this->prophesize(EntityTypeInterface::class);
    $prophecy->getPermissionGranularity()
      ->willReturn('entity_type');
    $entity_type = $prophecy->reveal();
    $prophecy = $this->prophesize(EntityTypeManagerInterface::class);
    $prophecy->getDefinition('entity_type')
      ->willReturn($entity_type);
    $entity_type_manager = $prophecy->reveal();
    $bundle_form = new EntityPermissionsRouteProviderWithCheck($entity_type_manager);

    // Mock the method parameters.
    $prophecy = $this->prophesize(EntityTypeInterface::class);
    $entity_type = $prophecy->reveal();

    $class = new \ReflectionClass(EntityPermissionsRouteProviderWithCheck::class);
    $instance_method = $class->getMethod('getEntityPermissionsRoute');
    $instance_method->invoke($bundle_form, $entity_type);
  }
}

This might not be the best approach but it does trigger the deprecation and passes testing on my local. I have updated the comment to remove reference to EntityPermissionsRouteProviderWithCheck. grep doesn't bring up any other mentions of it in comments.

Re: manual testing, @benjifisher do you want benchmarks or more people to test and confirm here?

@benjifisher @Berdir I've added an expectDeprecation check on the unit test that covers \Drupal\user\Form\EntityPermissionsForm::access().

Does the deprecation in EntityPermissionsRouteProviderWithCheck also need a test?

I also updated the 10.3.x branch. Setting to NR.

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

Confirming rules 4.0.x is working on a project of mine running 10.3.1, thanks @TR.

bsuttis → changed the visibility of the branch 3461559-10.3-convert-rulesaction to active.

bsuttis → changed the visibility of the branch 3461559-10.3-convert-rulesaction to hidden.

Confirming @benjifisher's updates to the IS match the bug I encountered after the 10.3.0 upgrade and the latest MR passes testing locally for me.

Thanks for the explanation in #66 too.

I also hit this bug after upgrading to 10.3.0 and I found https://www.drupal.org/project/drupal/issues/3384600 🐛 Don't hide permissions local tasks on bundles when no permissions are defined Needs work to be closely related. I have an Article node type with a Comments field.

I found that the main cause of the "Entity view display 'node.article.default': Component..." log was using getConfigEntitiesToChangeOnDependencyRemoval instead of findConfigEntityDependenciesAsEntities in
EntityPermissionsForm::permissionsByProvider.

After applying the MR patch here and running EntityViewDisplayCommentArticleTest the test passes locally for me. Reverting the MR patch, the test fails as expected due to the "Entity view display 'node.article.default" log.

I also notice odd behaviour depending on the $comment_view_mode used in the test before the MR patch is applied.
- 'default' calls CommentDefaultFormatter::calculateDependencies() 3 times and the "Entity view display 'node.article.default" log occurs (bad)
- 'full' calls CommentDefaultFormatter::calculateDependencies() 1 time and the log does not occur (good)

Is there is some specialness to 'default' that I haven't tracked down yet? The MR patch solves this too.

I had the same problem this morning deploying to Acquia PROD. No issues on DEV or STG but after deployment to PROD I began to get 503s and this log: Error: Class "Drupal\bootstrap\Bootstrap" not found in include_once() (line 31 of .../themes/contrib/bootstrap/bootstrap.theme)

@tikaszvince, your workaround fixed the issue in my case as well, thanks.

It seems like a race condition to me. When I was testing, I was visiting /user and /user/register and sometimes they'd work and other times were a 503.

I hit this issue after updating to Slick 8.x-2.7

I can confirm the problem does not exist with 8.x-2.6 and slick.js 1.8.1 but after updating to 8.x-2.7 the problem occurs. I think it's related to the commit referenced in comment #7 (https://git.drupalcode.org/project/slick/-/commit/22fd2e3b8e1203489c023f...).

In particular, the change of:
var _element = '.' + _id + ':not(.' + _mounted + ')';

to:
var _element = '.' + _id;

I applied the patch provided in #7 and the error stopped. I was curious if it was an issue with Slick 1.8.1 so I downgraded the module to 8.x-2-6 but the error still occurred. I think this is an issue with the module code and not the Slick JS library.