🇪🇸Spain @pcambra

I don't think we should be depending on commerce_product, as this uses https://www.drupal.org/project/commerce_purchasable_entity →

We could also check for $domElement->hasChildren

I only use the filter so there might be other places where the library can be added (the template file?)

pcambra → created an issue.

pcambra → created an issue.

I think branch 2.1 should drop D9 support or maybe a 2.2 for this?

pcambra → created an issue.

I can reproduce this issue, I needed to add https://login.microsoftonline.com as allow requests from.

This is exactly what #3 describe, it´s a route collision, let´s see if this MR helps and we can get this module slowly back on track.

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

I've merged this but there's probably still more work needed, at least the info.yml upgrade so help is welcome

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

Commimted, thanks!!

This is probably OK and merged it to get the warning away but we should handle what happens if key repository is actually null then.

For those doing this now, you can use chx/drupal-issue-fork

composer require chx/drupal-issue-fork
composer drupal-issue-fork https://git.drupalcode.org/issue/commerce_migrate-3506938/-/tree/3506938-support-commerce-3.0
composer require 'drupal/commerce_migrate:dev-3506938-support-commerce-3.0'

pcambra → created an issue.

Adding a patch file with the rebase above for 4.0.0

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

I think decorating your resource fetcher is the way to go, see https://git.drupalcode.org/project/oembed_configuration/-/blob/1.0.x/src...

Thanks!

@mon_franco brought sweets and I brought stuff from the Spanish Drupal camp :)

• https://www.drupal.org/project/add_to_calendar →
• https://www.drupal.org/project/like →
• https://www.drupal.org/project/form_display_visibility →

I can add more if needed :)

I use it on the process, any advantage to do it in the variable directly?

+1

Ah I saw the related issue now

Wondering what changed to produce this error, do we have a change record?

Thanks!

Could you please add a Merge request instead of a patch?

I can confirm this behaviour, adding the related issue that will fix this on D11

I've included the bits from this one on 🐛 State required asterisk doesn't show Needs work as it conflicts directly and introduces very similar changes, I think we could mark this one as duplicated and give credit on the other one to everyone involved.

MR updated to include the parts from 🐛 When an autocomplete entity reference is required via #states, no required marker is added Active , credit should go to @penyaskito, @edmoreta and @leoenriquezp I think.

Also attaching a #2912092 + #3342118 patch for composer workflows for 10.5.2

This solved the issue for me in 10.5.2, here's a patch for composer workflows.

We're not doing this.

Just chiming in to point to https://www.drupal.org/project/extra_field → and https://www.drupal.org/project/extra_field_plus → which might be useful in this context? happy to open a branch and give access if it's of any kind of use

https://www.drupal.org/project/content/issues/3397460 📌 Like "We stand with Ukraine", we should stand with the innocent people of Palestine Active

Seems harmless :) thanks!

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

🎉 thanks

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.