During kernel tests, ExtensionDiscovery is set up with the site directory, ORIGIN_SITE, as a virtual filesystem. This means the $searchDir item for this is of the form 'vfs://root/sites/simpletest/28733299'.

However, scanDirectory() doesn't manage to find anything in this, because it treats all the directories as being relative, and prefixes them all with the root:

    $dir_prefix = ($dir == '' ? '' : "$dir/");
    $absolute_dir = ($dir == '' ? $this->root : $this->root . "/$dir");

That means we end up with the directory '/Users/me/whatever/etc/vfs://root/sites/simpletest/28733299' which is broken.

Issue fork drupal-2961541

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

Comments

joachim created an issue. See original summary.

joachim’s picture

dawehner’s picture

Thank you for the patch!
I'm currently looking at \Drupal\Tests\Core\Extension\ExtensionDiscoveryTest as it is using VFS already. Do you think it would be possible to extend the test coverage?

dawehner’s picture

Issue tags: +Needs tests
joachim’s picture

> Do you think it would be possible to extend the test coverage?

One thing to bear in mind is that ExtensionDiscovery keeps a static cache, and you can't clear it during a request, or for that matter, during a Kernel test.

Over at Drupal Code Builder, I wrote Kernel tests that write a module to the vfsStream filesystem, and then try to enable it. I had to resort to using PHP Reflection to get ExtensionDiscovery to notice the new module -- see https://github.com/drupal-code-builder/drupal-code-builder/blob/3.2.x/Te...

dawehner’s picture

One thing to bear in mind is that ExtensionDiscovery keeps a static cache, and you can't clear it during a request, or for that matter, during a Kernel test.

Yeah maybe we should indeed add a mechanism to reset it. Its output also depends on the current installation profile, so its result might change.

Version: 8.6.x-dev » 8.7.x-dev

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

wim leers’s picture

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

smustgrave’s picture

Status: Needs review » Needs work
Issue tags: +Needs Review Queue Initiative, +Needs issue summary update

This issue is being reviewed by the kind folks in Slack, #needs-review-queue-initiative. We are working to keep the size of Needs Review queue [2700+ issues] to around 400 (1 month or less), following Review a patch or merge request as a guide.

For the tests requested in #4

Also should follow the default template for an issue summary please.

joachim’s picture

Rebase on 10.1.x and made a MR.

Still needs test.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

wim leers’s picture

Maybe deleting the work-around in \Drupal\Tests\ckeditor5\Kernel\CKEditor5PluginManagerTest which was necessary before this fix is enough to prove it now works — maybe we don't really need explicit test coverage for such a detail? 😇

Unless it fails, of course.

😱 Which it does!

wim leers’s picture

Looks like the static file cache in \Drupal\Core\Extension\ExtensionDiscovery is still a problem. There's no way to wipe that.

wim leers’s picture

Assigned: Unassigned » wim leers

Worked on this again for #3401837: Add basic validation to config schema definitions. I'm pretty sure I have a solution now. 🤓

wim leers’s picture

Assigned: wim leers » Unassigned
Status: Needs work » Needs review
wim leers’s picture

Hm, looks like the CKEditor 5 plugin manager test is extra complicated due to \Drupal\ckeditor5\Plugin\CKEditor5PluginDefinition::getTypedConfig() using the (global) container, which contains some static caches that get in the way. 😬

borisson_’s picture

Status: Needs review » Needs work

Back to needs work to correctly reflect the current state.
I see that you also implemented this fix (or at least the \Drupal::root call) in #3401837: Add basic validation to config schema definitions, does that mean we close this as a duplicate or do we want to keep this open?

wim leers’s picture

We should keep this open: this issue is specifically scoped to fix this problem, in #3401837 I had no choice but to figure out a solution for this. Ideally we'd be able to remove this change from #3401837 to allow a tighter scope 😇

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.