#Needs issue summary update

PHPUnit annotations are now attributes -- IS needs an update for this.

> Use @group Drupal to allow filtered testing.
> Use @group Namespace or similar for further filtering. e.g: @group Entity

What is the point of this? If all the Drupal core tests are in core/tests, then you pass that as a parameter to PHPUnit instead of a @group.
If all the tests for core/lib/Core/Foo are in core/tests/Foo, then you pass that.

Given how much people are complaining about writing docblocks for test methods in 📌 [policy] Remove the requirement for doxygen for test methods Needs work , why are we adding superfluous @group tags?

This came up as daily BSI target.

Since it's kinda already been triaged I'm going to move to PMNMI because no one else seems to be reporting it since 2017 is this still an issue in D11?

Updates that are listed under "Not compatible" on admin/reports/updates/update should not cause the status report to have a "Module and theme update status" "Out of date" warning so long as there is still a supported version installed.

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!

Rerolled the patch for 11.2 beta

I will focus on some 2.0.x issues, but this seems good to go.

See comment #59 🐛 Allow views attachment display to use its own pager options Needs work , posted two years ago.

This deprecation is now triggering fails in another MR that adds a views upgrade path https://git.drupalcode.org/issue/drupal-3095893/-/jobs/5480383

I think this can be closed now.

I'm not really sure how to determine who should get credit on a meta issue so if someone else could do that that'd be great :)

avpaderno → changed the visibility of the branch 2614198-select-formatting-overrides-CKEditor to hidden.

Came up as a daily BSI target

#1 ConfigurableLanguageManagerTest does still seem to be scare
#2 there is LanguageNegotiatorPluginTest now wonder if that covers it
#3 Quick search didn't find any test
#4 Which are missing?

Definitely still seems to be relevant

My commit fixes an issue in the unit test, but highlights another issue; what is the expected value of target_bundles in the 'node_reference no content types' test? My understanding is that it should be NULL, therefore we need to reinstate $target_bundles = empty($target_bundles) ? NULL : $target_bundles; while retaining the preceding else condition.

@wim leers if you can dredge this from your memory then I would appreciate your opinion, thanks.

(no longer needs reroll)

Created a patch based on https://www.drupal.org/project/inline_entity_form/issues/2822764#comment... ✨ Support adding new entities when translating Needs review and combined with the Called to undefined method getEntity when using in Layout Builder as mentioned in https://www.drupal.org/project/inline_entity_form/issues/2822764#comment... ✨ Support adding new entities when translating Needs review

When using nested content blocks and Complex widget in Layout builder, the following error occurs:
Error: Call to undefined method Drupal\layout_builder\Form\UpdateBlockForm::getEntity() in Drupal\inline_entity_form\Plugin\Field\FieldWidget\InlineEntityFormComplex->extractFormValues() (line 731 of /data/sites/web/xxxxx/web/modules/contrib/inline_entity_form/src/Plugin/Field/FieldWidget/InlineEntityFormComplex.php).

There is no getEntity-method for the layout builder form which triggers an error here:

$main_entity = $form_state->getFormObject()->getEntity();

Fixed bug in migrate process plugin.

(no longer needs reroll)

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

Just a diff patch against --branch 10.4.x to address this and other warnings, prior to new release

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!

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!

Thank you! The changes have been committed.

Fix in 3193939-the-content-language branch.

The issue summary should be updated: It is not clear to me what when it's on tab would mean.

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!

#71 worked correctly for us https://www.drupal.org/project/drupal/issues/2833734#comment-15844466 🐛 Allow views attachment display to use its own pager options Needs work

Existing patches are for seven and stable themes, is this still an issue with claro?

The steps to reproduce the issue should be made clearer.

✅ Patch tested and verified on Drupal 10.4.7

This patch applies cleanly and resolves the issue where an attachment display in a View cannot render pager values when inheriting from the parent display.

🔍 Steps to reproduce and test:

Created a View with a paged display (e.g., page display with a pager).

Added an attachment display that references the paged display.

Enabled the Render pager option in the attachment display.

🔧 Result:

With the patch applied, the attachment correctly renders pager values when configured to inherit and render them.

Without the patch, the attachment display does not show pager output, even if render pager is enabled.

🧪 No regressions observed. Views behavior remains stable, and the patch only touches Attachment.php.

📦 Patch is based on an updated fork where the original patch was implemented but not applying cleanly. Reformatted to Drupal standards using a/ and b/ paths.

✅ Marking as Needs Review — patch applies cleanly, fixes the issue, and is safe to test.

Following up if anyone can update IS with steps, if no follow up could close out in 3 months.

This came up as a daily BSI target

First we need to check if still an issue in D11.

If so then lets update the issue summary with the standard template and go from there.

I think this issue duplicates the issue you referenced.

Are these duplicates?

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

Since there's been no follow up in 3 months going to close out. But don't worry! Can always be re-opened

Thanks all!