#Needs issue summary update

#293 applies and works for Drupal 10.5

Please stop posting patches. Issues are solved with merge requests.

xjm → credited catch → .

xjm → credited effulgentsia → .

xjm → credited lauriii → .

Crediting major triage per @alexpott in #30:

catch, cilefen, effulgentsia, lauriii, xjm

Fixing attribution.

Amending attribution.

For posthumous review.

🐛 New constants in \Drupal\Core\Theme\Registry are private but they are accessed with static:: Active introduced a regression that reminded me why we need this policy, and also static analysis that will help in the future.

We haven't had a chance to hear back from @wim leers about https://git.drupalcode.org/project/experience_builder/-/merge_requests/1...
but since this issue just adds test coverage I think it is practical to commit. We could still change that behavior later

I will merge

Thank you for sharing your idea for improving Drupal.

We are working to decide if this proposal meets the Criteria for evaluating proposed changes. There hasn't been any discussion here for over 8 years which suggests that this has either been implemented or there is no community support. Your thoughts on this will allow a decision to be made.

Since we need more information to move forward with this issue, the status is now Postponed (maintainer needs more info). If we don't receive additional information to help with the issue, it may be closed after three months.

Thanks!

Re-rolled 🫰🏻

Amending attribution.

Amending attribution.

Assigning @tedbow for commit, but needs a rebase

penyaskito → credited larowlan → .

LGTM, thanks for the extra explanations @tedbow and @larowlan!

Maybe more a wontfix, actually.

Drupal picked an architectural direction for this in that REST and JSON:API do not use the Render system, and it is the client's responsibility to perform rendering and sanitization rather than Twig's or core utilities'.

Please stop rerolling this. See #197. I am the subsystem maintainer for Taxonomy and a release manager for core, and as I stated 2.5 years ago, I don't think the current approach is viable. I agree with @anybody in #209 that in this instance a new issue would probably serve us better since we need an entity-model approach rather than a database table approach.

For those relying on this patch to work around this deficiency in Taxonomy's data model, use the contrib module: https://www.drupal.org/project/taxonomy_entity_index →

Thanks!

I think the change record also needs to removed!!

Maybe @penyaskito can still review this today, I can’t 😇

Automatically closed - issue fixed for 2 weeks with no activity.

#10: 📌 Add field and entity access check on `ApiAutoSaveController::post()` Active landed, but had the "field access" bits descoped to 📌 Add field access check on `ApiAutoSaveController::post()` Active .

@penyaskito requested some extra test coverage.

I asked some Qs — AFAICT this entire problem is caused by #2862574: Add ability to track an entity object's dirty fields (and see if it has changed) → , would be good to see that A) confirmed/denied, B) if confirmed, a @todo pointing to it.

@divyansh.gupta thanks - the changes look good to me. I will leave rtbc to someone else so I can commit.

@alexpott,
Made the suggested changes, Please review!!

In Drupal core changes are made on on 11.x (our main development branch) first, and are then back ported as needed according to the Core change policies → . Also mentioned on the version → section of the list of issue fields documentation.

The fix in #30 also needs to handle update.php, so in full:

if (isset($GLOBALS['request']) && '/subdirectory/index.php' === $GLOBALS['request']->server->get('SCRIPT_NAME')) {
  $GLOBALS['request']->server->set('SCRIPT_NAME', '/index.php');
}
elseif (isset($GLOBALS['request']) && '/subdirectory/update.php' === $GLOBALS['request']->server->get('SCRIPT_NAME')) {
  $GLOBALS['request']->server->set('SCRIPT_NAME', '/update.php');
}

This issue was originally about help text from system module. It then became a broad discussion on CSS and finally, AFAICT, it is about broadly using heading tags in help pages. Whether the solution is CSS or heading tags, it ought to be scoped more broadly than just system.module, so I'm changing the component to help.module

I tried to follow the steps to reproduce against 11.x but getting slightly different results. For a start, going to /admin as an anonymous user just shows an Access Denied message. That's fine, but doing the same after logging in as an authenticated user results in a redirect loop. Also not seeing the same thing for /foobar, I'm redirected to the front page instead. Can anyone confirm the same?

Re #33:

BrowserTestBase really doesn't handle infinite redirects very well

I think instead we can use the guzzle http client to make requests to the site. There is an option not to follow redirects, so we can simply inspect the headers. There is also a max redirects option, so we could use that too.

Automatically closed - issue fixed for 2 weeks with no activity.

Too good to be true, if we can do !1086-note_540820 this is RTBC.

🐛 Page status changes from "Published" to "Changed" even when no actual changes are made Active just landed.

Rebased. Restoring RTBC.

The Needs Review Queue Bot → tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.

Thank you for creating this issue to improve Drupal.

We are working to decide if this task is still relevant to a currently supported version of Drupal. There hasn't been any discussion here for over 8 years which suggests that this has either been implemented or is no longer relevant. Your thoughts on this will allow a decision to be made.

Since we need more information to move forward with this issue, the status is now Postponed (maintainer needs more info). If we don't receive additional information to help with the issue, it may be closed after three months.

Thanks!

Update on #59:

1. The entity cache preloading itself isn't the problem, just suspending a fiber from entity load is enough to trigger some very weird placeholder replacement bugs with Umami.

2. After realising that, I wondered if there was a particular entity type causing the problem, and it turns out there is - it's file entities. If I skip the fiber suspend only when loading file entities, I don't get the bug.

3. This means that fiber suspending during file entity loading is sufficient to trigger the bug. That might be something specific to file entities, e.g. they're being rendered via a reference widget so maybe something in there, or it might be that on the umami front page this happens to be the only entity type that triggers the problematic code path a bit further up the call stack.

Still no idea what the actual bug is, but at least have managed to narrow it down from 'every possible situation that loads an entity' which is where I started and led me into several dead ends.

The blocker is in so this is technically unblocked, although it is definitely still stuck for now.

Left comments in the MR.

I tried to fix the last MR from @rajab natshah.

Working on it!!

I also if we need to think about empty media queries in \Drupal\toolbar\Element\Toolbar::preRenderToolbar()

Let's not add the new API here. It's going to introduce subtle bugs that are worse than the deprecation being fix here.

Let's change the getMediaQuery() to

  public function getMediaQuery() {
    return trim((string) $this->pluginDefinition['mediaQuery']);
  }

And the use in to

  $media_query = $breakpoint->getMediaQuery();
  if ($media_query !== '') {
    $source_attributes->setAttribute('media', $media_query);
  }

Drupal 10.4.6 here, same issue.

Any chance I could apply one of the proposed patch?

Why can't we just do something simpler like this?

  public function getAliasByPath($path, $langcode = NULL) {
    // Normalize the path: handle empty/null paths and ensure proper formatting.
    if (empty($path) || $path === '') {
      $path = '/';
    }

    // Ensure the path starts with a slash. If it doesn't, prepend one.
    if (!str_starts_with($path, '/')) {
      $path = '/' . $path;
    }

That seems to fix things that I tested from the comments above

• https://www.example.gov//
• /index.php5
• /index.php.
• /index.php.?hTTp://r87.com/n
• /index.phpI-dont-exist
• /index.php.php/some/path

This also occurs if someone just adds an extra / to the homepage, for example https://www.example.gov// which the htaccess route (3043779-htaccess-no-php-danglers) doesn't cover that situation.

And the other patch (3043779-source-path-has-11.x) results in a new error

The website encountered an unexpected error. Try again later.

Error: Call to a member function get() on null in Drupal\path_alias\AliasManager->getAliasByPath() (line 199 of core/modules/path_alias/src/AliasManager.php).
Drupal\protected_pages\EventSubscriber\ProtectedPagesSubscriber->checkProtectedPage(Object, 'kernel.response', Object)

The Ideas project is being deprecated. As discussed in a core committer meeting issues that are adding modules are being moved to the Drupal CMS project for discussion.

There's something very, very weird going on with the bugs here. I pushed a new branch - at https://git.drupalcode.org/project/drupal/-/merge_requests/12469 which has the absolute minimum changes to cause the bug - no entity preloading, just the fiber suspend in the same place. That I guess shows it's not the preloading causing the problem as such.

It's easy to reproduce with the combined MR, you just have to clear caches and load the umami front page to see broken rendering.

Tested this out locally really quick and I can see that drupalSettings.bigPipePlacheolderIds has 3 unreplaced entries.

{
    "callback=Drupal%5Cblock%5CBlockViewBuilder%3A%3AlazyBuilder&args%5B0%5D=umami_views_block__recipe_collections_block&args%5B1%5D=full&args%5B2%5D&token=LSXAUcXQcqsNxZk01EJ-DceQbM_P3ovAc_wniqiM2X0": true,
    "callback=Drupal%5Cblock%5CBlockViewBuilder%3A%3AlazyBuilder&args%5B0%5D=umami_views_block__promoted_items_block_1&args%5B1%5D=full&args%5B2%5D&token=XKowAdwoi2xYmp7GHvIqQteOfgS9deS_4OJckMkYGHQ": true,
    "callback=Drupal%5Cblock%5CBlockViewBuilder%3A%3AlazyBuilder&args%5B0%5D=umami_banner_home&args%5B1%5D=full&args%5B2%5D&token=j1t-pelbFkxnp6XgWmQ0AG2woBVFHKrU7calg2QLe8M": true
}

I'm uploading a new patch, this is compatible with drupal 11.2.0-rc2

I'm uploading a new patch, this make it compatible with drupal 11.2.0-rc2

Applied those suggestions which look good, but there are still bizarre bugs with the MR. It's easy to reproduce with the combined MR, you just have to clear caches and load the umami front page to see broken rendering.

I went down a whole rabbit hole of the fibers logic, but after exhausting that, I'm back to an issue with the entity load logic again, it is potentially something like the wrong entity getting returned sometimes, which causes Umami to render different blocks to the ones requested, or something.

The good news is that 📌 Try to replace path alias preloading with lazy generation Active appears to be working without the same problems, although it needs 📌 Views entity rendering should use a lazy builder/placeholder Active to be more effective.

NR for a small commment improvement suggestion I made on the MR. It's okay to re-RTBC the issue if the suggestion is accepted (no need for an extra review cycle over something small).

I updated the issue credit, removing credit for a number of old rerolls where the contributor did not add anything else to the issue. I left credit for a couple people who were doing the reroll in the context of a mentored event as their first contribution. I also added credits for a number of reviewers.

I'm not able do do the review myself at the moment, but at least having the crediting in order should save some time.

Saving mentor credits as per #33.

This came up as a daily BSI target

Think this could do with an issue summary update, using the standard issue template. To include steps to reproduce, proposed solution, etc.

Thanks!

A couple comments on the MR that look like bugs, not sure if related to the Umami test failure.

Wanted to give this one more bump before closing

I did that last one wrong

Reroll for 10.5.0

Attached a static drupal-core--2025-06-24--3049332--mr-12460.patch file to this point of MR12460.
To be used with Composer Patches and Drupal 11.2.0

This is probably a duplicate of 📌 Add a grace period to ChainedFastBackend when last_write_timestamp is ahead Active at this point - the other issue is much newer and the approach is different, but it's trying to solve the same problem.

Thank you for creating this issue to improve Drupal.

We are working to decide if this task is still relevant to a currently supported version of Drupal. There hasn't been any discussion here for over 8 years which suggests that this has either been implemented or is no longer relevant. Your thoughts on this will allow a decision to be made.

Since we need more information to move forward with this issue, the status is now Postponed (maintainer needs more info). If we don't receive additional information to help with the issue, it may be closed after three months.

Thanks!

This came up as a daily BSI

The issue summary appears incomplete and could use some love. Notably missing steps to reproduce.

I'm hoping to get rid of path alias preloading in 📌 Try to replace path alias preloading with lazy generation Active so that might not be a concern, once that issue lands.

I created a new page, maybe it can be added to the menu?

https://www.drupal.org/docs/drupal-apis/migrate-api/fixing-errors-due-to... →

> Note that the current MR will disable core's alias pre-loading optimization

What are the implications for performance?

BTW, as a workaround, without this MR you can edit your system.site.yml config file manually, and set a path alias as the front page, then import config.

It works, though clicking on home links makes your browser go to http://mysite.com/mypathalias rather than http://mysite.com/

The MR now applies to D11.2.0, thx!

Rebased MR on latest 11.x, adjusting the hooks to be placed in classes.

a.dmitriiev → made their first commit to this issue’s fork.

sorry, commnt mismatch.

- 3252288-50.patch is against 11.x
- 3252288-51_against_11.2.0.patch is against 11.2.0

Still NW because no test was added, but this patch applies on 11.x, from merge request https://git.drupalcode.org/project/drupal/-/merge_requests/12448

Patches #28 and #43 does not apply on 11.2 branch..

@nicxvan they seem like dupes, haven't looked how much overlap there is.

Should there be a separate issue to move the form?

If we move the form do we then also move the route, permission and menu links? I don't think there is a yaml equivalent for these outside of modules. Is there some other issue to facilitate those things? I think probably it needs to stay where it is.

Rebased to get a fresh test failure baseline. Removing needs tests tag because these were added.

Thank you! The changes have been committed.

I am going to restore the issue summary, which was removed from a previous edit.

This is surely a major.

I just moved my blog site to a cPanel-based host, and *NOTHING* worked.

I used the .htaccess redirect from https://www.drupal.org/hosting-support/2021-09-21/unable-to-set-document... → to get the document root as /web to work, but then I hit this.

There is one failing test, \Drupal\FunctionalTests\Bootstrap\UncaughtExceptionTest::testUncaughtFatalError, which passes locally for different versions of PHP. Not sure why it is failing here though.

Setting to NR because the existing changes can be reviewed as well as checking if there are other instances that need to change.

to check

1. core/modules/system/tests/src/Kernel/Theme/FunctionsTest.php
2. core/tests/Drupal/Tests/Core/Logger/LogMessageParserTest.php