@cilefen

One more thing: Can you get the JavaScript stack traces? They're not, like, fun to read when aggregation is on but they may reveal more about the problem.

Hello @cozydrupalnerd,

I tried and failed to reproduce this in DDEV.

This could be more to do with issues some sites are having with recent changes to the asset library system → than with batch system, but we would need more information from you to know for sure.

Specifically: Does this bug occur on the platform you are using in a totally new and clean Drupal Core installation with no contributed extensions?

Here is one such issue: 🐛 Remove use of exec('rm -Rf') as security concern preventing use of open_basedir. Needs work .

Hello @karthik.m,

Welcome to the Drupal Community and thank you for this post! I changed the issue category to "plan" because there would not be a visible change to users and I made its priority "normal" according to the issues documentation → . Additionally, I've retitled the issue to be more direct.

Some security "hardening" issues which are not immediately exploitable bugs are tagged " security improvements → ". It is likely any existing efforts you are looking for would be on that list. Generally, the Drupal Community would expect you to do this research before asking. To be in touch with the Drupal Community for interesting topics that require discussion, use Slack → . The #security-discussion channel would be an ideal place to talk about this matter.

Actual security bugs should be reported to the Drupal Security Team via the project's "report a security vulnerability" link.

In my opinion it would be effectively impossible to eradicate all those functions in Drupal—ini_set for example.

I think this may be more to do with https://github.com/jackocnr/intl-tel-input, which Webform uses. Is the flag correct at this demo?

If so, it may only need upgrading, which I think would make this a duplicate of ✨ Update jquery.intl-tel-input to v23.0.10 and add option for i18n Active .

I have looked this over and I think it may duplicate ✨ Add a #disable_inline_form_errors_summary property to disable the Inline Form Errors summary Needs work . Can you verify?

That's interesting. Could you please get us a link to the Commerce issue you mentioned? It would also be great to get a stack trace for this exception.

That is unfortunate however line 299 of core/lib/Drupal/Core/Entity/EntityTypeManager.php doesn't have an exception throw (it is a comment), so maybe the upgrade process you took didn't replace Drupal files as expected, or, you the site has patches or other adjustments that modify Drupal Core. More information is needed from you to further an investigation here.

Thanks for that update.

I agree this doesn't seem fundamentally different from #3045570: Plugin missing for node actions → , so I am marking this a support request. All I can surmise is that there was a failed update along the way or perhaps someone imported an old configuration set, overwriting new required values, because the action is defined in core/modules/comment/config/install/system.action.comment_delete_action.yml.

I would focus on the advice in comment 7 on [#3045570] → . Does importing that configuration into the active configuration fix the problem?

• Number::validStep(3596000.00, 2, 0) returns true for me.
• Number::validStep(123456789101112.00, 2, 0) returns true for me.
• Number::validStep(123456789101111.00, 2, 0) returns false for me (as it should).

Is this platform-specific?

We need the code changes in the form of a merge request to be reviewed. Thank you.

More than six months have passed without new activity so I am closing this.

Six months have passed without new activity so I am closing this.

The error message points to https://www.drupal.org/project/context_stack → .

See 🐛 cache problem after updated to 10.4.0 Active for more information on this.

The essential complaint here is that Core doesn't have a feature for managing revisions at scale. For an issue like this to be actionable it should be recreated as a feature request, and it would need a plan, a design and so on.

@marelpup: Open a bug report for Node Revision Delete → regarding translations. If that module gets to a certain stage of maturity it could be considered for integration into Core.

Actually, 'now' can never work. It's just the case that the format has to match the input. What is the input in the cases where this doesn't work?

This works: \DateTime::createFromFormat('Y-m-d H:i', '2008-06-01 12:50')

I think \T is totally unsupported. Anyway, this is PHP's standard library, not Drupal.

The code throwing the exception is:

$date = \DateTime::createFromFormat($format, $time, $datetime_plus->getTimezone());
if (!$date instanceof \DateTime) {
    throw new \InvalidArgumentException('The date cannot be created from a format.');
}

It is in DateTimePlus::createFromFormat. This code returns `false` in the PHP REPL:

(\DateTime::createFromFormat('Y-m-d\TH:i', 'now'));

So I think your time format string is invalid to the \DateTime library. I hope this helps.

I have found it is the programmatically generated menu items themselves which are uneditable this way, but it doesn't matter which menu they are on. Custom menu items can be edited. At least I think that's what I saw. I am tentatively retitling this issue.

Can you confirm that on any menu, custom menu items work properly, but programmatically-generated menu items do not? That has been what I observed.

@craigmullins You will have a much better time with migrations support by asking in the #migration channel in Drupal Slack → . In all honestly a support request of this nature posted here may be unanswered indefinitely.

When you do, be sure to summarize the migration configuration in play as the answer is probably to do with that.

benjifisher → credited cilefen → .

I agree, something odd happens with the form. It seems to affect only programmatically-generated menu items. Can you confirm that?

I am updating tags by the issue tag guidelines → .

I think this is fixed in the 6.3.x dev branch. Can you verify?

With but reports we generally request the reporter to provide the YAML of a small example form. That would help.

Is this reproducible on the CKEditor demo instances?

greggles → credited cilefen → .

Does this occur with translations, which could be 🐛 It should not be possible to install Drupal database into a site where it is already installed when pending translation imports exists Needs work , or in other cases? These issues may be the same, even if they have different triggers.

It is not missing. See the feature to install a new extension from a URL via the Drupal UI has been removed → for the explanation.

Drupal 9 is no longer supported. There will be no further releases.

Based on comments from last year, this is a duplicate.

See this comment I wrote 🐛 Database serialisation error Active for git bisect instructions.

As to "setup" I mean any guidance on how I could set up a site on my end to exhibit the bug.

For example, I may be unable to reproduce the bug because I am testing as administrator. I did the following:

1. Installed a new Drupal 10 site with Webform 6.2.8.
2. Changed the built-in Contact form to be accessible only to authenticated users.
3. I added some custom CSS.
4. I disabled CSS aggregation, so I could see every file in the dev tools network tab.
5. When viewing the form, the custom CSS file is downloaded and it is a HTTP 200.

I saw this on SE and have been unable to reproduce it as written. Because you can reproduce the bug on that site, would you add to the issue summary the full steps to reproduce including the CDN setup?

🐛 Webform asset javascript (webform/javascript/webform_id/custom.js) is showing not found Active is perhaps related, although that one is a 404.

Thanks for that comment. I just don't think this feature request should be taken on by Core. The existence of https://www.drupal.org/project/robotstxt → with 40,000 installs and of https://www.drupal.org/project/aitxt → (10 installs) means the flexibility to adjust AI content consumption is already well-supported within the Drupal ecosystem. IMO we don't want to be chasing specific bots in this core file, because to do so by default is controversial, and because of the commit noise it would incur. The contrib modules are a better avenue—even more so if those modules would feature a way to append the latest bots list.

As with 🐛 Drupal 10 webform validation issue when using checkboxes Active , does this bug require clientside_validation module?

Could we consider re-branding this as "Require re-authentication for certain admin actions", to include more authentication setups?

🐛 AJAX Response Not Sanitized For Length Active or one of its related issues may be addressing this problem. Can you verify?

Thank you for the report. I think this may duplicate 🐛 Labels should not have "for" attribute for non labelable elements Needs work . Can you verify?

Actually that's not completely true because of the /issues auto path.

I don't know, really. It just seems a strong default not to index /node. It's a bit of a singular case but this very website would be largely un-indexed with that default. 🙁

In my experiences that article is correct: search engines respect Core's rel="canonical", with or without Redirect. I am trying to understand the downside of having a /node URL indexed to which later the author adds a path alias, which the search engines then accept.

Does the opposite ever happen?

Also note:

If you have multiple pages that have the same information, try setting up a redirect from non-preferred URLs to a URL that best represents that information. If you can't redirect, use the rel="canonical" link element instead. But again, don't worry too much about this; search engines can generally figure this out for you on their own most of the time.

https://developers.google.com/search/docs/fundamentals/seo-starter-guide...

Although Google recommends descriptive URLs, there is nothing "wrong" with /node paths.

Because using Redirect to maintain canonical URLs → , that is, <link rel="canonical" />, works, I wonder whether it is ideal not to index /node paths by default.

These are just my first thoughts after a few minutes' consideration.

In past, related issues have been caused by drush/drush, and in those cases removing drush/drush, upgrading core, then adding back drush/drush completes the upgrade.

Doing this is easier than you may think:

1. Delete the copy of Webform module that Composer installed from the modules/contrib directory in your test site.
2. In the modules/contrib directory: `git clone https://git.drupalcode.org/project/webform.git`.
3. `cd webform`
4. `git checkout 6.3.x`
5. `git bisect start`
6. `git bisect good 6.2.9`
7. `git bisect bad 6.3.x`

`git bisect` will proceed to check out candidate commits. Test each time, then type `git bisect good` (if no bug) or `git bisect bad` (if you see the bug). This will find the commit in a few steps.

Is this bug reproducible with Webform alone?

Webform's own Drupal\webform\EventSubscriber\WebformFilterFormatSubscriber, the default implementation—a new class introduced in 🐛 Webform text format appears in the formats list Active —does implement Symfony\Component\EventDispatcher\EventSubscriberInterface.

That's all I can add here.

Yes this is a bit of a strange situation easily obtained. I think this is actually the "Text" module.

For what it's worth, in separate, fresh 10.2.8 and 10.3.6 sites, I created REST export view displays for the Content view. In each version there is not a root data key.

Is that the only file with this problem on the affected site?

I am adding the "Needs steps to reproduce" tag because having installed a new Drupal 11 site to test this, I don't see the problem. What other factors could be involved?

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?