This looks like another duplicate of 🐛 The following module is marked as installed in the core.extension configuration, but it is missing: webform_shortcuts Active .
What are the HTTP cache headers emitted by the site to Cloudflare on affected pages? That should answer your question.
This is a duplicate of 🐛 The following module is marked as installed in the core.extension configuration, but it is missing: webform_shortcuts Active .
@divyansh.gupta: Just to clarify further: It is not only removing usages of $this
, but refactoring to maintain the same functionality.
Which Drupal Core commit caused this? It could be 🐛 Regression: All stack middlewares are constructed at the same time even for cached pages Active or something else.
Let us know how to reproduce this bug. Can you determine the precise conditions under which it occurs?
I am glad to have helped! Reminder: Webform 6.3 is beta software right now and rebuilding the cache should part of your deployment steps.
Anyway, I am marking this as a duplicate of 🐛 Crash after update request Active in the absence of specific logs.
The location of PHP logs depends on your web server environment and setup. Consult its documentation for information. Logs are not normally stored in web site directories for security reasons.
Drupal.org documentation has an article titled Clearing the Cache → .
Another avenue of support is the #webform channel in Drupal Slack → .
I replied. Below is the template reply with ways to have your bug prioritized.
The only way to determine the immediate cause is to read the PHP logs and get that information.
Also, you did not respond to my question in comment #2.
This is a support request with steps to reproduce. Is it actually a bug report? If so, change the issue category field. Only merge requests are testable. Untested patches will not be merged into Drupal.
Please add information about specific versions installed and the update commands you used, and the command output. This class does exist in Webform 6.3.x but not 6.2.x. Is is possible you downgraded webform?
Is there an inspectable implementation of this that actually increases security in another software system?
Passkeys are current standard to replace passwords.
Old deprecated submodules are moving to https://www.drupal.org/project/webform_deprecated → . This is mentioned in the beta3 release notes → .
Is there a meta/parent issue for that, or could we create one?
You should share code on ✨ International Telephone Validation Active rather than on this duplicate issue
Is this different than ✨ International Telephone Validation Active ? It says exactly the same thing.
There is not a call to function id
on line 259 of core/modules/layout_builder/src/Plugin/Block/InlineBlock.php
in Drupal 10.5.1. Comment #3 above is probably something you should look into.
The WCAG relevance is understood. The question is "why", as in "what markup is Webform producing that Gin theme displays at low contrast"?
These are <p>
tags inside of a message, from src/WebformHelpManager.php
. Do <div>
tags display at higher contrast here in Gin theme in this context?
Include the steps to reproduce this problem to receive support.
There is not a call to that function on line 259 of that file in Drupal 10.4. How do we reproduce this bug?
A Gin maintainer sent 🐛 Improve the accessibility of information messages on webforms Active back here. I closed it as a duplicate of this one. I suppose we would have to come to understand what the problem is with the markup.
This is a duplicate of 🐛 Webform library configuration information message text inaccessible Active .
Please test on the default theme. It may be some markup needs changing but let's see.
Could we see enough of your code implementation to see if this is a bug or an API misunderstanding?
A dev says this causes a regression.
For bug reports provide the YAML of a minimal form which demonstrates the bug, and please leave out extra fields.
By the error it could be that the PHP version is not actually 8.4.
This seems to be a bug report.
Can we close this as a duplicate of 🐛 View deleted without notice on deletion of content type Needs work ?
So I think we need to take this problem very serious...
This has been a critical bug for five years.
Technically an uninstall validator in the views module could stop an uninstall if a view would be deleted, but it could do nothing for a content type deletion.
Are you referring to Forum's uninstall validator?
The steps to reproduce are not reproducible on a modern web browser. It is a type="email"
field. Modern browsers won't let users post the form without a valid email.
I think your patch would only work if the field is called "email".
In case my comment was vague, I am saying that the most likely situation is that the file has already been included by some other code, and that proving that should be straightforward on your end using built-in PHP debugging tools.
I meant @badwebcoder or @szeidler...
I don't think Drupal can have any influence directly over the behavior of require, require_once, include, or include_once in PHP. Perhpaps the file has already been included in a prior bootstrap phase which overwrote values. @szeidler or @szeidler: have you traced Drush's execution to the point of the require
to investigate?
This seems better left to other modules. Does the Webform Booking module → implement these features?
I am connecting the issue that added this behavior.
It's intentional that requests to /contextual/render
with no IDs results in this response—of course Drupal does so and it is tested to be true. As far as I know these requests are always invalid and are always client error. A 400 response is appropriate. In addition tokens
is also required and produces a 400 too.
I agree we would have to understand if there are what people think are valid requests to /contextual/render
failing in 2025.
To be a bug we need steps to reproduce involving valid contextual link setups that experience this behavior. I don't think there are any because Drupal has been configured for a long time to reject these requests.
To change the behavior is a different matter. In my opinion we should not. A web application firewall or web server configuration can block these bad requests to avoid them ever getting to Drupal.
So @brad.bulger, I pretty much agree with you and I think this should be closed as not having steps to reproduce.
Drush can show the logs. Also the 500 was probably logged by the web server.
Is this patch installed? 🐛 PHP message: Error: Call to a member function getEntityTypeId() on null (Layout Builder) Needs work
smustgrave → credited cilefen → .
I haven't been able to reproduce this as written. It looks like there are some kind of nested fields in the example screenshot, which aren't present on a default Drupal install. Accordingly, we need additional steps to reproduce the bug.
Is this a duplicate of 🐛 Plugin is broken in Ckeditor 45 on Drupal 10.5 Active ?
If I remember correctly this works as expected according to standards → .
It looks like projects that are maintained are upgrading the deprecations. I suggest creating a contributed module.
This was announced for developers in jQuery updated to 4.0.0-beta → , and I think those functions were previously deprecated. The issues you related have been fixed appropriately. I am unsure of the reasons for doing this.
That module should be ported to the current Webform rather than adding yet another feature to support.
This is essentially the same issue as the one I related so I am marking it a duplicate.
What does "List the title using MIN()" mean?
Merge requests must be against the 11.x branch.
This needs steps to reproduce. In almost every case this is probably due to SQL statements not being executed or failing.
I think this is frequently a backup, move, or restore issue where SQL settings are missed.
The batch table is auto_increment:
> describe batch;
+-----------+------------------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
+-----------+------------------+------+-----+---------+----------------+
| bid | int(10) unsigned | NO | PRI | NULL | auto_increment |
| token | varchar(64) | NO | MUL | NULL | |
| timestamp | int(11) | NO | | NULL | |
| batch | longblob | YES | | NULL | |
+-----------+------------------+------+-----+---------+----------------+
Possibly that site had a problem with a restored backup or some other condition.
This would be more appropriately selected for the CMS build, like #3065740: Add Autoban module to Drupal CMS → .
There are some prior issues that may be related to this one → .
Thanks for that update. Are only older versions of entity browser module affected?
@giordy You are correct. Sorry!
To be clear I wrote "In addition it would be helpful to know which CKEditor extra modules are installed on the site" here in a comment a week ago and did not get a reply. In future it would be more efficient to get those answers.
In 🐛 reCAPTCHA v3 not working in form with ajax elements Closed: works as designed , a maintainer said the bug is in the reCAPTCHA module. How did you determine this is a Webform bug?
Then, what configuration string is used in "Text Format" Configuration Type? Isn't it the same as the default?
Yes. But importantly, if you are using "Text Format", this module disables MathJax except in formatted text fields.
Type the command that I provided in comment #11.
Read carefully this section: https://www.drupal.org/node/1029506#s-a-database-import-changed-the-uid-... →
You probably need to execute UPDATE users SET uid = 0 WHERE uuid = '';
What was the command you typed? It did not insert a row with uid = 0 so it must have failed with an error.
If the users table did not exist Drupal would not be operating. Perhaps your database hmcpdbiy_t2am1
is not the one in which Drupal is installed.
There is also libraries/dom_purify/dist/purify.min.js
, which is missing on your end.
If the users table doesn't exist then there were serious installation problems that only exist on your platform.
This bug is not reproducible on a clean install of Drupal 11.2.2 so we need additional steps to reproduce it.
This isn’t a bug in Drupal. You have to upgrade https://www.drupal.org/project/custom_book_block → too.
You have a problem there with a custom theme which you will have to analyze.
This looks like an install or a platform problem on your end. You will have to explain exactly how you installed Drupal.