🇪🇸Spain @enchufe

A colleague solved it with the Migrate Files (extended) → module.
Should the issue be closed or is it still a bug in this module?

Adds a validation of the existence of the variable on the line that indicates the warning.

enchufe → created an issue.

@florianmuellerCH To manage Cookies I use the JavaScript library orestbida/cookieconsent. The GA4 beacon is loaded with the attributes type=text/plain data-category=analytics. And the rest is configured by the library by activating the script (removing type=text/plain) when consenting to Cookies.
This gave me quite a headache, I hope it helps!

Patch #4 🐛 Could not check compatibility between Drupal\disable_route_normalizer\DisableRouteNormalizer\DisableRouteNormalizer and Drupal\redirect\EventSubscriber\RouteNormalizerRequestSubscriber Needs review works fine.

+1 It is not specified on the main page of the module that it requires a paid subscription. It looks more like a proprietary promotion in open source.

#6 🐛 Error: Call to a member function getType() on bool in filefield_paths_filefield_paths_process_file() Needs work
Currently I have the migration development paused, when I resume it I will test the patch.

#8 🐛 Error: Call to a member function getType() on bool in filefield_paths_filefield_paths_process_file() Needs work
But, if $temporary_scheme_name is always NULL, wouldn't the "if" logic always be skipped?

If attributes are added in TWIG as raw, they are not displayed in the final HTML, and the async attribute is displayed as async="true".

Source: drupal/ga4_google_analytics:dev-1.1.x

Removed the "required" property from the new field in the configuration form.

enchufe → created an issue.

enchufe → created an issue.

enchufe → created an issue.

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

None of these fixes are related to the Tome Add Paths → module, but to its parent Tome → module.
Please report this issue to the Tome Drupal.org issue queue → .

Rerolled patch #9 for version 2.x, passes the Google Lighthouse test.

As an alternative, I have created the submodule Tome Add Paths → .

Added to the event subscribers a specific one for the sitemap.

Added the limit in the form with the machine name bundle max lenght limit core constant. Also added a security check that programmatically limits machine name in case it exceeds the maximum allowed length.

The patch unnecessarily limits the machine name of the entity bundle, causing it to have a lower limit than normal.

enchufe → created an issue.

Thank you for your contribution!

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

Works well for me

enchufe → created an issue.

In the end, I have considered that a better implementation of the removal of the "Menu settings" block is to add the #access => FALSE property, which also avoids this reported error, although its implementation can be considered to protect the system from failures.

In my particular case a customer has requested it. I thought that maybe someone else could use it and it does not affect the flow of the current code.

The PHP function array_filter() always expects to receive an array, in case $form_state->getValue('menu_options') is NULL, it passes as fallback parameter an empty array to avoid the error.

enchufe → created an issue.

enchufe → created an issue.

#7 I added the URL alias filter to the main content view with the views_url_alias → module. Which is officially supported by Drupal 10.

As a workaround I've created a patch to make the AudioFieldPluginBase and WavesurferAudioPlayer classes support both DrupalCoreFileUrlGenerator and DrupalCoreFileUrlGenerator. And, as this patch fixes a problem that only affects in a specific scenario, I have added the CDN module as a dependency.

Patch works fine for me.

Automated patch works fine for me.

Implements hook_help().

enchufe → created an issue.

enchufe → created an issue.

I had the same problem and solved it by rerolling patch #2 of the issue https://www.drupal.org/project/commerce_paypal/issues/3145157 → .
As stated in the issue, this doesn't fix the problem but it works as a workaround.

PHP 8.2 and Drupal 9.5.x. Added tags and cache contexts to the block, tested with two blocks on views on different pages, and two blocks on views on the same page.

enchufe → created an issue.

enchufe → created an issue.

Following recent changes, the MR as plain diff no longer functions as a patch. I include a backrroll to the previous changes as a patch.

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

Works fine for me

So, the current MR is slightly safer by first checking if the variable is defined and not null before applying PHP functions. In my specific case it works correctly.

Wouldn't it be more efficient to use $condition['operator'] ?? '' instead of !empty($condition['operator']) ? $condition['operator'] : ''? The empty function and the ternary operator are two steps, while the null merge operator (??) is a native PHP operator.

Looks good, the MR works for me

#3 Your patch seems to be more secure by adding additional checks for variables. Do I manually add it to my MR or is there a way to merge the patch? I'm relatively new to contributing code to Drupal.

enchufe → created an issue.

Issue solved in branch 9.5.x, replaced code with

substr(PHP_OS, 0, 3) != 'WIN'