alexpott → made their first commit to this issue’s fork.
I've pushed up a different approach. SImpe Oauth should not do routing beofre routing has occurred - that only fixes here that continue to support the route option will all be flawed and result in Drupal doing routing twice for every request.
I've just pushed an MR that does a simple exclude based on path using settings.
alexpott → made their first commit to this issue’s fork.
@smustgrave no that is not in scope. The scope is the
1) /builds/issue/drupal-3523596/core/modules/views/src/Plugin/views/field/FieldPluginBase.php:1696
Using null as an array offset is deprecated, use an empty string instead
deprecation.
Merged in HEAD because that deprecation is already fixed.
Committed and pushed 2b63f874753 to 11.x and 06d7aaadbe9 to 11.3.x. Thanks!
Nice - law threes - time for it to become API.
Committed and pushed 5071f112783 to 11.x and 13d4f6c1a39 to 11.3.x. Thanks!
I can see why you might want this though... but also @phenaproxima tells me an event subscriber can add it back in. So lets add a CR and tell people how to do that.
@andypost ideally we'd use the version core is shipping with once composer has done the initial install...
So locally
// If we're looking for Composer, use the project's local copy if available.
elseif ($name === 'composer') {
$path = $this->getLocalComposerPath();
if ($path && file_exists($path)) {
return $path;
}
in \Drupal\package_manager\ExecutableFinder so not result in using the local composer... because \Drupal\Composer\Plugin\VendorHardening\Config::$defaultConfig removes the composer bin by default.
Yep if I do composer self=update and run ./vendor/bin/phpunit core/modules/package_manager/tests/src/Kernel/PhpTufValidatorTest.php it fails.
So we need to fix both the test and the test infra where we are using the globally installed composer.
There's nothing in https://github.com/composer/composer/compare/2.9.0-RC1...2.9.0 that shows why this would have changed. I suspect that you did not actually upgrade the composer on your system and I suspect that our tests are using the system composer and not the composer we ship with.
Committed and pushed cdfabaf11f5 to 11.x and 59721e9881d to 11.3.x and 7ce663c45a7 to 10.6.x. Thanks!
Backported to 10.6.x as a bugfix for contrib.
I've merged this into 🐛 Deprecations in \Drupal\Core\Entity\EntityStorageBase::mapFromStorageRecords() on PHP 8.5 Needs review as they are fixing the same deprecation.
This will cause failures due 🐛 Deprecations in \Drupal\Core\Entity\EntityStorageBase::mapFromStorageRecords() on PHP 8.5 Needs review and this one cannot go in till that one lands...
alexpott → created an issue. See original summary → .
This has been superceded by 📌 Drupal\search\SearchPageRepository->getDefaultSearchPage()() (Line: 80) triggers deprecations in PHP 8.5 Needs review
I think we should convert the block region constraint here because it is where the PHP 8.5 deprecation is AND it shows we've got an implementation problem somewhere because the test is unable to get the correct violation property path...
Need this to fix a PHP 8.5 issue! Will merge once we're out of the commit freeze.
Here's the fix for that:
diff --git a/core/tests/Drupal/Tests/Core/DrupalKernel/ValidateHostnameTest.php b/core/tests/Drupal/Tests/Core/DrupalKernel/ValidateHostnameTest.php
index 2c2ad89f4c9..7718914f10f 100644
--- a/core/tests/Drupal/Tests/Core/DrupalKernel/ValidateHostnameTest.php
+++ b/core/tests/Drupal/Tests/Core/DrupalKernel/ValidateHostnameTest.php
@@ -50,7 +50,7 @@ public static function providerTestValidateHostname() {
// Verifies that using valid IP address for the hostname is allowed.
$data[] = ['72.21.91.99:80', 'Properly formed HTTP_HOST with IPv4 address valid.', TRUE];
- $data[] = ['2607:f8b0:4004:803::1002:80', 'Properly formed HTTP_HOST with IPv6 address valid.', TRUE];
+ $data[] = ['[2607:f8b0:4004:803::1002]:80', 'Properly formed HTTP_HOST with IPv6 address valid.', TRUE];
// Verifies that the IPv6 loopback address is valid.
$data[] = ['[::1]:80', 'HTTP_HOST containing IPv6 loopback is valid.', TRUE];
Build tests won't pass until we have a tagged release but it is great to confirm there's nothing in the dev version that breaks Drupal.
alexpott → created an issue. See original summary → .
@quietone there is no replacement. The example never worked and there are examples for bypass and default_value already. Which is what you'll need to use to handle NULLs without skipping.