Warning: Undefined array key 1 in Drupal\Core\Asset\AssetResolver of core\lib\Drupal\Core\Asset\AssetResolver.php

The patch resolved the issue. I don't see any warning for this.

We need those steps to reproduce.

Hi Cilefen,

This happened for me on Drupal 9.5.10 version and I am using PHP 8.1 and Database Version 10.4.25-MariaDB. My site was running with 9.5.9 and I started getting this warning after upgrading to 9.5.10 (Upgraded through composer).

Leaving steps to reproduce as the actual steps are not provided.

Also issue summary is incomplete.

No test case either.

The cause of this is an incorrectly formatted library name, likely in YOURTHEME.libraries.yml. Look for a library that does not follow this format: "MODULE_NAME/LIBRARY_NAME" (the forward slash is crucial). If you are able to step debug you could also add a breakpoint within \Drupal\Core\Asset\LibraryDependencyResolver::doGetDependencies (currently line 67). Refresh the page that triggers the error and continue debugging until you find that $library does not follow the correct format. Search your codebase for the incorrect format and replace it if it is in a custom module or theme. If it is in a contrib module, open an issue there.

Perhaps the goal of this ticket could be to have core throw a useful error message when this happens?

Can someone help me know how to make this patch application persist?
I added these lines under /patches in composer.json, but the changes keep getting overwritten as I make changes in composer and update:

 "drupal/core": {
                "3329660 - Assetresolver":
                    "https://www.drupal.org/files/issues/2022-12-26/3329660-2.patch"
            },

In our case, this happens when the library does not exist on Drupal because was removed.

Example of our case:

A search Ajax callback with a library that was removed:
https://example.com/search?ajax_page_state[theme]=radix&ajax_page_state[theme_token]=&ajax_page_state[libraries]=addtoany/addtoany.front&f[0]=type:article
When the library does not exist or is not a valid name, then it gives a warning.
Should be it fixed? Maybe not or maybe it should log which library is not available to leave to the admin decide what to do.

Also covered the core/lib/Drupal/Core/Asset/LibraryDependencyResolver.php class, and continue if the extension or the name are not defined.

Added also array filter on HtmlResponseAttachmentsProcessor to avoid setting already loaded libraries when the array is empty.

[0 = ""]

#10 MR7016 reroll for D10.3.

I have a similar warning with drupal 11.0.9 for every page visited. It must have appeared after one of the latest core updates.
The site with drupal 10.3.10 has the same pages and settings, but there is no warning.
I don't know how to fix it.

Thank you

Warning: Undefined array key 1 in Drupal\Core\Asset\AssetResolver->getJsAssets() (line 243 of /home/hmcpdbiy/prova.gmpe.it/core/lib/Drupal/Core/Asset/AssetResolver.php)

#0 /home/hmcpdbiy/prova.gmpe.it/core/includes/bootstrap.inc(108): _drupal_error_handler_real(2, 'Undefined array...', '/home/hmcpdbiy/...', 243)
#1 /home/hmcpdbiy/prova.gmpe.it/core/lib/Drupal/Core/Asset/AssetResolver.php(243): _drupal_error_handler(2, 'Undefined array...', '/home/hmcpdbiy/...', 243)
#2 /home/hmcpdbiy/prova.gmpe.it/core/lib/Drupal/Core/Render/HtmlResponseAttachmentsProcessor.php(286): Drupal\Core\Asset\AssetResolver->getJsAssets(Object(Drupal\Core\Asset\AttachedAssets), true, Object(Drupal\Core\Language\Language))
#3 /home/hmcpdbiy/prova.gmpe.it/core/lib/Drupal/Core/Render/HtmlResponseAttachmentsProcessor.php(123): Drupal\Core\Render\HtmlResponseAttachmentsProcessor->processAssetLibraries(Object(Drupal\Core\Asset\AttachedAssets), Array)
#4 /home/hmcpdbiy/prova.gmpe.it/core/modules/big_pipe/src/Render/BigPipeResponseAttachmentsProcessor.php(97): Drupal\Core\Render\HtmlResponseAttachmentsProcessor->processAttachments(Object(Drupal\Core\Render\HtmlResponse))
#5 /home/hmcpdbiy/prova.gmpe.it/core/lib/Drupal/Core/EventSubscriber/HtmlResponseSubscriber.php(45): Drupal\big_pipe\Render\BigPipeResponseAttachmentsProcessor->processAttachments(Object(Drupal\Core\Render\HtmlResponse))
#6 /home/hmcpdbiy/prova.gmpe.it/vendor/symfony/event-dispatcher/EventDispatcher.php(246): Drupal\Core\EventSubscriber\HtmlResponseSubscriber->onRespond(Object(Symfony\Component\HttpKernel\Event\ResponseEvent), 'kernel.response', Object(Symfony\Component\EventDispatcher\EventDispatcher))
#7 /home/hmcpdbiy/prova.gmpe.it/vendor/symfony/event-dispatcher/EventDispatcher.php(206): Symfony\Component\EventDispatcher\EventDispatcher::Symfony\Component\EventDispatcher\{closure}(Object(Symfony\Component\HttpKernel\Event\ResponseEvent), 'kernel.response', Object(Symfony\Component\EventDispatcher\EventDispatcher))
#8 /home/hmcpdbiy/prova.gmpe.it/vendor/symfony/event-dispatcher/EventDispatcher.php(56): Symfony\Component\EventDispatcher\EventDispatcher->callListeners(Array, 'kernel.response', Object(Symfony\Component\HttpKernel\Event\ResponseEvent))
#9 /home/hmcpdbiy/prova.gmpe.it/vendor/symfony/http-kernel/HttpKernel.php(216): Symfony\Component\EventDispatcher\EventDispatcher->dispatch(Object(Symfony\Component\HttpKernel\Event\ResponseEvent), 'kernel.response')
#10 /home/hmcpdbiy/prova.gmpe.it/vendor/symfony/http-kernel/HttpKernel.php(204): Symfony\Component\HttpKernel\HttpKernel->filterResponse(Object(Drupal\Core\Render\HtmlResponse), Object(Symfony\Component\HttpFoundation\Request), 1)
#11 /home/hmcpdbiy/prova.gmpe.it/vendor/symfony/http-kernel/HttpKernel.php(76): Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object(Symfony\Component\HttpFoundation\Request), 1)
#12 /home/hmcpdbiy/prova.gmpe.it/core/lib/Drupal/Core/StackMiddleware/Session.php(53): Symfony\Component\HttpKernel\HttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#13 /home/hmcpdbiy/prova.gmpe.it/core/lib/Drupal/Core/StackMiddleware/KernelPreHandle.php(48): Drupal\Core\StackMiddleware\Session->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#14 /home/hmcpdbiy/prova.gmpe.it/core/lib/Drupal/Core/StackMiddleware/ContentLength.php(28): Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#15 /home/hmcpdbiy/prova.gmpe.it/core/modules/big_pipe/src/StackMiddleware/ContentLength.php(32): Drupal\Core\StackMiddleware\ContentLength->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#16 /home/hmcpdbiy/prova.gmpe.it/core/modules/page_cache/src/StackMiddleware/PageCache.php(106): Drupal\big_pipe\StackMiddleware\ContentLength->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#17 /home/hmcpdbiy/prova.gmpe.it/core/modules/page_cache/src/StackMiddleware/PageCache.php(85): Drupal\page_cache\StackMiddleware\PageCache->pass(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#18 /home/hmcpdbiy/prova.gmpe.it/core/lib/Drupal/Core/StackMiddleware/ReverseProxyMiddleware.php(48): Drupal\page_cache\StackMiddleware\PageCache->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#19 /home/hmcpdbiy/prova.gmpe.it/core/lib/Drupal/Core/StackMiddleware/NegotiationMiddleware.php(51): Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#20 /home/hmcpdbiy/prova.gmpe.it/core/lib/Drupal/Core/StackMiddleware/AjaxPageState.php(36): Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#21 /home/hmcpdbiy/prova.gmpe.it/core/lib/Drupal/Core/StackMiddleware/StackedHttpKernel.php(51): Drupal\Core\StackMiddleware\AjaxPageState->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#22 /home/hmcpdbiy/prova.gmpe.it/core/lib/Drupal/Core/DrupalKernel.php(709): Drupal\Core\StackMiddleware\StackedHttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#23 /home/hmcpdbiy/prova.gmpe.it/index.php(19): Drupal\Core\DrupalKernel->handle(Object(Symfony\Component\HttpFoundation\Request))
#24 {main}

There's an MR here that needs work, changing status.

#13 reroll for D10.4

I installed version 11.1.0., but the problem persists.

I had this error on each page after upgrading to D10.4.1.
Patch #16 fixed it.
But if the source of the problem is that there is code or a theme trying to load an unexisting library, shouldn't we log a clear error instead ?
something like Module responsive_image is trying to load a library that does not exist: 'responsive_image/ajax'

@flyke yes we should add validation for the library name, maybe via an assert() so it impacts developers rather than live sites, but could also log on top of that.

Is it possible to fix this for Drupal 11 too?
I can't publish my site with a warning every 10 seconds.

@giordy: I am currently using patch from #16 in D11.1.1

I tried applying patch #16 on Drupal 11.1.1 but the problem is not solved.

#13 reroll for D11.1

Ok #13 solves in D11.1.1.

We ran into an attack that with about 3610 of these in the logs in one day.

Updated the issue summary with the following from our logs:

Warning: Undefined array key 1 in Drupal\Core\Asset\LibraryDependencyResolver->doGetDependencies() (line 67 of core/lib/Drupal/Core/Asset/LibraryDependencyResolver.php) #0 core/includes/bootstrap.inc(166): _drupal_error_handler_real()
#1 core/lib/Drupal/Core/Asset/LibraryDependencyResolver.php(67): _drupal_error_handler()
#2 core/lib/Drupal/Core/Asset/LibraryDependencyResolver.php(41): Drupal\Core\Asset\LibraryDependencyResolver->doGetDependencies()
#3 core/lib/Drupal/Core/Asset/AssetResolver.php(117): Drupal\Core\Asset\LibraryDependencyResolver->getLibrariesWithDependencies()
#4 core/lib/Drupal/Core/Asset/AssetResolver.php(175): Drupal\Core\Asset\AssetResolver->getLibrariesToLoad()
#5 core/lib/Drupal/Core/Ajax/AjaxResponseAttachmentsProcessor.php(149): Drupal\Core\Asset\AssetResolver->getCssAssets()
#6 core/lib/Drupal/Core/Ajax/AjaxResponseAttachmentsProcessor.php(117): Drupal\Core\Ajax\AjaxResponseAttachmentsProcessor->buildAttachmentsCommands()
#7 core/lib/Drupal/Core/EventSubscriber/AjaxResponseSubscriber.php(66): Drupal\Core\Ajax\AjaxResponseAttachmentsProcessor->processAttachments()
#8 [internal function]: Drupal\Core\EventSubscriber\AjaxResponseSubscriber->onResponse()
#9 core/lib/Drupal/Component/EventDispatcher/ContainerAwareEventDispatcher.php(111): call_user_func()
#10 symfony/http-kernel/HttpKernel.php(214): Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher->dispatch()
#11 symfony/http-kernel/HttpKernel.php(202): Symfony\Component\HttpKernel\HttpKernel->filterResponse()
#12 symfony/http-kernel/HttpKernel.php(76): Symfony\Component\HttpKernel\HttpKernel->handleRaw()
#13 core/lib/Drupal/Core/StackMiddleware/Session.php(53): Symfony\Component\HttpKernel\HttpKernel->handle()
#14 core/lib/Drupal/Core/StackMiddleware/KernelPreHandle.php(48): Drupal\Core\StackMiddleware\Session->handle()
#15 core/lib/Drupal/Core/StackMiddleware/ContentLength.php(28): Drupal\Core\StackMiddleware\KernelPreHandle->handle()
#16 core/modules/page_cache/src/StackMiddleware/PageCache.php(116): Drupal\Core\StackMiddleware\ContentLength->handle()
#17 core/modules/page_cache/src/StackMiddleware/PageCache.php(90): Drupal\page_cache\StackMiddleware\PageCache->pass()
#18 core/lib/Drupal/Core/StackMiddleware/ReverseProxyMiddleware.php(48): Drupal\page_cache\StackMiddleware\PageCache->handle()
#19 core/lib/Drupal/Core/StackMiddleware/NegotiationMiddleware.php(51): Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle()
#20 core/lib/Drupal/Core/StackMiddleware/AjaxPageState.php(36): Drupal\Core\StackMiddleware\NegotiationMiddleware->handle()
#21 core/lib/Drupal/Core/StackMiddleware/StackedHttpKernel.php(51): Drupal\Core\StackMiddleware\AjaxPageState->handle()
#22 core/lib/Drupal/Core/DrupalKernel.php(741): Drupal\Core\StackMiddleware\StackedHttpKernel->handle()
#23 index.php(19): Drupal\Core\DrupalKernel->handle()
#24 {main}.

When reproducing this locally the steps were minimally

With a Views page with "Use AJAX" enabled:

Bare minimum query parameters:
https://example.org/views/ajax?ajax_page_state[libraries]=ajax&view_name=example_view

Instead of suppressing the warning, we could throw a RuntimeException, triggering a 4xx client error when this occurs. This would clearly indicate that the request was invalid, rather than failing silently, making it obvious that unexpected input was provided.

A decision is needed on whether to handle this gracefully or enforce stricter validation with an explicit exception. Tagging this with “Needs architectural review” in the hopes that it will get some attention.

Created a separate MR 11113 to leave the other approach until a review happens on which direction to take, then it can go back to needs work.

@joelpittet see #19. I think we should assert() here, because we know that there are modules using invalid library names on production sites already and rather than a PHP warning this would cause their CSS or JS aggregates to actually be broken.

I don't have a strong view on whether we should also log an error for site owners, maybe not because the assert() should eventually filter through the relevant fixes to sites.

edit: crossposted with the MR which I haven't looked at yet.

Could the summary be cleaned up some. Proposed solution doesn't seem clear to me.

Also probably need simple test coverage.

@catch Thanks for the review! That makes sense, and I’m glad I asked. For me, I get emails about PHP warnings but not Client Errors, which is why I initially proposed that approach. I also saw it used elsewhere in the code for similar cases. My main goal is to reduce noise while ensuring the issue isn’t hidden—similar to “permission denied” warnings, which appear but generally aren’t a concern for site owners unless they’re actively investigating something.

@smustgrave If we go with @catch’s approach using assert(), wouldn’t that already serve as a sufficient test? Or are you suggesting we should also verify that the asserts are in place? aka asserting the asserts 🫣

Yeah I'd completely agreed with BadRequestException if we weren't already aware of modules doing this in the wild, we could maybe open a 12.x follow-up to switch to that from the assert()?

Why were the changes not included in version 11.1.2? I had to re-apply the patch #13.

@giordy because the patch you're using isn't suitable to commit to Drupal core, it only hides the error, and because apart from @joelpittet no one has yet created an MR to actually move the issue forward.

See https://www.drupal.org/community/contributor-guide/reference-information... →