#Needs tests

Postponed on 📌 Add a fallback classloader that can handle missing traits Active

Patch from #74 works on Drupal 10.4 for us. Thanks all!

@jeremey1606: Are you planning on doing something here?

Hi @andy-blum, I've added the gap between the site logo and site title & slogan. Attaching the screenshot of the after fixes for your reference. Please review the changes.

Thanks!

Updated the patch so that the PathautoBulkUpdateForm supports selecting bundles for other entities than nodes.

The MR has tests that pass, so removed the "needs tests" tag.

It is missing a "-" character at this place :

Hello,

The latest patch #23 seems to break CSS aggregation for me.

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.

kumudb → closed merge request !11399

I've converted the patch from #71 to a MR to comply with current Drupal processes. Tests are successful and test-only changes show that the test will fail without the fix.

nico.b → made their first commit to this issue’s fork.

Merged latest 11.x code into MR 10820, now it applies again. I wonder which will happen first, getting back to RTBC here again, or core moving faster than we can keep up with here...

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.

The Needs Review Queue Bot → tested this issue. It fails the Drupal core commit checks. 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.

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.

Not sure but we can fix with this code,

Modify DraggableListBuilderTrait or override buildRow() in DraggableListBuilder:

public function buildRow(EntityInterface $entity) {
  $row = parent::buildRow($entity);

  foreach ($row as $key => $value) {
    if (!is_array($value)) {
      $row[$key] = ['#markup' => $value];
    }
  }

  return $row;
}

I tried to reproduce this issue but:

• The issue should be raised against 2.0.x because the route given in issue summary does not exist in 8.x-1.x
• I could not find any issue on /admin/config/development/performance/purge. So if you could provide steps to reproduce this issue and this patch does not make any changes.

Working on it.

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

Here's a patch of the latest MR for composer

I made a small update to the MR to use $info->getDataTable() to get the table name and only include it if the entity has a data table.

I see some modules that provide views integration use something along the lines of
$table_name = $info->getDataTable() ?: $info->getBaseTable();
to get the table name for joining entities. Im not sure if thats appropriate here or if doing so would break existing views.

So I'm just adding this join to the data table which make it work with the parent issue.

A follow-up would be to make a deriver class because as-is this will have some problems without manual YAML modification (migration_lookup, etc...) if using migrate_upgrade / migrate_plus entities.

FYI,

The patches provided here work with page_manager patches till this one https://www.drupal.org/project/page_manager/issues/2858877#comment-14787260 ✨ Allow for block visibility rules Needs work

But does not work with subsequent patches or with the MR, as the page_manager.condition_access_resolver service has been removed.

You can use the MR and apply this patch: https://www.drupal.org/project/page_manager/issues/2858877#comment-16016365 ✨ Allow for block visibility rules Needs work

Hopefully this mentioned page_manager patch will get into the MR (https://git.drupalcode.org/project/page_manager/-/merge_requests/24).

catch → closed merge request !11377

Committed/pushed to 11.x, thanks!

The patch in #35 fixes the issue for me with no images and with Stage File Proxy on Drupal 10.4.3.

Leaving as Needs Work though for the comments in #37.

Or actually postponing is probably better.

Closing this as a duplicate then.

Yep, works out of the box using the issue fork from 🐛 Field formatter with inline settings is missing field formatters from the referenced (media) entity type Active :

Great stuff :)

Ended up in this issue while debugging another one in the Linkchecker module, which uses Dynamic Entity Reference.

It would seem the core lib/Drupal/Core/Entity/Query/Sql/Tables.php does not account for the existence of computed fields. However, does it really make sense for code in "Sql/Tables" to account for that? Where in the entity query interface or internals would it make sense to prevent computed fields from making it into entity queries at all?

This is probably fixed through 🐛 Field formatter with inline settings is missing field formatters from the referenced (media) entity type Active .

The "Field formatter with inline settings" never used the "real" field definition, but instead created a new one, meaning some field definition settings were reset to their default values (and third_party_settings probably got ommited entirely).

Please test, once that issue is merged (or test the issue fork directly).

POSTPONED on 🐛 Field formatter with inline settings is missing field formatters from the referenced (media) entity type Active .

Oh wow, thanks @ivnish for wrapping this up!

Think that alternative approach works fine.

From re-reviewing the docs on options_allowed_values, I think we need to cache it on both, yes. Leaving at NW for this.

After enabling AJAX in a Views page in Drupal 11.x-dev version that lists Articles with an exposed Article Title filter, pagination behaves unexpectedly. The issue occurs under the following conditions:

1. The pager is set to display 10 items per page.
2. Navigating through multiple pages (e.g., reaching the 4th or 5th page)
3. Performing a search for a unique item results in a blank page instead of displaying the expected results.

A screen recording has been provided to demonstrate the issue.

https://www.drupal.org/files/issues/2025-03-05/pagination_search_issue_w... →

Upon debugging the issue further and for writing the test properly.
found out that the issue which is mentioned in the description to run the update-countries.sh to Update the CountryManager.php

here the .sh file it self is generating the error with the 11.x code base and not updating the CountryManager.php file.

i setup the drupalsetup using ddev and was trying to run the sh file like this ddev exec php core/scripts/update-countries.sh
and got the following error

PHP Fatal error:  Uncaught Error: Call to undefined function Drupal\Core\Locale\t() in /Users/abc/Developer/DrupalProject/core/lib/Drupal/Core/Locale/CountryManager.php:45
Stack trace:
#0 /Users/abc/Developer/DrupalProject/core/scripts/update-countries.sh(43): Drupal\Core\Locale\CountryManager::getStandardList()
#1 {main}
  thrown in /Users/abc/Developer/DrupalProject/core/lib/Drupal/Core/Locale/CountryManager.php on line 45

keep this on need work as need more input on this error of the .sh file.

@berdir's points in #7 and #9 still haven't been adequately answered. Should the cache key instead use the entity ID?

Re #92

#89 works

Patches are no longer used for updating drupal core → . If this is ready then it should be applied to the current merge request (which also needs rerolling) or create a new merge request.

The patch also doesn't have tests. Its possible the MR does but the diff is currently too large for that to be clear.

Thanks all! Committed!

ivnish → closed merge request !20

goz → changed the visibility of the branch 3.0.x to hidden.

Added the tests. Please review.

#89 works

Updated the MR to reflect comment #34 and earlier.

Thanks! Still needs tests

Why not do something like this... move the breadcrumb assertions to the tests that are actually testing the field UI pages. They don't really belong in those trait functions IMO. The other assertions in there are making sure the form is progressing correctly.

As for CommentNonNodeTest, it does more assertions on other breadcrumbs so we can't remove the breadcrumb block from there anyway.

This new MR decouples breadcrumbs from fieldUIAddNewField and fieldUIDeleteField though. No documentation changes, CR, or additional tests required.

Agreed with @catch, also making this a child issue of 🐛 Prevent saving config entities when configuration overrides are applied Needs work which is about enforcing this in the long-term for all config.

Converted patch from #3098245-8: Clone nested inline blocks when translating → into MR + updated it after ✨ Fails on translated inline blocks Closed: duplicate got merged.

Came up as the daily BSI target.

May still be relevant but agree probably should have simple test coverage to make sure a trait works.

One comment on the MR.

Does a folow-up exist?

Not yet, I can probably create on later this week. if others want to beat me to it, go ahead.

Also not sure why this is adding a new entry to the phpstan baseline, is it somehow picking up a pre-existing issue it didn't pick up before?

Yes.

catch → closed merge request !5800

Committed/pushed to 11.x, thanks!

Did my best with commit credit but this is a long issue with a lot of commenters on it so apologies if someone was overlooked.

The issue summary still has:

Decide what to do with pre_render (and post_render) as theoretically those could also set or change the type.This probably deserves a follow-up as it has far more edge cases than lazy builders because the array specifying a lazy builder cannot have a #type set.

Does a folow-up exist?

Also not sure why this is adding a new entry to the phpstan baseline, is it somehow picking up a pre-existing issue it didn't pick up before?

Sorry for all the rebasing spam. I've been trying to keep this up to date despite all of the other recent commits. Practically every change to the performance test forces a rebase and update of this MR.

I am working on writing PHPUnit test cases for the update-countries script. The test currently verifies the following:
• The script correctly reads and processes the territories.json file.
• Excluded country codes (e.g., ‘EU’, ‘UN’, ‘ZZ’) are not included in the final country list.
• The updated country list is properly written to CountryManager.php.

Are there any additional test cases that should be considered to ensure full coverage? Feedback is welcome!

Thanks for clarifying this, @catch 😊

catch → closed merge request !10908

Edit: I wonder if test classes are considered @internal, meaning a CR and deprecation wouldn’t be strictly necessary. However, doing so is certainly the more considerate approach.

fwiw this is exactly how we approach it most of the time, if we really need to skip deprecating and introduce a hard break then we can and will, but if it's straightforward to provide bc then that's preferred to avoid disrupting contrib modules too much/often in minor releases.

Committed/pushed to 11.x, thanks!

@hswong3i
I understand that people could need this and ✨ File target: add support for local file path as source Needs review together, but for keeping the issues focussed, it is better to keep them separated. Instead, maybe it is better to open a separate branch called '2928904-2968671-media-and-local-file-do-not-merge' for that.

For people would like to see this issue to be resolved, we need to have automated tests - and there appears to be an issue with updating existing configuration. See Remaining tasks for details.

Since people already keep testing #105 ✨ Add a mapping target to media field Needs review and feedback directly, I give a merge to https://git.drupalcode.org/project/feeds/-/merge_requests/161 for simplify.

Moreover, I merge changes for local file import logic from https://www.drupal.org/project/feeds/issues/2968671 ✨ File target: add support for local file path as source Needs review , else this 2 MR will get conflict and working together.

I read the MR and did a brief manual test and can't see any changes that are required.

Committed ea29660 and pushed to 11.x. Thanks!

Also published the change record.

Hi @karlshea, I'm moving to 3.x too. And actually using a patch from this issue. But AFAIK it indeed works. Not 100% sure about views facets summary as it was detached but views block seemed straighforward...

I ran pipeline. Tests needs some updates

Removing patches

I converted #20 into an MR and added a unit test.

I just tried Facets 3.x with views_filters_summary, configurable_views_filter_block, and bef—and most of it is broken with AJAX. It'll be great the day that might happen, but as of now it's no better a situation than using this patch which at least sometimes functions.

Agree with #13, this doesn't seem valid.

I merge in the upstream changes from 11.x and fix the merge conflicts. Setting back to RTBC.

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

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!

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!

For me, the combination of:
- custom module from #3;
- using the Format "Boostrap table" #6 with an added hidden field from (and sorting the table by this hidden field).
solved the problem with duplicates in View of content and paragraph as a relationship.

Also, I tried the patch from #117, both with Distinct on and off, but I can't find the difference.

I'm using Drupal 10.3.10, btw.

Rebase seems fine, random javascript error.

We're adding some gap between the site title & slogan, but there's currently none between the text of this block and the site logo. Can we add the same --sp0-5 between the image and the text as we have between the title & slogan?

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

This is a straight 10.4 re-roll. Git stats between the patch in 72 vs this one are pretty close so it shouldn't be missing anything. Leaving at NW since no tests were added, nor was it even modernized for Drupal 11 and attributes instead of annotations.

Was previously tagged for tests which are still needed it appears.

MR in #28 didn’t fix the actual issue where, if the same date is provided in the filter, it won’t filter the full day as expected.

As the problem lies in:

• For offset type with identical min and max (e.g., +1 day):

• $a = '***CURRENT_TIME***+86400', $b = '***CURRENT_TIME***+86400'
  

  .

• Query: $field
  

  BETWEEN ***CURRENT_TIME***+86400 AND ***CURRENT_TIME***+86400
  

  .

• Matches only the exact timestamp, not the full day, often yielding no results.
• For date type, with identical min and max (e.g., 2025-03-03):
• Both $a and $b will be same 2025-03-03 00:00:00 with no result

Solution:

• Offset Type:
• Add check:
  

  if ($this->value['min'] === $this->value['max'] && $b_original % 86400 === 0).
  

• Adjust $b to end of day (offset_days * 86400 + 86399).
• Retains behavior for offsets with time (e.g., +1 day 4 hours).
• Date Type:
• Add check:
  

  (date('H:i:s', strtotime($this->value['max'])) == '00:00:00').
  

• Adjust $b to end of the day 23:59:59

Added test for edge cases mentioned in #20.

I have tested the updated code on Drupal 11.1.1 and reviewed the changes thoroughly. With the updates made to the script, the update-countries.sh file now runs without any issues. Additionally, I have ensured that the code aligns with the latest version of the 11.x branch.

I am moving this issue to Needs Review (NR) for further verification. However, based on my testing and review, this patch appears to be ready for RTBC (Reviewed & Tested by the Community).

Thank you!

jaydev bhatt → made their first commit to this issue’s fork.

@skyejohnson no, the community can review it as well, so if you have the time please take a look.

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

Feedback appears to be addressed.

@bojan_dev does one of the official maintainers need to approve MR164? This is an issue I've just stumbled across in my own situation. Thanks for working on it.

I tried this out but the new setting was not saving on the display form. I made a small change to the MR. Here is a patch for composer.

I committed the type suggestions.

@remco hoeneveld: But your patch works for you? That’s at least good to know. I also updated the MR with the latest changes from HEAD.
Still needs test coverage.

#89 works with 3.0 but use previous fix based on "Any".
MR add the adjustmentType which should be kept for 3.0

Merged in the latest from origin.

I didn't follow the recommended test plan. I created a unit test instead. Let me know if that isn't acceptable.

Going deeper into this, it makes sense that the expired status also means that there was no response to the confirmation request. But according to the getStatus() method documentation, expired status is returned regardless of any other condition:

  [ ... ]
   * - expired: the confirmation age is over the allowed maximum, regardless
   *   of any other status
   *
   * Note that an expired confirmation could be confirmed as well. Check
   * the confirmed status with the isConfirmed method.
  [ ... ]

Therefore, the patch introduces changes to the API and may break any existing implementation using this method.

Postponed for the 2.x branch.

Gitlab is showing as mergeable

Small comments on the MR.

Thank you for starting with test coverage, guarantees this will probably get done faster

If you are another contributor eager to jump in, please allow the previous poster at least 48 hours to respond to feedback first, so they have the opportunity to finish what they started!

But we should also support denormalizer implementing DenormalizerInterface and adding denormalize method, so we can create order item with adjustment from jsonapi.

  /**
   * {@inheritdoc}
   */
  public function denormalize($data, $type, $format = NULL, array $context = []) {
    if (isset($context['field_type']) && 'commerce_adjustment' === $context['field_type']) {
      if (isset($data['amount'], $data['amount']['number'], $data['amount']['currency_code'])) {
        $data['amount'] = new Price($data['amount']['number'], $data['amount']['currency_code']);
      }
      return new Adjustment($data);
    }

    return $data;
  }

Patches should be in MR (didn't check for test coverage)

Issue summary needs to be updated as well please.

If we get 🐛 User can't reference unpublished content even when they have access to it Needs work in core, I don't think this issue will be necessary anymore either.

Amazing work, got nothing left to say.

#89 works great on Commerce 3.0

I agree that the ability to distinguish between published and unpublished content is out of scope for this and should be handled in a follow up. This issue has gone on long enough, adding that requirement will delay it further.

Turns out the bug I encountered was actually in facets so I'm hiding my patch.

I added some tests.

I can't reproduce anymore on Drupal 11.1.3, I think this was fixed by 📌 Entity operations for menu links are hardcoded in edit menu form Fixed .

Re-roll of #27 because it did not apply for me with Search API 1.35