Issue with doTrustedCallback() must be callable, array given

Can you put a debugger in the calling code and check what the array is?

@sardiwal if you turn on 'verbose with backtrace' at config -> development -> logging you may get some more info

A callable is considered an array if the callable passed can't be executed.

So inside the function, can you add something like this

if (is_array($callback)) {
  drupal_set_message(var_export($callback, TRUE));
}

And report back, that should output the callback it is trying to execute but can't (because it can't find the functions etc)

We have been running into a similar issue that only affects some environments. In our case we have been generated theme based on Olivero with https://github.com/mherchel/olivero-subtheme

And the issue sounds a bit like what you (@larowlan) noted in https://www.drupal.org/project/drupal/issues/3111409#comment-13842264 concerning autoloading.

I was experiencing this error too, I think it might be related to the "gin" theme.

I have added the following to my settings.local.php :

$class_loader->addPsr4('Drupal\\gin\\', 'themes/contrib/gin/src');

I suspect the culprit might be the class GinPrePrender.php, but I am not sure, I am not able to see who is responsible (PHP-7 cuts the error_log with "..." so I can not really tell which #pre_render is doing it.)

Anyway, maybe this can help others.
Any feedback is welcome.

same error with 9.4.5 when creating a new theme based on stable9
```
name: My
type: theme
description: 'base stable9.'
core_version_requirement: ^8 || ^9
libraries:
# - tkla/global-styling
base theme: stable9
regions:
header: 'Header'
content: 'Content'
sidebar_first: 'Sidebar first'
footer: 'Footer'

```

same error in drupal 10.0 when try create a subtheme Olivero, i use the provided script to copy the theme of

https://github.com/mherchel/olivero-subtheme

with this instruccions too

https://github.com/mherchel/olivero-subtheme/issues/1#issuecomment-12753...

I was also getting this same error after following the subtheme Olivero instructions.

https://github.com/mherchel/olivero-subtheme

What happened was I was renaming everything to olivero_company. Even though I told PHPStorm to use case sensitive when performing the find/replace, it still performed the action twice on class OliveroPreRender implements TrustedCallbackInterface {} making it class Olivero_company_companyPreRender implements TrustedCallbackInterface {}.

It might be worth checking the above class declaration in the src/OliveroPreRender.php file. Remember, this may be named differently depending on your theme name.

To find the find the problem code, edit core/lib/Drupal/Core/Render/Renderer.php and add the debug code to the end of the function doCallback() immediately before return $this->doTrustedCallback().

For example, if you're using devel/kint:

  kint($callback);

If the error is resulting in a WSOD then the last one displayed will tell you where the problem lies.

In my case, I forgot to make one of the callbacks a static function.

I get this error just after I upgrade from D9 to D10.0.5

TypeError: Drupal\Core\Render\Renderer::doTrustedCallback(): Argument #1 ($callback) must be of type callable, array given, called in /srv/www/htdocs/ssl2/www/web/core/lib/Drupal/Core/Render/Renderer.php on line 788 in Drupal\Core\Render\Renderer->doTrustedCallback() (line 51 of core/lib/Drupal/Core/Security/DoTrustedCallbackTrait.php).

I wrote none of the code.

I also cannot update the database:
drush updb
[preflight] Mapping values are not allowed in multi-line blocks at line 2 (near "<?php").

You may also need a use statement in your module file.

e.g. my_module.module:

use Drupal\my_module\MyModuleCallback;

/*
 * Implements hook_block_view_alter().
 */
function my_module_block_view_alter(array &$build, BlockPluginInterface $block) {
  if ($build['#plugin_id'] === 'block_my_block') {
    $build['#pre_render'][] = [MyModuleCallback::class, 'preRender'];
  }
}

There are quite a few issues which all result in the same error message.

I get the same Error as the #21, it seems to have something to do with the "Claro" Theme and the { [0]=> string(33) "Drupal\Core\Render\Element\Hidden" [1]=> string(15) "preRenderHidden" } component.

After this component is loaded, the error occurs.

The same instance with the Stark 10.0.9 theme works as expected.

If anyone could look into this it would be highly appreciated, my server setup:

Linux CentOS
PHP8.1 & PHP 8.2 both failed
MariaDB 10.5.19

I had the same problem cloning Olivero. There was a mismatch in the naming of the PreRender class. Sounds like you may have run into the same problem cloning Claro.

https://github.com/mherchel/olivero-subtheme/issues/1#issuecomment-16052...

I have the same issue.

I used the Stark theme for both Admin and Website and it still gave me this error:

===============
TypeError: Drupal\Core\Render\Renderer::doTrustedCallback(): Argument #1 ($callback) must be of type callable, array given, called in /var/www/vhosts/thejdngroup.com/domains/test10.portrevolt.com/core/lib/Drupal/Core/Render/Renderer.php on line 788 in Drupal\Core\Render\Renderer->doTrustedCallback() (line 57 of core/lib/Drupal/Core/Security/DoTrustedCallbackTrait.php).
===============

Hope someone can resolve this soon ...

Hi folks

For everyone posting here, it would be really great if you could dig into this a bit more and provide an example of the array being passed that Drupal can't execute.

As mentioned above it sounds like an issue with autoloading, so could be related to how we register theme namespaces in the autoloader.

Lee

I posted some debug code for this issue here: https://www.drupal.org/forum/support/upgrading-drupal/2023-05-30/migrati...

Have those who have this problem used composer to install the site and are there any issues with the vendor directory?

drush cr -y fixed the ...TypeError: Argument 1 passed to Drupal\Core\Render\Renderer::doTrustedCallback() must be callable, array given... issue for me.

When I upgrade from 9.5.1 to Drupal 10.1 I am getting the same error only in my AWS hosting and not in my local site

"[Mon, 09/11/2023 - 12:04] [Error] [php] [client: 10.80.35.171, Anonymous] TypeError: Drupal\Core\Render\Renderer::doTrustedCallback(): Argument #1 ($callback) must be of type callable, array given, called in /opt/drupal/web/web/core/lib/Drupal/Core/Render/Renderer.php on line 788 in Drupal\Core\Render\Renderer->doTrustedCallback() (line 57 of /opt/drupal/web/web/core/lib/Drupal/Core/Security/DoTrustedCallbackTrait.php)."

I have enabled the default olivero theme but still its giving the same issue.
Someone please suggest solution if you have anything.

drush cr -y fixed the issue for "Drupal\Core\Render\Renderer::doTrustedCallback()"

After install recommended project with composer I have the same error upgrading from 9.5 to 10.1.3 PHP 8.1.12. Patch 3224723-10 failed.
I am stuck now and will not migrate the productive system to 10.

The patches in #10 & #11 probably won't work.

I posted a link to things you can do in #27.

It'd be great if someone who's experiencing this issue would spend a little time trying to find out what's in the callback.

Had the same error after updating to Drupal 9.5.11 but also updating Gin theme.
When I applied patch from #11, then the error changed into:
Render #pre_render callbacks must be methods of a class that implements \Drupal\Core\Security\TrustedCallbackInterface or be an anonymous function. The callback was Toolbar::localTasks. See https://www.drupal.org/node/2966725
I am now investigating the gin_toolbar module as possible culprit.

I needed to get a website that was offline due to this error back online asap.
The fastest method was putting these lines in comment in web/modules/contrib/gin_toolbar/gin_toolbar.module:

    [
      Toolbar::class,
      'localTasks',
    ]

That fixed it for admin pages.
I was still getting error on my frontend theme. After a lot of digging, that was caused by using a token in a view.
More specifically, I have a Geolocation CommonMap view where I set the Marker icon path like this:
/themes/custom/basetheme/img/marker--{{field_showroom_type}}.png
Before updating, that showed different markers on the map based on the value of field_showroom_type.
After updating, that resulted in the error from this issue for some reason. Still figuring that out.

In another project where I had this same error after updating, I needed to replace the following code in a custom module:
$rendered_teaser = \Drupal::service('renderer')->render($teaser);
with:
$rendered_teaser = \Drupal::service('renderer')->renderRoot($teaser);
and that fixed the error for that project... For a day.. The next day I had to revert these changes because the site wouldn't work for anonymous users (drupal LogicException: A stray renderRoot() invocation is causing bubbling of attached assets to break) but strangely the site kept on working after reverting. So suddenly a day later the same code that breaked the site a day before no longer breaks the site. Might have been a (Redis) cache fluke or something.

This just happened to me updating a site from Drupal 9.5 to Drupal 10. The site uses the Claro theme for both front and back end. Drush not working and only getting the WSOD. From #27 above I did the second part of this comment and was able to get a bootstrap. Then clearing the cache fixed the issue.

https://www.drupal.org/forum/support/upgrading-drupal/2023-05-30/migrati...

I ran into this as well while updating to Drupal 9.5.

I was able to debug this by adding this before the call to \Drupal\Core\Security\DoTrustedCallbackTrait::doTrustedCallback and inspecting what is the value of $callback when it's not a callable:

if (!is_callable($callback)) {
  xdebug_break();
}

For some reason it was caused by Gin Toolbar having a pre_render calling ::localTasks on an undefined class; Toolbar. I removed Gin Toolbar from the code base and installed composer dependencies again and for some reason it fixed the problem. It also looks like the code was different even though the version of the module remained same 🤔 I tried to check the history for that module but didn't find any clues to why this was happening.

The reason why others are running into this is probably something else since the problem I ran into seems quite arbitrary. I hope the steps for debugging this at least helps.

I had the same error that was only on the production environment. I ran drush cr and it fixed it.

I had the same error after upgrading from 9.5.11 to 10.1.7, only on my staging environment (Platform.sh). Like for chefigueroa, a simple drush cr fixed it for me. Hope that helps.

The hints in #19 helped me, almost.
Before the Olivero subtheme was finally displayed as desired not only under Drupal 9, but also under Drupal 10, only one thing was missing.

Let's say the copied Olivero subtheme is called "coco".

In /themes/custom/coco/src/, OliveroPreRender.php then becomes CocoPreRender.php (even if the theme itself actually starts with a lowercase letter, the file name of this file must start with an uppercase letter).

As described in #19, the file still contains the following in line 12...
class OliveroPreRender implements TrustedCallbackInterface {
...then...
class CocoPreRender implements TrustedCallbackInterface {
.

And now back up to line 3, where it becomes (and I haven't read this anywhere else)...
namespace Drupal\olivero;
...then...
namespace Drupal\coco;

Now into the file coco.theme:
Line 8
use Drupal\coco\CocoPreRender;
Line 550
$info['text_format']['#pre_render'][] = [CocoPreRender::class,
line 555
$info['status_messages']['#pre_render'][] = [CocoPreRender::class,

I created the original working version of my Olivero subthemes for Drupal 8+9 with the help of
https://github.com/mherchel/olivero-subtheme
. I had to make the additional changes described above so that it also runs under Drupal 10.

I ran into this but it was only happening on the live site (Pantheon, but I don't think that matters). If I cleared the cache, some of the domains worked but not others. If I cleared the cache again, then a different set of domains started working. I attempted to deploy the attached patch to get more info. But simply the act of deploying seemed to kick it into gear and it started working for all domains.

Not to belabor the point, but #8, #26, & #27 all have ways you can help debug what's actually going on. Please take out a few minutes to do one of those.

(Sorry, wrong issue.)

This still a support request and should it be moved to NW?