🇪🇸Spain @pcambra

Thanks for the pointer, this makes sense.

pcambra → created an issue.

pcambra → created an issue.

pcambra → created an issue.

What's going on is that the tabs are picked from the latest translation revision from ERR so if you have a site in English and Spanish, whatever you save last, will win, adding a MR shortly.

I'm going to close this one with the changes suggested by the bot only, please add follow up issues if there are any other changes you'd like to make.

pcambra → created an issue.

Let's make this simpler and do just the icon, if someone wants the text, we can open another task.

You normally don't put your own patches as RTBC.

I've rebased this to be against 2.x

Thanks.

Please remove anything that is not D11 related and open separate issues for that.

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

Awesome, thanks!!

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

Awesome, thanks both!

Thanks all!

Example on how we could apply this:

on the .module file:

/**
 * Implements hook_field_info_alter().)
 */
function my_module_field_info_alter(&$info) {
  if (isset($info['block_field'])) {
    // Override the list class for the block_field field type to avoid comparing
    // plugin changes between revisions.
    // @see \Drupal\Core\Field\FieldItemList::hasAffectingChanges()
    // @see https://www.drupal.org/project/block_field/issues/3517759
    $info['block_field']['list_class'] = '\Drupal\my_module\BlockFieldItemList';
  }
}

The custom BlockFieldItemList class:

<?php

namespace Drupal\my_module;

use Drupal\Core\Field\FieldItemList;
use Drupal\Core\Field\FieldItemListInterface;

/**
 * Avoids block plugin fields to be compared between revisions.
 */
class BlockFieldItemList extends FieldItemList {

  /**
   * {@inheritdoc}
   */
  public function hasAffectingChanges(FieldItemListInterface $original_items, $langcode) {
    // If there are different items, then it is a change.
    if (count($this) != count($original_items)) {
      return TRUE;
    }

    foreach ($this as $delta => $item) {
      if ($item->getProperties()['plugin_id']->getValue() != $original_items[$delta]->getProperties()['plugin_id']->getValue()) {
        return TRUE;
      }
    }

    return FALSE;
  }

}

pcambra → created an issue.

pcambra → created an issue.

@macsim, oh dear, apologies for that, I didn't noticed that the default option didn't include you, should be fixed now!, thanks for letting me know!

I think this was included in 📌 Drush 13 compatibility Active , thanks!

Could you please confirm if this has been solved in branch 3.x?

Is this something that happens on 3.x branch as well?

Thanks all!!!

Let's merge this and fix whatever is missing afterwards, thanks all for the hard work on this one.

Well,. looking at the compatibility table in https://www.drush.org/13.x/install/#drupal-compatibility we cannot have a 3.x release that supports Drupal 10 and 11 AND Drush 11, so I'd be OK dropping it for 3.x

Should this be needs review?

I would suggest the 2.x branch is removed from the project page then, as it might be expected that users see a D11 version and they read only that.

Just changed the branch to be 3.x

Is this a duplicate of 📌 Support latest versions of drush for drush.services.yml Active ?

This has been/will be fixed by 📌 Support last delimiter to allow comma separated plus and Active and 🐛 str_replace(): Passing null to parameter #3 ($subject) of type array|string is deprecated in Drupal\Component\Utility\Xss::filter() RTBC , thanks

Merged into 2.x, thanks all!

1.x Branch is no longer supported

pcambra → created an issue.

Added langcode to the query and reference to the Drupal issue

I just found this issue myself, I think it doesn't really matter to group by uid, but we definitely need to group by language.

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

I think this is part of 📌 Automated Drupal 11 compatibility fixes for entity_reference_validators Needs review

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

🙌🏽

This has issues related to translation, please if you do more changes in here, make sure you test the multilingual text for "Likes"

This is derailing pretty fast, could you please double check the changes you're doing, @prem suthar?

This is looking good @sahana_n, we could add a link in the settings form help for the icon class pointing to FA so people can see what options are available maybe?

I think the MR needs to be against 3.x branch?

Hi,
What I mean is that we can leverage the class names from FA and allow to add any class, i.e.
https://fontawesome.com/v4/examples/

Well, there's that :) thanks Jim!

Thanks all!

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

Is this relevant for 2.x as well?

Branch 1.x is no longer supported

Could someone explain why we need this package in require-dev?

@duaelfr could you confirm that we want to merge and release this on 2.x and then have a different MR for 3.x where we remove it?

This is great, thanks for all the work and follow ups!

I think this issue is intended to leave open in case there's more stuff coming from the bot?

This is fair, maybe we should use the new OOP hook system instead? https://www.drupal.org/node/3442349 →

I'm not seeing where we use BubbleableMetadata on the Util file, mind providing more info?

Wow, many thanks for this @sahana _n, I've added some feedback to your changes.