@cilefen

@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.

I don't agree that this isn't a breaking change, because it is in fact in some cases. For Drupal sites on shared hosting, a bugfix release like 1.1.4 may require opening a support ticket with the hosting company to have a restart. And yes, I understand that mitigations on the library maintainer's side are not easy. They are not even practical in many cases.

Drupal's PHP requirements → say nothing about needing to restart the PHP process during deployments. I asked at #3153335: Document $settings['deployment_identifier'] (and that it fixes moved class autoloader caching) → if that documentation would be sufficient in a case like this. If it isn't we need to update the PHP requirements accordingly.

Does changing the identifier fix cases like 🐛 Class "Doctrine\Deprecations\Deprecation" not found Active , where a file tree relocates without namespace changes?

Usually for bug reports we require the steps to reproduce the bug on a newly-installed Drupal site. If you would like to add those to the issue summary it may become clear where this issue belongs.

This question seems to be about the webform_rest module, so I am moving this issue to that project's issue queue.

Thank you for this bug report.

Could you please provide more detailed steps to reproduce the issue? Specifically, it would be helpful to clarify what you mean by "upstream environment" and to elaborate on the "systems which use the URL as a primary key in the database rather than an auto-incrementing ID."

For instance, are you referring to systems like Drupal?

Is this bug report about the Gin theme?

I am updating the tags according to the issue tag guidelines → and I am marking this in need of additional reproduction steps.

@sbrenner02 Have you been able to reproduce the bug on a clean Drupal installation?

Have you gone as far as to reduce the scope of the migration to begin identifying the problem area?

https://github.com/doctrine/deprecations/compare/1.1.3...1.1.4

@gaelicmichael Metatag seems uninvolved on the site where you see this one. What exactly is Drupal doing when this occurs?

I made some small edits.

The datetime module did not change between Drupal versions 10.3.8 and 10.3.10. Which updates executed with update.php on the site?

When I install a default 10.3.8 site in English, there isn't a date format at /admin/config/regional/date-time that is Y-m-d H:i:s. There is:

• Default long date l, F j, Y - H:i
• Default medium date D, m/d/Y - H:i
• Default short date m/d/Y - H:i
• Olivero medium j F, Y

But just to test I changed "Default short date" to m/d/Y and updated Drupal to 10.3.10. There are no Drupal core database updates between 10.3.8 and 10.3.10 when running update.php. The date format did not change.

It is likely there are additional steps to reproduce that are not recorded in this issue. We require more information from you to proceed with this bug report.,

In fact I am certain.

Understood. I think this is a duplicate of 🐛 Install Fails on WAMP server with php 8.3 Active .

Unfortunately, I remain unable to reproduce the bug that way.

I followed the steps to reproduce as currently written but I can't reproduce this bug. Because of that, I tagged this "Needs steps to reproduce" and postponed it on getting whatever other steps are required.

Can you update the issue summary, providing specific versions please? In that way we can find the commit that changed the behavior.

This is tested in a few places by necessity but in core/modules/system/tests/src/Functional/System/FrontPageTest.php specificallly. Is that test missing something?

In addition we need a summary description of the platform on which you are trying to install Drupal.

Drupal install is heavily tested. This is either a platform requirements issue or a rare bug, which may already be reported. We need more information from you to investigate the situation.

1. Check the browser console log for more details.
2. Check the PHP error log for errors or exceptions.

I am not convinced by the details.

I am almost certain there already exists an issue for this. Can you investigate please?

Any translatable string may be overridden in settings.php, as I have written before.

What is the purpose of this task?

Look at the page source to see the HTML. Anyway class="text-align-center" is on images so I think this is more to do with themes than with CKEditor or with that web site's text filters configurations.

Would you please answer both of my questions?

Is data-align="center" present in the rendered page markup? Which theme are you using?

Would you please run drush updatedb -vvv for more information?

I want you to be aware that support requests posted here may go months with no reply. The #support channel in Drupal Slack → is better for real-time help.

I am unsure as to why this is a bug. You can override any translatable text in settings.php.

I don't understand the nature of this report as a bug. Can you explain in some more detail what the problem is here?

Why should the alternate text should be limited to 255 characters?

What is the purpose of this change?

Ok, that all makes sense then.

Was this completed in 📌 Symfony 7.2 Active ?

Separately, 🐛 Regression? PHP 8.4 session.sid_length and session.sid_bits_per_character are deprecated Active seems to be the other problem this issue intends to fix, "sites that have them explicitly set", so I marked it a duplicate.

On those sites does services.yml or one of the php.ini set those configurations?

This looks like a duplicate of 🐛 Drupal core update + update to symfony/http-foundation causes certain views blocks to cause a "client error" and breaks page display. Active . Can you confirm that?

Thanks for this.

This needs a merge request to be tested, and as you have said, some kind of a regression test.

I am updating this issue's tags according to the issue tag guidelines → .

greggles → credited cilefen → .

Not every site has this configuration problem. It would be good to understand the real reason it occurs.

How would another developer reproduce this bug? Please add those steps to the issue summary.

composer require drush/drush, as you have now done, is the only supported way to use Drush.

From https://www.drush.org/13.x/install/:

It is required that Drupal sites be built using Composer, with Drush listed as a dependency.

@wcndave: Requiring Drush that like that is the only supported way to use Drush in its current versions.

I continue not to be able to reproduce this bug. Here is what it did:

1. Installed a new Drupal 11 site.
2. Added an article.
3. For the body field I selected Text Format: Full HTML.
4. I switched the editor to source mode.
5. I pasted the HTML given in the issue summary.
6. I saved the node.
7. I examined the HTML. There are no changes.
8. I edited the node.
9. I switched the editor to source mode.
10. I examined the HTML. There are no changes.

Because you have a site that can reproduce the bug we need much more detail about how CKEditor and the text formats are configured.

I am setting this to postponed pending that information.

Nor do we. You opened this as a bug with no steps to reproduce.

I can't seem to reproduce this. Please add the complete steps to reproduce to the issue summary. Using a site like https://simplytest.me is a way to create a clean Drupal site for bug reproduction.

Also, see if you can reproduce the bug with the CKEditor 5 demo so we can understand if this is CKEditor or a Drupal filter causing it.

/var/simplesamlphp/vendor/twig/twig/src/Environment.php isn't Drupal, but it is processing Drupal templates, so you have an unusual setup that you must explain. This is not a Drupal bug.