@apparatchik

I just bumped into this issue, for me, it happens regardless of wether the recipient is set or not.

I'm running version 3.0.3, and the stack trace is the following:

TypeError: implode(): Argument #2 ($array) must be of type ?array, string given in implode() (line 260 of /opt/drupal/web/modules/contrib/easy_email/src/Form/EasyEmailTypeForm.php).

#0 /opt/drupal/web/modules/contrib/easy_email/src/Form/EasyEmailTypeForm.php(260): implode(', ', '[easy_email:fie...')
#1 /opt/drupal/web/core/lib/Drupal/Core/Entity/EntityForm.php(107): Drupal\easy_email\Form\EasyEmailTypeForm->form(Array, Object(Drupal\Core\Form\FormState))
#2 [internal function]: Drupal\Core\Entity\EntityForm->buildForm(Array, Object(Drupal\Core\Form\FormState))
#3 /opt/drupal/web/core/lib/Drupal/Core/Form/FormBuilder.php(536): call_user_func_array(Array, Array)
#4 /opt/drupal/web/core/lib/Drupal/Core/Form/FormBuilder.php(375): Drupal\Core\Form\FormBuilder->retrieveForm('easy_email_type...', Object(Drupal\Core\Form\FormState))
#5 /opt/drupal/web/core/lib/Drupal/Core/Form/FormBuilder.php(633): Drupal\Core\Form\FormBuilder->rebuildForm('easy_email_type...', Object(Drupal\Core\Form\FormState), Array)
#6 /opt/drupal/web/core/lib/Drupal/Core/Form/FormBuilder.php(326): Drupal\Core\Form\FormBuilder->processForm('easy_email_type...', Array, Object(Drupal\Core\Form\FormState))
#7 /opt/drupal/web/core/lib/Drupal/Core/Controller/FormController.php(73): Drupal\Core\Form\FormBuilder->buildForm(Object(Drupal\easy_email\Form\EasyEmailTypeForm), Object(Drupal\Core\Form\FormState))
#8 [internal function]: Drupal\Core\Controller\FormController->getContentResult(Object(Symfony\Component\HttpFoundation\Request), Object(Drupal\Core\Routing\RouteMatch))
#9 /opt/drupal/web/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(123): call_user_func_array(Array, Array)
#10 /opt/drupal/web/core/lib/Drupal/Core/Render/Renderer.php(638): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}()
#11 /opt/drupal/web/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(121): Drupal\Core\Render\Renderer->executeInRenderContext(Object(Drupal\Core\Render\RenderContext), Object(Closure))
#12 /opt/drupal/web/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(97): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array)
#13 /opt/drupal/vendor/symfony/http-kernel/HttpKernel.php(181): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}()
#14 /opt/drupal/vendor/symfony/http-kernel/HttpKernel.php(76): Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object(Symfony\Component\HttpFoundation\Request), 1)
#15 /opt/drupal/web/core/lib/Drupal/Core/StackMiddleware/Session.php(53): Symfony\Component\HttpKernel\HttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#16 /opt/drupal/web/core/lib/Drupal/Core/StackMiddleware/KernelPreHandle.php(48): Drupal\Core\StackMiddleware\Session->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#17 /opt/drupal/web/core/lib/Drupal/Core/StackMiddleware/ContentLength.php(28): Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#18 /opt/drupal/web/core/modules/big_pipe/src/StackMiddleware/ContentLength.php(32): Drupal\Core\StackMiddleware\ContentLength->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#19 /opt/drupal/web/core/modules/page_cache/src/StackMiddleware/PageCache.php(106): Drupal\big_pipe\StackMiddleware\ContentLength->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#20 /opt/drupal/web/core/modules/page_cache/src/StackMiddleware/PageCache.php(85): Drupal\page_cache\StackMiddleware\PageCache->pass(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#21 /opt/drupal/web/core/lib/Drupal/Core/StackMiddleware/ReverseProxyMiddleware.php(48): Drupal\page_cache\StackMiddleware\PageCache->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#22 /opt/drupal/web/core/lib/Drupal/Core/StackMiddleware/NegotiationMiddleware.php(51): Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#23 /opt/drupal/web/core/lib/Drupal/Core/StackMiddleware/AjaxPageState.php(36): Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#24 /opt/drupal/web/core/lib/Drupal/Core/StackMiddleware/StackedHttpKernel.php(51): Drupal\Core\StackMiddleware\AjaxPageState->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#25 /opt/drupal/web/core/lib/Drupal/Core/DrupalKernel.php(741): Drupal\Core\StackMiddleware\StackedHttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#26 /opt/drupal/web/index.php(19): Drupal\Core\DrupalKernel->handle(Object(Symfony\Component\HttpFoundation\Request))
#27 {main}

I have been bumping into this issue from time to time, and then I come here to grab the latest patch for the current Drupal version.

I also think some simpler patches / fixes shouldn't need to take 8 years and 4 major Drupal versions to get applied, regardless if there are specific tests developed.

I also can't get to it to show up on Drupal 10.3.6.

Thank you at #111 for testing this, I can confirm patch #45 works for the time being, dpm and kint are essential to our dev process.

Thank you to everyone involved in the successive patches, I can confirm I was able to have notifications working again in my Drupal web app, though not with some work.

A few tips for other people struggling with this:

- After you apply the #38 patch to the latest 3.0.1 version, don't forget to run drush updb or update.php to get all the changes to the module's configuration in the db.

- The credentials json is found not on the firebase console like usual but on the google cloud console, search for "google service account credentials json"

- This might be obvious, but don't forget to import the needed classes at the top of your file:

use Drupal\firebase\Entity\Message;
use Drupal\firebase\Entity\MessageData;
use Drupal\firebase\Entity\Notification;
use Drupal\firebase\Entity\AndroidConfig;
use Drupal\firebase\Entity\ApnsConfig;

- This is the code that I'm using at the moment:

public static function firebase_message($token, $title, $body, $data)
    {
        $service = Drupal::service('firebase.message');
        $service->setRecipients($token);
        
        $notification = new Notification($title);
        $notification->setBody($body);
        
        $data = MessageData::fromArray($data);
          
        // Message
         $message = new Message($notification);
         $message->setData($data);
         $service->setMessage($message);
         // Android config
         $android_config = new AndroidConfig();
         $android_config->setPriority('high');
         $message->setAndroidConfig($android_config);
         // Apple config
         $apns_config = new ApnsConfig();
         $apns_config->setHeaders(['apns-priority' => '5']);
         $apns_config->setPayload(['aps'=> ['mutable-content' => 1, 'content-available' => 1]]);
         $message->setApnsConfig($apns_config);
        
          $result = $service->sendToTokens();
    }

Regards.

After trying everything for the better part of a day, I faced the simple fact that mymodule_theme_suggestions_alter and mymodule_theme were never going to work due to the active theme taking precedence / priority over whatever template your module suggests or defines. At least in my use case.

My specific problem: I needed to override a template defined by the theme, and I wanted to do that from my module, it didn't make sense to make a sub theme and add an unnecessary extension, versioning and overhead just to override one line of a twig in a theme.

Specifically, I wanted the site's logo on the menu toolbar to not point to <front> but to a custom url. That was it. Simple, right? Well, that functionality is not baked in, at least not in the theme I'm using and on most themes. I could have done it in a hackish, non-Drupal way, in 5 minutes with javascript. Anyways, this is what worked for me in Drupal 10.3:

/**
 * Implements hook_theme_registry_alter().
*/
function mymodule_theme_registry_alter(&$theme_registry) {
  if(isset($theme_registry['menu__toolbar__gin'])){
    $theme_registry['menu__toolbar__gin']['path'] = \Drupal::service('extension.list.module')->getPath('mymodule').'/templates';
  }
}

I found out that checking the theme_registry using Devel was of great help to just change the part that needed to be overwritten for my use case, I didn't want to redefine the whole array entry (hook), just the path.

After further testing, I found out there was an unrelated hook saving the submission before the route loaded the webform, thus triggering the update operations I was getting. My Bad.

apparatchik → created an issue.

Just a stopgap patch to avoid RuntimeException while $required_derivative_scheme can be fully implemented.

I'm now getting the following exception:

RuntimeException: Controller "Drupal\az_blob_fs\Controller\AzBlobFsImageStyleDownloadController::deliver" requires that you provide a value for the "$required_derivative_scheme" argument. Either the argument is nullable and no null value has been provided, no default value has been provided or there is a non-optional argument after this one. in Symfony\Component\HttpKernel\Controller\ArgumentResolver->getArguments() (line 110 of /opt/drupal/vendor/symfony/http-kernel/Controller/ArgumentResolver.php).

I imagine there are places where AzBlobFsImageStyleDownloadController::deliver gets called without providing the $required_derivative_scheme.

I'm not familiar enough with the module and the changes introduced by 10.3 but will try to give this a go when I get a bit of free time.

I just bumped into this issue when upgrading to 10.3, thank you for the patch.

I think here are two unrelated problems: the OP appears to be having issues loading jQuery (probably a JS general problem), which might be helped by changing $ for jQuery as in the proposed patch.

I, however, have bumped into the issue of the flags not loading, etc. with an error in the setCountry function within mobile-number-form-element.js.

It turns out that sometimes, on first load, the setCountry function gets called with a null value before setting itself correctly to the chosen default value. In those cases, the script breaks and the flags never load, etc.

I will be posting a patch here later today, but wanted to leave a heads up, the quick workaround is to check if the value is null and return the function in other to prevent the errors from breaking the functionality.

as in:

function setCountry(country) {
          if(!country){
            return;
          }

          $input.parents('.country-select').find('.mobile-number-flag').removeClass($input.data('value'));
          $input.parents('.country-select').find('.mobile-number-flag').addClass(country.toLowerCase());
          $input.data('value', country.toLowerCase());

          var options = $input.get(0).options;
          for (var i = 0; i < options.length; i++) {
            if (options[i].value === country) {
              var prefix = options[i].label.match(/(\d+)/)[0];
              $input.parents('.country-select').find('.prefix').text('(+' + prefix + ')');
            }
          }
        }
      

I applied the proposed patch and got the following:

 TypeError: count(): Argument #1 ($value) must be of type Countable|array, string given in count() (line 98 of /home/mmex/public_html/web/modules/contrib/metatag/src/Entity/Me  
  tatagDefaults.php).    

I changed line 98 to check if $tag is of type array:

if (is_array($tag) && count($tag) === 1) {
            return reset($tag);
        } 

I don't know how to create a MR.

In a modern project you would want to have composer.json under version control so others could composer install it, Drupal 10's recommended composer project is still missing a useful gitignore.

The patch works great for the BLT config-import scenario described above: installing from configuration without all the limitations, caveats and inconsistencies of a profile's config install scenario (read: no core.extension support). In our case, we wrote a BLT Task Hook to run on new sites install only, thus, when deploying updates we avoid existing sites configuration from being overwritten by the drush cex/cim cycle.