@cilefen

The issue summary says that "users are unable to access additional options or features when clicking the icon", but in fact the problem is that the icon should change when used. Do I understand now?

Which theme is this?

We could have moved this there.

Understood.

Is this something that can or should be fixed in Drupal Core or is it more of an Entity Browser bug that we should move to that project?

What are the steps to reproduce this bug?

"File (Field) Paths" isn't an option in the File System configuration for a default Drupal installation. Are there additional file system modules needed to exhibit this bug?

The menu appears to be working in the screenshot you posted. Additionally, I can't reproduce the problem on Drupal 10.4 with the steps to reproduce as written above.

Welcome to Drupal! I am unsure exactly what "PHP Extension Disable" would mean here. Perhaps if you were to post the exact error we could help.

Be aware that it is not recommended to use XAMPP for local Drupal development → . You have some work to do to get XAMPP to run Drupal. DDEV is the easiest way to run Drupal locally, and that is explained in the Local Development Guide → .

Information in comment #3 suggests there are additional steps to reproduce.

@dalemoore Thank you for that comment. So, there can be more than one reason.

If any of the followers of this issue are overlaying files when upgrading, that has never really been the process. The only supported way to upgrade Drupal now is with Composer. If you are going with another method, you have to actually delete the files that have been removed in updates. If you are using Composer in a creative way, you have to actually delete the files that have been removed in updates. If you are syncing files in some way to a remote web server, you have to actually delete the files that have been removed in updates.

Not deleting those files is why this is happening to you.

What are the steps to reproduce this bug starting from installing Webform?

I've closed this as a duplicate because this is indistinguishable from 🐛 Individual admin pages no longer accessible after update to 10.4 Active .

This is probably not a bug.

Additionally, it was never the practice to only overwrite files. Even the Drupal 7 instructions included the fact that you should delete the source code files → before copying in new ones. This is because files may be removed whose presence may crash the software.

As this is not a lecture about Composer I hope it will be accepted.

Did you go as far as to remove files from the filesystem that have been removed from the product? At just a glance, the file core/modules/update/update.links.action.yml was removed from Drupal and may be wrongly present on the affected site.

There exists a GitLab Triage Bot so we would not have to author one.

I find giant backlogs psychologically paralyzing and that if a bug, task, or feature is important to a community people will continue interacting with it. GitLab, for example, allows voting up issues without needing to comment.

Would you please take these steps to ensure this issue gets attention?

• Update the issue summary above to include the exception message. That will more clearly explain the bug, as readers will not have to read comments to find essential information.
• Update the issue summary above with more detailed steps to reproduce from a clean Drupal install. In particular, explain exactly how to implement the custom entity type that is involved. Be sure to verify the steps yourself on a clean Drupal install.
• Remove the "Needs issue summary update" tag and change the issue status to "Active".

I've not been able to reproduce this bug on Drupal 11. Are there any modules on the site that could modify the file module's configuration?

Hello. There is a stack trace but the actual error isn't there.

Thanks for this bug report. It looks as though missing translation support is an acknowledged problem with layout builder.

Can you verify whether this issue duplicates one of the following issues?

• 📌 Allow synced Layout default Translations: translating labels and inline blocks Needs work
• 📌 Allow synced Layout override Translations: translating labels and inline blocks Needs work
• ✨ Let layout builder render inline block translations Needs work
• #3044386: [META] Make Layout Builder layouts translatable →

There seems to be something with a custom grid_news module which isn't part of a default Drupal install. Perhaps it has a coding bug.

I updated this comment to fix my typos.

Please try to determine the bug reproduction steps with a clean Drupal installation.

I noticed this has something to do with Webform. Is a load balancer in use on this site?

I am unable to reproduce this bug as written. I am tagging this for needing more steps to reproduce.

Update the "Resolve modules that are only compatible with Drupal 10" to indicate that the example configuration allows either D9 or D10 compatible extensions, but it does not install both at the same time. This has actually confused people.

I just checked on my sites and is-active is there as expected. We'll need some refined steps to reproduce to take this on as a bug report.

Thanks for the patch. I am tagging this and updating other issue metadata.

Please set up a merge request.

This issue may actually be a feature request rather than a bug.

It's obviously a temporary measure, but you could apply the reverse of the feature patch.

git diff ebc8e0639e0e12391087d9abe0ad8eca0034d1ea ebc8e0639e0e12391087d9abe0ad8eca0034d1ea~1 >patches/3497758.patch

I've attached that patch.

You may as well try. But, create merge request instead of a patch.

For Composer usage support provide the composer.json file.

I have 10.4.0 sites working on Apache so there must be additional steps to reproduce the bug. Perhaps it is related to the Apache configuration that is in the Docker image. What is that configuration?

Thanks for looking into that.

Although this is a slightly different root cause, I think this may be essentially the same as 💬 RuntimeException: Adding non-existent permissions to a role is not allowed Active . Can you verify?

Thank you for that update. I am setting this issue's status to "needs work" based on the tests requested in #7.

I am not sure anything is required except to add the contributed module into the codebase when upgrading to Drupal 11.

Nevertheless I am moving this issue to the contributed project because that is a better place for questions.

Thank you for the suggestion. It looks like this is a long-time goal in issue ✨ Pathauto in Core Needs work so I am going to mark this as a duplicate. There are some blocking issues and other work to be done.

Are any CKEditor plugin modules installed on affected sites?

Understood. Thank you for that clarification.

Thanks for the report. I think this issue needs to be clarified with steps to reproduce in order to be considered as a bug report. For example "The website encountered an unexpected error" normally produces an error in logs. Providing us that error will be useful.

I don't understand the unknown string angle. It's a type error where the type is Drupal\Core\StringTranslation\TranslatableMarkup, and objects can't be array indexes (aka "offsets").

This happens with or without contributed modules but the reproduction steps remain a bit unclear. We need technically-detailed evidence of the root cause. If that cause is definitively the composer_deploy module based on evidence, ideally including debugging function parameter data, please move this issue back there.

@tr: I think @thejimbirch agrees with you comments about CI but suggests you should open a separate issue for them, possibly in https://www.drupal.org/project/gitlab_templates → .

Thank you for contributing that tip @hoxton.

Sure but I have to ask: What is the use-case for a version string being translatable markup? It seems like a mistake.

Take, for example, this code from the package_manager module:

if (!is_string($existing_version)) {
        return NULL;
}

This is RTBC for the newline quick fix.

Based on its contents the new README is meant to be scaffolded into a full Drupal site codebase, not into extension directories. The same must happen with .gitattribute and .editorconfig but to date I suppose those have been benign on CI. @tr: Whether we need a separate issue for solving that or if we should just continue here I'll leave to your discretion.

"No update information available" is a separate matter. There is a large volume of posts online about that dating back many years. The causes can vary, but include issues such as an inability of the initiating process to access the updates domain via HTTP, occasional minor outages of the updates feed, and other reasons. It should be investigated with those resources instead of here.

Is it now established that the cause is composer_deploy? The existing_version string being translatable doesn't actually make sense so if "yes" we should probably move this issue to that project's queue.

I am closing this as a duplicate of 🐛 fatal error on `update` module enable on composer-managed D11.1.0 instance Active , which has more and better information.

For what it's worth that site doesn't have any particularly rare modules. I am trying to remember whether (and where) update data is cached...

Is it still the case when the module code is not present? Update manager looks at all present extensions.

At a glance it may be composer_deploy, because it modifies update information. I would try uninstalling it first.

Are there contributed or custom modules present in the Drupal installation that produces this bug?

I am seeking to understand if this issue duplicates the previously-reported 🐛 Cannot access offset of type Drupal\Core\StringTranslation\TranslatableMarkup in isset or empty in Drupal\update\ProjectCoreCompatibility->getPossibleCoreUpdateVersions Active . That is all. I wrongly referred back to this very issue in comment 4. Sorry for that confusing comment.

This issue has a stack trace. The other does not. Both issues describe the bug reproduction environment, which I am beginning to think does not influence the bug occurring. Neither has steps to reproduce. There must be some steps to reproduce, even insomuch as an element of the environment may be the reproduction.

The stack trace indicates that $this->existingCoreVersion is an object when it should be a string. How this is happening is a bit of a mystery.

This, I think is the same error as 🐛 fatal error on `update` module enable on composer-managed D11.1.0 instance Active . 🐛 fatal error on `update` module enable on composer-managed D11.1.0 instance Active doesn't have a stack trace so I don't know if this is quite the same. My investment in this right now is just determining if we have a duplicate issue.

I think this may duplicate 🐛 Update manager compatibility logic is missing if you're on a -dev release of core Active or 🐛 Cannot access offset of type Drupal\Core\StringTranslation\TranslatableMarkup in isset or empty in Drupal\update\ProjectCoreCompatibility->getPossibleCoreUpdateVersions Active . It looks like you commented on one of them. Is this issue distinct?

Is the autosave_form module required to reproduce the bug? I am tagging this issue for needing steps to reproduce.

@davidwbarratt Does core/modules/update/update.links.action.yml exist in that installation?

In that case I think this issue needs a title update to more clearly indicate its scope. Additionally, you should comment at #1765576: Redesign Permissions Page → to alert the followers of that issue of the existence of this issue.

In the least it should be part of that issue or incorporated into it.

I don't understand this bug report very well as written. Is it possibly something to do with 🐛 Individual admin pages no longer accessible after update to 10.4 Active ?

larowlan → credited cilefen → .

This is the expected behavior of the update module when there is no version set in the info.yaml file. If you select a branch release like that, Git will clone the project repo rather than download a versioned compressed archive.

This isn't a Drupal Core bug but rather more like ✨ Requiring dev releases with Composer clones the repo, which is different than downloading a dev release archive Active . Can you confirm?

#540118: Add revision support to users → is the first and only issue you find by searching "revisionable" in the user component.

That is functionally the same then.

Is Xdebug enabled when this occurs?

Have you been in touch with Acquia Support about this?

Is this Site Studio, as in, the Acquia product?

Actually it would be interesting to know if you were to make a PHP file in the web root called test.php with these contents:

<?php
if (file_put_contents('/tmp/drupal/mysite/foobar', 'test') === FALSE) {
      throw new \Exception("Temporary file could not be created.");
}

Then browse to https://example.com/test.php. This would be a basic test that doesn't use a stream wrapper. What happens?

Maybe it is a bug. Add the steps to reproduce it with a common linux distribution to the issue summary and someone will probably have a look.

Here is the call point with the warning: https://git.drupalcode.org/project/drupal/-/blob/11.x/core/lib/Drupal/Co...

It's a little difficult to remove Drupal to test this, with, say, a plain PHP script, because setting up the temporary:// stream wrapper involves a few classes. Otherwise, I would suggest trying that.

This looks like a duplicate of 🐛 Checking for duplicate emails in user_requirements() does not take langcode into account Active . Can you verify?

FWIW here is that function: https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21StreamWra...

It looks like a permissions issue or that the directory is totally unreachable by the web server process. You are in the best position to solve this one. It isn't a bug in Drupal.

Is there selinux or other advanced ACL or other file access security system running?

+1 I guess we need some updated markup there. The W3C Patterns Guide has some examples. Unfortunately, the tooltip pattern isn't finalized, and the is a tooltip with a header and a body, which may differ from the eventual pattern.

Ok, let's publish the CR and close this.

Probably. And then there is the auto-updates feature to consider.

The steps to reproduce list ordinary actions which are not failing on any system I've been using. So, we will need additional steps to reproduce from you. For example, the "site studio" text format isn't a default in Drupal Core. If you suspect it is involved, its configuration needs to be clarified by you. As written, it's hard to tell if CKEditor is doing this because you said you have to save the data to see it happen. If the data is as expected when leaving the source tab, then this may not involve CKEditor.

Additionally, it would be helpful to know whether Drupal or the browser console log are indicating errors.

But what we need most are very clear steps to reproduce performed and verified by you on a newly-installed Drupal site.