🇪🇸Spain @pcambra

Careful with the approach above, as the patch is associated to the MR so it will change over time. See https://architecture.lullabot.com/adr/20220429-composer-patch-files/

Thanks!

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

A start is a start indeed, thanks!

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

Probably related to 🐛 JSON:API assumes entity reference field's main property must be the entity ID Active and https://www.drupal.org/node/3519887 →

I've tested this with a somehow large project I'm working on and after around 10 minutes or less I got:

Packages: 146
TUF metadata: 9.9M

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

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

pcambra → created an issue.

pcambra → created an issue.

Thanks!

Adding the WIP policy for core.

We don't need that level of flexibility

Well, I've just show you a use case for this. I suspect ✨ Support Memcached for local caching Active is also related to this.

We're implementing required changes such that this service remains fully controlled but still serves all the needs

It does not serve all needs, that's why I try to explain.

Then, there is no alter or decoration required.

I have it decorated with this patch in a real use case. If that's not proof I don't know what is.

You can do reflection, service providers/compiler passes, patching, forking... so you can get the service you need for your project, that's the point of using services... the control you claim is not really there and this should be more flexible, or at the minimum have the possibility of controlling the DSN you eventually connect to, Happy to find ways to work with you to get this more flexible but I need some openness on your side to do so.

Not reopening this because the patch from the MR works for me, but I hope you reconsider.

Attaching the patch as standalone here in case someone else finds it useful.

It doesn't:

  Unable to find the socket transport "rediss" - did you forget to enable it   
  when you configured PHP?   

Maybe a different approach would be a weighted plugglable system that would support any backend? so instead of doing a if redis else php files, we could have a plugin manager deciding which cache method to implement in order? maybe Redis and fallback on phpfiles as default but someone could prioritize memcached, couchbase, valkey or a custom calculation for elastic cache for example?

Awesome, thanks!

How can the dsn calculation be altered then? another protected method for it?

And that's precisely why the client method should be protected rather than private, so it can be decorated while the Redis module fixes the issue (which is 4+ years old IIRC).

As we've closed the issue upstream, this is now related to what we do with this in relation to ✨ Support TLS for Predis Needs review as it is the patch that enables the redis contrib module to separate host and scheme. Without including a scheme/host separation, the PR in this issue doesn't really fix anything, it does though in combination. So I'm unsure where we should solve the issue because symfony/cache is going to handle it in a different way anyways.

I've added a separated issue to handle this redis connection issue so the site doesn't break/WSOD due to crowdsec failing to connect to Redis. 📌 Fail gracefully when Redis not available Active
And ✨ Could Drupal\crowdsec\Client::cache be protected instead of private? Active allows for service decoration which can be handy to alter the dsn for special cases.

Well, for once it is a service, so it is always a good thing, I've added more info on 💬 ElasticCache Redis issue Active and I think the client should be fair game as it could have other use cases and we have no hooks/OOP ways to change the dsn dynamically, which I need to do right now.

pcambra → created an issue.

I'm not using D11 yet :( it'd be great if 1.2 would have support for D10

pcambra → created an issue.

✅

Probably relevant that the DA has recently endorsed the UN Open source principles:

1. Open by default: Making Open Source the standard approach for projects
2. Contribute back: Encouraging active participation in the Open Source ecosystem
3. Secure by design: Making security a priority in all software projects
4. Foster inclusive participation and community building: Enabling and facilitating diverse and inclusive contributions
5. Design for reusability: Designing projects to be interoperable across various platforms and ecosystems
6. Provide documentation: Providing thorough documentation for end-users, integrators and developers
7. RISE (recognize, incentivize, support and empower): Empowering individuals and communities to actively participate
8. Sustain and scale: Supporting the development of solutions that meet the evolving needs of the UN system and beyond

See https://www.drupal.org/association/blog/the-drupal-association-endorses-... →

From the endorsement

be resilient to a changing world and not controlled by a select few.

https://github.com/crowdsecurity/php-remediation-engine/issues/37

No no no guys! This change are broken the logic!!!

Please open a new issue calmly for the maintainers to review :)

Merged, thanks

Well there's no conflicts because there are no changes now.

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

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

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

Needs rebase

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

I think this is still happening on 2.x

Finally had time to look at this and I think it's fixed, adding it to 2.x and 3.x

Finally had time to look at this and I think it's fixed, adding it to 2.x and 3.x

pcambra → created an issue.

Done :)

Moving this to a 2.x branch! thanks Mike

pcambra → created an issue.

I understand what you're explaining. What's missing is an upgrade path as mentioned earlier.

I will add a 3.x branch for the DER changes :)

This is definitely missing a migration, we can't just do this.

I still see that this overlaps with ✨ Allow Like Entity to support multiple entity types Active , I feel we should be do one or the other but not both. I am not opposed of adding a dynamic ER dependency.
This probably justifies opening a 3.x branch, but we still need an upgrade path.

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;
  }

}