🇺🇸United States @cilefen

All of the code samples above are broken. Markdown code fences is not supported. Also, I think there is already an issue for this.

The prohibits subcommand answers this.

Upgrade the site to a supported version of Drupal and test again.

Things to try: Obtain stack traces. Uninstall suspect modules until it stops.

Are you saying that you yourself are not intentionally visiting those pages? The more explanation I see the less I understand. Maybe you could break it down to the simplest possible narrative?

There are no IP addresses shown above but IP addresses seem to be involved in this bug report, which I admit I don’t yet understand. Is the content of log messages the Core bug you are reporting, or is it the access denied?

Yes, 🐛 Validate view_name in ajaxView() Needs work , for example.

Please include the screenshot in this issue rather than in an outside link. Also, indicate the prior version of Drupal that was working.

In past this has been because max_allowed_packet in MySQL is set too low or because of something else about the platform not meeting Drupal's requirements. We'll need verification from you that the platform meets all requirements. Also: zip installs are just barely supported anymore.

Tests are expected by default. Maybe a unit test will do.

There is a clear solution then. Can we close this?

More documentation exists:

• https://www.drupal.org/community/contributor-guide/task/triage-novice-is... →
• https://www.drupal.org/community/contributor-guide/reference-information... →

I suggest this be moved to https://www.drupal.org/project/issues/mentoring → .

It's interesting.

For a bug report we'll need some more technical info. Some examples of the log messages would be a good start, as would a list of modules enabled and their versions.

I would need technical information on what happened to comment meaningfully.

cilefen → created an issue.

This breaks the Menu Trail By Path module, which extends that class.

The MenuActiveTrail change causes a regression for us. I am looking into the immediate cause on our end.

There is a short definition of "novice" → :

It would make a good project for someone who is new to the Drupal contribution process. It's preferred over Newbie.

In my opinion an issue tagged "Novice" must have extent unambiguous tasks that could be completed by contributors with little or no experience with Drupal contribution or with OSS contribution. The "Novice" tag must be removed when that isn't the case.

Which core and contributed modules are installed in this site and what are their versions?

Also please get the entire stack trace.

Can you check on what error is logged there?

This could be the same as 🐛 Aggregation changes in 10.1 break xdebug Postponed: needs info .

In the short-term have you tried turning xdebug off? Are there any core patches installed on the site?

Please add to the issue summary your code implementation that triggers this bug.

I've read this report and I've not been able to reproduce this bug as written. Here is what I did:

1. Created a Drupal 10.3.3 site on https://simplytest.me
2. Installed the Media and Media Library modules.
3. Added a Media entity reference field to the default "Article" content type.
4. Added permissions to the default "Content editor" role to manage the Remote video media type.
5. Created a user with "Content editor" role.
6. Logged in as the content editor user.
7. I was able to add a remote video media by URL.

Since you have a site set up to reproduce the bug we need more information from you on how to trigger the issue.

See document the steps to reproduce an issue → for a guide to documenting an issue so a developer can work to fix it.

Drush is a separate project, which is supported at https://github.com/drush-ops/drush/issues. If you have determined this is a Drush problem then that is the place to report a bug.

The issue summary needs updating to explain why putting this back into Drupal is needed.

I haven't been able to reproduce this bug with the information given above. Here is what I did:

1. Created a Drupal 10.3.3 site using https://simplytest.me.
2. Enabled Workspaces module.
3. Enabled Configuration Translation module.

Nothing seems wrong after this. Since the site you are analyzing has crashed we need additional reproduction steps from you.

This is not critical and I am not sure it is a bug.

Document the steps to reproduce in the issue summary.

In seeking support at those places I recommend gathering this information:

• Details of the hosting platform. Is the platform set up—even certified—for hosting Drupal?
• Verbose output and stack traces.
• The definition of the "Post-Rollout" program and the expected system state and environment where it executes.
• What, very specifically, did you change about Views that precipitated the problem?

That must have a cause that probably isn't a bug.

• What are the "visibility" settings for the block?
• Are there any custom themes or custom modules on the site?
• What is the theme?

Unfortunately Drupal 8 is no longer supported here. To troubleshoot console errors in Drupal, disable script aggregation on the Performance screen and clear caches. Then you will see the actual JS files involved.

The way to investigate changes is as follows:

• Check out a Git working copy of Drupal.
• Search the commit contents for the removal: git log -S'zebra striping'
• The most recent commit mentioning those words is:

commit 9f723a46933159b41771f396b71c11156192c3c0
Author: webchick <webchick@24967.no-reply.drupal.org>
Date:   Mon Apr 15 08:21:21 2013 -0700

    Issue #1968322 by effulgentsia: Remove unused $id and $zebra variables from templates.

• Read over #1968322: Remove unused $id and $zebra variables from templates → to understand the reasons and note the affiliated change record, Zebra striping variables removed from templates → .

So this is an intentional change with suggestions of a modern replacement.

You will have to give here a lot more information about where you put Drupal and what your expectations are for how it should load. As it is, you have an index.php that is probably from Wordpress or which was set up to load Wordpress, rather than Drupal's index.php.

It's quite clear, in the file /home1/zoom/public_html/index.php, at line 24, there is code attempting to load a Wordpress code file called wp-blog-header.php, which does not exist. I don't think we can help beyond that. There doesn't seem to be much involving Drupal here.

Document the steps to reproduce. Put that information in the issue summary.

I used https://simplytest.me and followed the steps but I could not reproduce this bug. I am tagging this for improved steps to reproduce.

Put the steps to reproduce in the issue summary. The current merge request fails a DateTime test.

Thanks for trying to reproduce. I'm tagging this for an update to the reproduction steps.

One other issue could be sluggish syncing between the host and the container. If the host isn't Linux, and it's, for example, Mac OS, be sure that mutagen is running.

What command? Did I suggest a command?

FYI the default files permissions in a DDEV install are as follows:

ls -al sites/default/files
total 8
drwxr-xr-x  8 user1  staff  256 Sep  3 13:28 .
drwxr-xr-x  8 user1  staff  256 Sep  3 13:26 ..
-r--r--r--  1 user1  staff  486 Sep  3 13:27 .htaccess
drwxrwxr-x  8 user1  staff  256 Sep  3 13:28 css
drwxrwxr-x  6 user1  staff  192 Sep  3 13:28 js
drwxrwxrwx  3 user1  staff   96 Sep  3 13:27 php
drwxrwxr-x  2 user1  staff   64 Sep  3 13:27 styles
drwxr-xr-x  3 user1  staff   96 Sep  3 13:27 sync

If yours are different, and you are still struggling with this I suggest instead the #support channel in Drupal Slack because I don't feel these comments are helping you.

As I said I think default/files/php needs to be 777 also. I could be wrong but AFAICS you did not try that.

Thanks for the report and a patch. What is $raw_term->parents on this site and how do we set this up to reproduce the bug?

Unless ddev is actually running as a user that maps to a host user, which is unlikely, I think default/files/php needs to be 777 also.

I am unable to produce this on the 11.x. I also am using DDEV.

You should take that error at face value, because it is a low-level PHP error. Is the web server process user allowed to create directories there?

Could we see your unit test code?

Could the issue summary be cleaned up not to say “traversal” because this isn’t a traversal? Since it’s a critical now it should be accurate.

It’s displaying the install path when there is a coding error causing an exception in settings.php.

Original image height or width is zero.

What is the image.settings:preview_image config set to on those sites?

That update script was in 6.2.2. Did it not run then?

Was this site patched with https://www.drupal.org/project/webform/issues/3328205 ✨ Add print download bulk action Fixed ?

Asked also at: https://drupal.stackexchange.com/questions/320698/how-to-automatically-r...

Drupal 9 is no longer supported here.

This is the Drupal core issue queue. You should ask for support in the contributed projects you are using in this setup.

If there are image styles like cropping, etc, that will by default essentially "freeze" a Gif to one of its frames.

Perhaps this will help: https://www.drupal.org/project/animated_gif →

It's true—it's definitely broken.

Quite a few sites have already taken that upgrade so there must be some more steps to reproduce. I think in HandlerBase:getEntityType, $this->getViewsData()->get($relationship['table']) is NULL for a given view configuration. Can you get the stack trace?

I am linking another issue that was uncovered by this update.

For a bug report we need technical details which explain precisely how to reproduce the bug.

In addition it is helpful to include a stack trace.

What is the nr_media module?

Drupal 9 is end of life so we can close this. 9 isn’t supported here.

Duple has a large contribution guide → . But I think you are looking for information on how to create a merge request → .

The aria-describedby attribute is set and it is set to the correct element, and the screen reader announces it.

<div class="js-form-item form-item js-form-type-managed-file form-type--managed-file js-form-item-upload form-item--upload">
      <label for="edit-upload-upload--ww6zLjlooeg" id="edit-upload--aatPBnZtlHw--label" class="form-item__label">Add file</label>
        <div id="edit-upload--aatPBnZtlHw" class="js-form-managed-file form-managed-file is-multiple has-upload no-value no-meta">
  <div class="form-managed-file__main">
    
    <input aria-describedby="edit-upload--aatPBnZtlHw--description" data-drupal-selector="edit-upload-upload-ww6zljlooeg" type="file" id="edit-upload-upload--ww6zLjlooeg" name="files[upload]" size="22" class="js-form-file form-file form-element form-element--type-file form-element--api-file" data-once="fileValidate auto-file-upload"><input class="js-hide upload-button button js-form-submit form-submit" data-drupal-selector="edit-upload-upload-button" formnovalidate="formnovalidate" type="submit" id="edit-upload-upload-button--U-Kw8pzuZKk" name="upload_upload_button" value="Upload" data-once="drupal-ajax">
  </div>

  
    <input data-drupal-selector="edit-upload-fids" type="hidden" name="upload[fids]">
</div>

            <div id="edit-upload--aatPBnZtlHw--description" class="form-item__description">
      One file only.<br>2 MB limit.<br>Allowed types: png gif jpg jpeg webp.

    </div>
  </div>

I put the full stack trace in the issue description.

https://git.drupalcode.org/project/drupal/-/blob/11.x/core/modules/conte...

Does the diff from the current merge request work for you?

This is specifically a Drupal 10 issue.

It might be good to know the config.preferred-install config value that is in composer.json. But all-in-all I don't think this is a Webform issue.

I just installed drupal/webform on a site and I verified the version information is in its info file. So whatever is happening on that site, it isn't a bug in Webform module. To be absolutely clear I am talking about webform.info.yml which is in the root directory of this module.

Execute composer show drupal/webform and report back with what it says in the source field.

The packaged release contains:

# Information added by Drupal.org packaging script on 2024-07-19
version: '6.2.7'
project: 'webform'
datestamp: 1721425240

If that is missing you probably have a Git checkout of the project instead.

🐛 No release history was found for the requested project (Drupal). Fixed

You simply must share your code that triggers a bug for a bug report.

This seems a duplicate of 🐛 No release history was found for the requested project (Drupal). Fixed . Please confirm.

This seems a duplicate of 🐛 No release history was found for the requested project (Drupal). Fixed . Please confirm.

This seems a duplicate of 🐛 No release history was found for the requested project (Drupal). Fixed . Please confirm.