Account created on 19 September 2017, about 7 years ago
#

Merge Requests

Recent comments

🇪🇸Spain miguelarber

I confirm this issue exists, as I needed to map a value when one field was empty (NULL), but doing so causes a YAML parse error (as described in the ticket).

🇪🇸Spain miguelarber

Hi again, I'm updating my latest patch as I detected a small typo in the $form['include_null'] item of the NumericArgument views argument. Attached there is the updated patch #19 and the interdiff with #12 and #17.

🇪🇸Spain miguelarber

The patch in #12 is working for me too, thank you.

However, there seems to be a situation where the 'include_null' form element is not accessible to the user via the UI (not visible), because its state is depending on the 'glossary' element. There might be use cases where the 'include_null' is required, regardless of the state of the glossary mode (i.e.: in the case of a NumericArgument).

I have attached a new patch fixing this situation: 3209940-17.patch

🇪🇸Spain miguelarber

I was going to provide a patch myself for this bug, but I came across this issue where #2 patch resolves it.

I confirm the bug is still present in the latest version of webform submission migration from D7, and it is caused because of applying the strtolower() function to the 'form_key' in the webform migration source plugin, but not in the webform submission source plugin (this difference makes the 'form_key' inconsistent).

When executed, the migration doesn't fail per-se (you can actually check that the submission data is present in the database), however the UI is not able to properly display the submissions for those items where the 'form_key' originally contained uppercase characters. The provided patch also applies the strtolower() to the 'form_key' in the webform submission source plugin and fixes the issue. Thank you.

🇪🇸Spain miguelarber

Attached to this comment is the patch for Drupal 10.1.x.

🇪🇸Spain miguelarber

The patch provided in #11 seems to be problematic as it throws the following error when importing the site's configuration:

TypeError: Drupal\layout_builder\Entity\LayoutBuilderEntityViewDisplayStorage::Drupal\layout_builder\Entity\{closure}(): Argument #1 ($section) must be of type Drupal\layout_builder\Section, array given in Drupal\layout_builder\Entity\LayoutBuilderEntityViewDisplayStorage->Drupal\layout_builder\Entity\{closure}() (line 24 of /app/web/core/modules/layout_builder/src/Entity/LayoutBuilderEntityViewDisplayStorage.php)

Based on the previous patch, I have performed some small adjustments that should do the trick and allow you bypass the mentioned issues.

🇪🇸Spain miguelarber

I am sorry for the delay, I just read the message posted by @Anybody, but I see that @dieterholvoet has already created an MR of the rebased #157. Please let me know if I can help on anything else.

PS: I'm glad to help, thanks for testing @Victornator.

🇪🇸Spain miguelarber

I attached an updated version of the patch that also manages the issues caused for the same reason on the 'evaluate' and 'getCacheMaxAge' methods of the Expiry class.

🇪🇸Spain miguelarber

Attached to this comment you will find a patch in the case you want to combine together these two awesome modules.

🇪🇸Spain miguelarber

In a very specific scenario, when a media entity has more than a single 'file' type field (i.e.: 'book' media entity, containing a 'file' field and a 'cover' field) this patch causes the editing form to not submit properly when adding/removing the second 'file' type field (the user has to click on the 'Save' button twice, so that the changes take place).

I have added some extra lines to make sure that the media library opener is actually the 'Field widget'. This avoids the annoying issue I described above. This patch is based on #148.

Production build 0.71.5 2024