@cilefen

I used Drupal 11.2.5 with Webform 6.3.0-beta5 and after enabling configuration translation, I could not reproduce this bug.

In detail, the YAML is parsed by symfony/yaml but I can't reproduce this on the 6.3.x Webform branch using the following:

use Symfony\Component\Yaml\Yaml as SymfonyYaml;

include_once 'autoload.php';

$yaml = new \Symfony\Component\Yaml\Parser();

$raw = file_get_contents('./projects/drupal-webform/config/install/webform.settings.yml');

return $yaml->parse(
  $raw,
  SymfonyYaml::PARSE_EXCEPTION_ON_INVALID_TYPE | SymfonyYaml::PARSE_CUSTOM_TAGS
);

There must be additional unknown steps to reproduce the bug. Can you confirm the version of symfony/yaml on the site with this error?

If you could do some debugging in FileDownloadController::download it would seem that $this->streamWrapperManager->isValidScheme($scheme) && is_file($uri) is false in this case and the reason can be found.

Commerce invoice sets special controls on file access. For an example, see #3216295: Separate view invoice route for customer user → . That may be related to the behavior you have reproduced. Because of this I am moving this issue to that module because that is the best place to understand the situation.

composer/composer is at 2.8.9 in 11.x at the time I write this, and nothing prevents it from updating to 2.8.12, which is the highest available.

📌 Update Composer dependencies for 11.2.0 Active .

Could we rebrand it as ExtensionUninstallValidatorInterface?

Is this bug replicable without additional modules?

Provide the YAML of a small form that replicates the bug and please explain specifically and technically the type of mobile device and the browser used, and indicate which site theme is affected.

This is the way to mark a duplicate.

Thanks for looking into that.

This looks like a duplicate of 🐛 Webform not redirecting to default submission page when limit is reached Active . Can you verify?

Please target the merge request at branch 11.x.

I think ^ that was for one of the hidden branches.

Yes

cilefen → changed the visibility of the branch 3549717-ckeditor5.api.php-fix-encode to hidden.

Your commits must be to a branch taken from 11.x. It looks like you used another branch, perhaps 11.2.x, but the merge request is targeted, as required, to the 11.x branch.

That function is over 100 lines long. Can we get line numbers?

See also, the previously-reported:

• https://www.drupal.org/forum/support/upgrading-drupal/2024-08-02/upgrade... →
• 💬 Upgrading Drupal core to a new major version is very difficult when Drush is also installed Active

Oh, the command is in the screenshot. It would have been easier for me to see the command in the issue summary.

Also, it may be Drush. Some people have uninstalled drush/drush then put it back after the upgrade.

Did you try with --with-all-dependencies as suggested? What Composer command did you type in the first place?

These bug reports may be related or the same:

• 🐛 Contextual links of reusable content blocks are not displayed when rendering entities built via Layout Builder Needs work
• 🐛 Layout builder - contextual links Active

Drupal 10.4 will receive only security bug fixes until December 2025. Can you determine and provide the steps to reproduce the bug on the most recent version of Drupal 10 or 11, starting from a fresh install?

Let’s at least link these issues but we probably don’t need more of them. Do any have the steps to reproduce?

Why not -1?

Please participate in 📌 Update external libraries Active so we don't have duplicate efforts.

The maintainers have an issue for this: 📌 Update external libraries Active .

This may be related to 🐛 JS Client-side file validation is broken (because ajaxPageState is broken?) Needs work or #2800981: Image field with multiple values: Upload new image, then delete old image breaks order → .

What is its query plan?

If you have the slow query log enabled on the database it should show some detail. Knowing which specific queries are slow you can execute EXPLAIN <the slow SQL query> on the database server to see the query plan. That will shine some light on what went wrong with 🐛 Entity queries querying the latest revision very slow with lots of revisions Needs work .

The version set on this issue is 10.4.x, which only gets security releases. Because until today there hadn't been comments in a year, it would be valuable to get reproduction steps on 10.5.x, and ideally, on 11.x.

A community member reported this behavior change as an impediment 🐛 [D11] Embedded Blocks in REST Export Views return tags Active .

The code changed in 📌 Create placeholders for more things Active .

Please rebase your changes onto the 11.x branch for tests to run. Remove code instead of commenting it out.

1. See the Core Governance documentation, #2050477: [META] Identify component maintainers for components with no maintainer listed in MAINTAINERS.txt → , and its related issues. But Ban can't be one of them. See below.
2. Ban is deprecated in core → , which is the reason for the dedicated project page. It is the project site owners should switch to to continue using Ban.
3. The maintainers of Ban are the ones listed on the Ban project page → .

There it is. You should upgrade composer/installers to a current version.

What does composer show composer/installers show?

There isn't much to go on here. Add the specific steps to reproduce so we can characterize and reproduce this bug report.

Unfortunately I can't reproduce these warnings by installing Drupal 10.5.x in PHP 8.4. This is possibly due to an issue with the field schema on the affected site. We'll need additional debugging information to characterize and reproduce this bug.

Also, it is a bit unusual for an unset array key to be detected only by upgrading PHP, which suggests an existing problem that wasn't noticed in PHP 8.3 due to error reporting settings.

cilefen → credited cilefen → .

This could be another duplicate of 🐛 Default all responses to 500 before any code is run so PHP will throw 500's on FATAL errors Needs work .

Would you please update the issue summary, including links to the instructions you referenced, so we can use that as a basis for helping you? In addition for bug reproduction, include the commands you typed, and indicate the environment you are using, for example Windows Subsystem for Linux or other.

I am tentatively switching this one to a support request.

DM me in Slack.

@freelock core/tests/Drupal/Tests/Core/Database/UrlConversionTest.php failed, which is a different one than you updated.

I think that's as expected because Drupal 11 doesn't have a file.inc file.

Are any JavaScript console errors affiliated with this in addition to the PHP error?

🐛 [PP-2] When Media entities are deleted, the associated files are not deleted. Needs work exists. Are these working to the same goal?

Hello @dolst:

Could you cite a specific hypertext on that page that does this, and which is the anchor tag URL? I just now clicked around and did not experience what you reported.

Indeed. Let's get the answers to #7.

The patch is changing Composer libraries, which aren't part of Drupal.

Is there a specific Composer command that shows these deprecation warnings? Let's get all these answers so we can develop a reproduction.

What is the Composer command version from composer --version? What is the exact Drupal version?

We've been on PHP 8.4 for quite a while and I can't reproduce this. There must be some other conditions we need to document to reproduce this.

$ git status
On branch 10.5.x
Your branch is up to date with 'origin/10.5.x'.

nothing to commit, working tree clean
$ git pull
Already up to date.
$ composer --version
Composer version 2.8.11 2025-08-21 11:29:39
PHP version 8.4.12 (/opt/homebrew/Cellar/php/8.4.12/bin/php)
Run the "diagnose" command to get more detailed diagnostics output.
$ composer install
> Drupal\Composer\Composer::ensureComposerVersion
Installing dependencies from lock file (including require-dev)
Verifying lock file contents can be installed on current platform.
Nothing to install, update or remove
Generating autoload files
> Drupal\Core\Composer\Composer::preAutoloadDump
Hardening vendor directory with .htaccess and web.config files.
86 packages you are using are looking for funding.
Use the `composer fund` command to find out more!
drupal/drupal: This package is meant for core development,
               and not intended to be used for production sites.
               See: https://www.drupal.org/node/3082474
Cleaning installed packages.
phpstan/extension-installer: Extensions installed

What is the Composer version running?

I don't understand the connection to this issue.

Is this more of a Drush issue in that case?

I was linking to the group of issues about media paging bugs.

This is the third instance of the same issue reported.

Was this module never actually marked as deprecated → in 6.2? It seems not. In truth, only a major release should include backward compatibility breaks. In this case, at a minimum these modules should be marked as deprecated in a 6.2 release. Isn't it too late to put this code in 6.3.x?

Sorry! I thought the "stale-issue-cleanup" tag was a signal for the bot to close this in n days.

smustgrave → credited cilefen → .

I think this confusing API should be changed.

This issue may be the same as reported in 🐛 Simple decimals fail to pass validation RTBC . Can you verify?

Did you consider removing the webform_shortcuts.settings.yml file from the configuration directory then importing?

Please update this issue with the complete steps to set up the view.

Can we get the complete stack trace?

Neither file layout_builder.module nor function layout_builder_config_translation_info exist in branch 11.x. They were removed in 📌 Bulk convert the remaining hooks to OOP Active . Maybe the site had some difficulty updating which left old files?

Understood. I am attaching an issue with the same error, in case there is useful information there. Also, I am moving this to Workspaces because that is where the exception throws.

This doesn't meet the criteria for a critical bug → .

This issue is filed as a support request. Are you looking for support or for some changes to Drupal?

Do the HTTP request headers differ significantly between browsers in this case?

Is PostgreSQL essential to the bug reproduction?

What are the details of the error? Can you get the stack trace?