@cilefen

smustgrave → credited cilefen → .

Thanks for the report and for the code! Just one thing—the merge request is enormous so something is wrong there.

Oh, I guess you can't because this is a distro. Hmm...

The issue summary needs reformatting to be understandable. Are you saying this is a regression in 10.4.8 as compared to a prior version of Drupal? If so, then which version worked?

Would you execute a git bisect operation on a working copy Drupal Core to find the commit that caused this?

Thanks for the patch. Can we get a merge request against the 11.x branch please?

An Ajax test failed, which seems related. Automated test documentation is on drupal.org.

For this to be a Drupal Core issue we would like to see the problem reproduced on the default theme, or else this is a problem with the theme which you are using.

This is a possible duplicate of 🐛 Encrypted fields do not work with Views exposed filter(s) Active . Can you verify? I'm not entirely sure how or why this issue would be addressed in Drupal Core.

At a glance it is because the default site exists and the web server hasn't been configured to handle that.

This bug report will be improved by someone putting the corrected steps to reproduce into this issue summary and removing the “needs steps to reproduce” tag.

Which theme is that?

There could already exist an issue for this.

First, you may have a better support experience on Slack.

Was the DDEV software documentation helpful or did you have to make the customizations based on your own knowledge of Drupal and nginx?

What does the DDEV configuration file look like?

Is this answer helpful?

I didn't say they obtained anything. I was indicating that it's been my experience to discover that some site admins do not use Drush to add some context to this issue.

I don't know whether the site admins who don't use Drush change the admin theme. I am only saying that these people exist. I don't know if there is an intersection between non-Drush users and the 73k sites that use Gin, for example. I can't answer your questions.

There is a report that this regressed.

Understood.

That will be 🐛 LogicException: The database connection is not serializable. Postponed: needs info or one of its related issues, for example, 🐛 LogicException: The database connection is not serializable (for string translations in Ajax callback) [META] Active .

Is this issue part of 🌱 Gradually replace Drupal's AJAX system with HTMX Active ?

According to the screenshot there was a 500 error. What is that error? Check the logs.

git log -S timepicker 6.2.7..6.3.0-beta2 shows that 📌 Fix broken tests Active and 📌 Require minimum of Drupal 10.2 and remove compatibility shims Fixed are the changes affecting "timepicker" directly that are only in 6.3.

@nod_ What do you mean by a "security track"?

What were the initial versions?

FWIW you can delete install.php and update.php in production deploys and enable aggregation. Those actions will eliminate the scanner detection.

Why is this feature request a bug?

You experienced this after upgrading specifically which versions of which software?

I have encountered community members who operate web sites but do not use Drush and don’t know what it is. I don’t know what portion of the total works this way.

I looked into the history of that theme's development and concluded that the rounded image is an intentional design choice.

What is a circle icon?

I cannot reproduce this bug as currently specified on a new Drupal 10.4.7 install with Webform 6.3.0-beta2. I am marking this issue as being in need of additional steps to reproduce the bug conditions.

According to this bug report Webform is unusable.

I think this issue duplicates the issue you referenced.

@nicxvan re #28, not everything in that comment was addressed. I guess recipes don’t count? IMO this text shouldn’t cite specific project types.

We can’t know how your JavaScript file is loaded so for now this is a support request and we need more information from you.

Sorry for the late comment here, but there already exists text of this policy → :

# How to report a security issue

If you discover or learn about a potential error, weakness, or threat that can compromise the security of Drupal, we ask you to keep it confidential and submit your concern to the Drupal security team.

Should we not use the same?

How do we reproduce this so someone can write a regression test?

This may be covered by 📌 Come up with a design for highly destructive operations in confirm forms Active or more likely, 🌱 Configuration change data loss prevention functionality inconsistent, restrictive Active . Would you please steps to reproduce on a fresh install so I can reproduce this one?

Most people would say Tailwind these days. IMO this should be closed for lack of interest, a plan, and funding.

First try updating the target branch.

I may be misunderstanding your comment but in Drupal there is not a function_exists check for imageavif.

I linked to this issue from ✨ Let GDToolkit support AVIF image format Needs work . Yes it seems like Drupal should check whether the function exists before calling it.

I don't know what we can be fixed in this issue without steps to reproduce. Perhaps it is a Commerce issue. It's support options are listed at https://www.drupal.org/project/commerce → .

This was added to fix "Files uploaded by anonymous users into a private file system can be accessed by other anonymous users" in SA-CORE-2017-003 → .

I think an exception throw is the best way to notify the developer..

Why not? drush updatedb exists.

Thank you for the patch! I am updating the issue metadata because we need the following to proceed:

• A merge request.
• Detailed steps to reproduce.
• Regression tests.

Drupal 9 is no longer supported here. Composer questions can only be answered by you providing information including the command you typed and its complete output. Read the output carefully, as the reason is often stated there.

From the project's page: "The module is in a very stable place, though we are doing performance enhancements to the path checking".

As mentioned in comment #5 above, you may completely remove these files as documented at https://www.drupal.org/node/3424527 → .

I marked that one as a duplicate because it is very old, the OP's account no longer exists, and there is actually more information on this issue.

In current scope of the limited case of images which are public, does this bug need to be critical?

Please also credit kaique peres who also reported the same to security.drupal.org.

Just to be clear, I am not against some adjustments here. In the case of install.php I think it should do nothing whatsoever after install. But I think this issue needs to be better scoped—perhaps split—because install.php and update.php are a bit different in the codebase.

What does "Drupal core paths are accessible" mean in this bug report?

I am moving this issue to normal priority because there is a workaround—a site owner may delete these file in production deployments.

There are many ways for a sophisticated attacker to determine whether a site is Drupal.

What did Google offer?

I guess search page results should be excluded from indexing. That can't be fixed here so I'll move it to "API.Drupal.org customizations".

Is it ok if I close this then? If someone has a similar problem they will find this issue and can comment.

I think you have misunderstood what I wrote.

That page isn't a 404 error. It's a search page. What is the problem to be solved in this case?

When MySQL will full table scan with LIKE clauses is up to the query optimizer. We definitely need to understand what code calls this query and in what situations.

The query you posted does cause a full table scan on a default site:

> EXPLAIN SELECT pattern_outline FROM router WHERE '/node/278960' LIKE CONCAT(pattern_outline, '%') AND pattern_outline != '/';
+------+-------------+--------+------+-----------------------+------+---------+------+------+-------------+
| id   | select_type | table  | type | possible_keys         | key  | key_len | ref  | rows | Extra       |
+------+-------------+--------+------+-----------------------+------+---------+------+------+-------------+
|    1 | SIMPLE      | router | ALL  | pattern_outline_parts | NULL | NULL    | NULL | 332  | Using where |
+------+-------------+--------+------+-----------------------+------+---------+------+------+-------------+

It would be good to know if Drupal Core code is initiating that query or if it comes from a contributed module. If we knew which action on the website induces that query to execute on a plain Drupal site it would really help.

Show the output from DESCRIBE router and SHOW INDEX FROM router, so we can be sure the site doesn't have modifications. The defaults are as follows:

> DESCRIBE router;
+-----------------+--------------+------+-----+---------+-------+
| Field           | Type         | Null | Key | Default | Extra |
+-----------------+--------------+------+-----+---------+-------+
| name            | varchar(255) | NO   | PRI |         |       |
| path            | varchar(255) | NO   |     |         |       |
| pattern_outline | varchar(255) | NO   | MUL |         |       |
| fit             | int(11)      | NO   |     | 0       |       |
| route           | longblob     | YES  |     | NULL    |       |
| number_parts    | smallint(6)  | NO   |     | 0       |       |
| alias           | varchar(255) | YES  | MUL | NULL    |       |
+-----------------+--------------+------+-----+---------+-------+
7 rows in set (0.002 sec)

> SHOW INDEX FROM router;
+--------+------------+-----------------------+--------------+-----------------+-----------+-------------+----------+--------+------+------------+---------+---------------+---------+
| Table  | Non_unique | Key_name              | Seq_in_index | Column_name     | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment | Index_comment | Ignored |
+--------+------------+-----------------------+--------------+-----------------+-----------+-------------+----------+--------+------+------------+---------+---------------+---------+
| router |          0 | PRIMARY               |            1 | name            | A         |         332 |     NULL | NULL   |      | BTREE      |         |               | NO      |
| router |          1 | pattern_outline_parts |            1 | pattern_outline | A         |         332 |      191 | NULL   |      | BTREE      |         |               | NO      |
| router |          1 | pattern_outline_parts |            2 | number_parts    | A         |         332 |     NULL | NULL   |      | BTREE      |         |               | NO      |
| router |          1 | alias                 |            1 | alias           | A         |           2 |     NULL | NULL   | YES  | BTREE      |         |               | NO      |
+--------+------------+-----------------------+--------------+-----------------+-----------+-------------+----------+--------+------+------------+---------+---------------+---------+
4 rows in set (0.001 sec)

In case you didn't already find this information, git bisect is documented. In this case you would:

1. Git cone a working copy of Drupal core.
2. composer install
3. Install Drupal. If you are using DDEV, ddev exec composer install drush/drush && ddev exec drush si will accelerate that process.
4. Install and test your module.
5. Begin a git bisect operation, giving the tool a known bad and a known good Drupal release tag.
6. Repeat steps 2, 3, and 4 each time bisect checks out a candidate commit.

This isn't the only way to solve this problem, however, knowing the commit that broke your code should quickly lead to a resolution.

All we know is that in on of the many Drupal 10 versions this code broke. Could you do a git bisect on Drupal Core with this module present to find the breaking commit?

smustgrave → credited cilefen → .

* You can use the following snippet to retrieve all available toolbar items:
* ```ts
* Array.from( editor.ui.componentFactory.names() );
* ```

I am not sure at what stage the documentation means this should be executed to check. Do you know? Did you do so?

There is documentation for that error, and it includes troubleshooting steps.

I am moving this to the CKEditor 5 module component because it doesn't seem to relate to Drupal's plugin system, which refers to PHP objects.

Are you certain this integration broke in Drupal 10.0.0, or do you happen to know it broke in a more specific version?

This doesn't happen in a newly-setup Drupal site. Has this site been upgraded through many versions?

Could you dump the configuration for the action module and the user module?

I am removing excess tags according to the tag guidelines → .

In fact, in these cases the log messages would make no sense without values in placeholders.

I am relating a few issues.

There is a @todo below that documentation saying "address the above issue in Drupal 8", so I guess that hasn't yet happened. I hope there is an issue open somewhere to make this "just work" by default.

I think the setting you are looking for is #empty_value.

Its documentation reads:

 * - #empty_option: (optional) The label to show for the first default option.
 *   By default, the label is automatically set to "- Select -" for a required
 *   field and "- None -" for an optional field.
 * - #empty_value: (optional) The value for the first default option, which is
 *   used to determine whether the user submitted a value or not.
 *   - If #required is TRUE, this defaults to '' (an empty string).
 *   - If #required is not TRUE and this value isn't set, then no extra option
 *     is added to the select control, leaving the control in a slightly
 *     illogical state, because there's no way for the user to select nothing,
 *     since all user agents automatically preselect the first available
 *     option. But people are used to this being the behavior of select
 *     controls.

Alternatively you have the option of changing your code not to pass a null.

🐛 Decimal separator and decimals settings ignored when aggregating decimal fields Needs work has been reverted. Have you tested this on the development branch?