#Needs Review Queue Initiative

I have raised the PR against 11.x and have attached before/after screenshots to demonstrate the UI changes introduced by the patch.

Now that 📌 Deprecate/remove the ability to update a module from a URL and authorize.php Active and child issues are done, all this code is deprecated and will be removed in D12.

Now that 📌 Deprecate/remove the ability to update a module from a URL and authorize.php Active and child issues are done, this code is all deprecated and will be removed in D12.

#2702061-106: Unify & simplify render & theme system: component-based rendering (enables pattern library, style guides, interface previews, client-side re-rendering) → and downwards is relevant, but the most likely outcome would be that the number of different elements is reduced, and eventually #theme gets dropped in favour of #type component, but don't really see any reason that this couldn't all be worked on in parallel without explicit dependencies.

I added steps to create a view that triggers the error and is fixed with this patch.

This is probably a duplicate of ✨ Add default date formats without time Closed: duplicate but this has obviously had much more recent discussion. Perhaps someone could credit @dead_arm for the original issue I've just closed.

Yes, agree #142 is nicer and it also gels with some thinking I had in this experiment

It also means we might not have to add new classes for everything, we could possibly use the existing render element plugins but instantiate them.

I ran into this error, but replacing my site config with the default media library view fixed it.

I had changed the view display to use responsive grid.

But that display doesn't support row classes, relating to https://www.drupal.org/project/drupal/issues/2474491 →

I made a custom display that extends responsive grid to add custom classes back in, and it's working again.

Should this be moved to documentation I wonder.

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.

Rebased MR 12000

Super nice @elimw! Great job! 🥳

Looks like everything requested above is now in the MR, with the added Unit Test 👌

Let's see if reviewers and maintainers could take another look at this issue.
Thanks again for the great help and work @elimw!

Closing as a duplicate of ✨ Prevent inaccessible links from being displayed in LinkFormatter Needs work .

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.

Changed - @nicxvan

Applied the MR suggestion and rebased. Since the change is minor and there were no other suggestions, going to push this back to RTBC.

Did you mean to change the status to rtbc, because you said rtbc but did not change the status.

There is suggestion in the MR

MR updated with latest 11.x + some feedback for MR review.

Let's try again a review. thanks

nod_ → closed merge request !11971

Committed d381523 and pushed to 11.x. Thanks!

Hello,

Tested and verified on Drupal 11,
MR applied successfully,
Working as expected.
Please check attachments

RTBC+

After about 9 months there has been no response so state that this is still needed. Therefor, closing.

If there is work to do here, then either re-open the issue or open a new issue and reference this one. If the choice is to use this issue then add a comment change make sure to change the issue status to 'Active'.

You're welcome! And great catch, the order is much better now.

Thanks for the quick response 😊

Tested this locally and found the sorting in the listing a bit weird. I think it would be better to prefix the labels.
I won't do it myself so I can still RTBC.

PS: don't try to test on the MR tugboat because it doesn't trigger a new install.

Thanks for clearing that up @catch, and that's totally all right @quietone. As a side effect I realized what a useful feature the ddev snapshot command is, to quickly roll back changes. I also learned a bit or two about making a hook_update and running phpcs, so it turned out to be a gain after all. I am pasting the end result below, just in case someone else needs to do something similar in the future. Thanks for the Doc page link @penyaskito!

Unused hook_update code:

use Drupal\Core\Datetime\Entity\DateFormat;

/**
 * Add date-only date formats.
 *
 * @see https://www.drupal.org/project/drupal/issues/3498980
 */
function system_update_11202(): string {
  $message = NULL;
  $date_formats = [
    'long_date_only' => [
      'label' => t('Long date (date only)'),
      'pattern' => t('l, j F Y', [], ['context' => 'PHP date format']),
    ],
    'medium_date_only' => [
      'label' => t('medium date (date only)'),
      'pattern' => t('D, j M Y', [], ['context' => 'PHP date format']),
    ],
    'short_date_only' => [
      'label' => t('short date (date only)'),
      'pattern' => t('j M Y', [], ['context' => 'PHP date format']),
    ],
  ];
  foreach ($date_formats as $id => $date_format_info) {
    if (!DateFormat::load($id)) {
      $date_format = DateFormat::create([
        'id' => $id,
        'locked' => FALSE,
        'status' => TRUE,
        'pattern' => $date_format_info['pattern'],
        'label' => $date_format_info['label'],
      ]);
      $message .= "Date format " . $date_format_info['label'] . " was created.\n";
      $date_format->save();
    }
  }
  return $message;
}

Oh, really? Then 🚀 ship it. @pameeela said this already, but I was pretty sure this was one of the core gates.

That means we need to actually remove that upgrade from this MR and we're done.

We don't need upgrade tests if there's no upgrade. Removing tag.
@ressa For the sake of learning, see https://www.drupal.org/docs/drupal-apis/update-api/writing-automated-upd... →

Updated issue summary.
Only left: Revert