🇪🇸Spain @pcambra

Thanks all!

Taking a look a this, we can easily fall into entities that do not have canonical URLs

Drupal\Core\Entity\Exception\UndefinedLinkTemplateException: Cannot generate default URL because no link template 'canonical' or 'edit-form' was found for the 'paragraph' entity type in Drupal\Core\Entity\EntityBase->toUrl() (line 211 of core/lib/Drupal/Core/Entity/EntityBase.php). 

I think it is ok to pass id, entity_type and bundle, but we should remove URL and leave that for 📌 Implement Token Replacements Active

I can confirm this bug on 8.x-1.12 on user/{id}/security/tfa/tfa_trusted_browser

Drupal\Component\Plugin\Exception\PluginNotFoundException: The "tfa_trusted_browser" plugin does not exist. Valid plugin IDs for Drupal\tfa\TfaValidationPluginManager are: tfa_hotp, tfa_recovery_code, tfa_totp in Drupal\tfa\TfaValidationPluginManager->doGetDefinition() (line 53 of core/lib/Drupal/Component/Plugin/Discovery/DiscoveryTrait.php). 

I'm seeing that the other plugins have unit tests for them but tfa_trusted_browser seems to be missing.

1. tfa_hotp: TfaHotpTest.php
2. tfa_recovery_code: TfaRecoveryCodeTest.php
3. tfa_totp: TfaTotpTest.php

I've created the MR from the available branch and I can confirm it fixes or at least works around the issue.

I'm seeing why this is being an issue for some, drush cr did not have bootstrap none on top until https://github.com/drush-ops/drush/pull/6243

So basically this is not an issue for those running drush >13.4.rc1 https://github.com/drush-ops/drush/releases/tag/13.4.0-rc1

Leaving in NR in case we want to be super duper sure and include the workaround

Something like this should do

Seems that webform beta is using Drupal\Core\Hook\Attribute\Hook but that's not in D10 is it? https://www.drupal.org/node/3442349 →

I'm seeing the same thing on 10.5

function webform_ui_entity_type_alter(array &$entity_types) {
  \Drupal::service(WebformUiHooks::class)->entityTypeAlter($entity_types);
}

It's a classic catch 22 issue and you won't probably be able to reproduce it unless you do an upgrade from say beta2 to beta4

The service doesn't exist and then you can't clear the cache because it complains about it, clearing the cache would solve the issue.

  You have requested a non-existent service "Drupal\webform_ui\Hook\WebformUiHooks".  

We could also contribute back to the aos main library so they have a dist version minified and zipped like chosen does: https://github.com/noli42/chosen/blob/main/.github/workflows/release.yml

We should copy chosen strategy:

https://git.drupalcode.org/project/chosen/-/tree/5.0.x?ref_type=heads#in...

pcambra → created an issue.

We would need tests and a MR, thanks :)

Could we have a little test for this?

@rcodina, did you include the fixes in the other issue or should we add an independent MR on this one? Thanks

NW as per #6 and #7

Could we get a MR for this instead?

Thanks!

Ah this was already fixed :)

pcambra → created an issue.

Thanks pasqualle!

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

This works for me:

    mode:
      type: string
      title: Mode
      enum:
        - default
        - figure

Not sure if we need to do something on this module?

Thanks for reporting, this is a particular setup of composer.json and depends on your whether you need only stable, beta, dev... on your projects

I think this is a dupe

seantwalsh → credited pcambra → .

I've faced a somehow related issue with Floursish oEmbeds, not in terms of aspect ratio but in terms of the maxwidth/maxheight not overriding the default height and weight, for example:

https://app.flourish.studio/api/v1/oembed?url=https://public.flourish.st...

Should display a width of 960px but it shows the default 700px as it is forced by the weight attribute in the returned JSON file.

Adding a solution like #27 for the type_rich would be my suggestion to solve this.

Thanks @larowlan, could we backport this to 10.x too?

pcambra → created an issue.

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

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.