Hello and thanks for this legendary module,

Problem/Motivation

After updating to 3.6.0, I've started receiving the error message below:

Warning: Trying to access array offset on null in admin_toolbar_toolbar_alter() (line 39 of modules/contrib/admin_toolbar/admin_toolbar.module)

See detail below.

How can I solve it?

Best,

Orkut

Steps to reproduce

Proposed resolution

Solution: The key is to run database update as everybody is confirming or, only in case of need, just save the form /admin/config/user-interface/admin-toolbar.

See also Deploying a Drupal update for the most basic steps, and the correct order.

Remaining tasks

User interface changes

API changes

Data model changes

Detailed error:

admin_toolbar_toolbar_alter() (Line: 552)
Drupal\Core\Extension\ModuleHandler->alter() (Line: 80)
Drupal\toolbar\Element\Toolbar::preRenderToolbar()
call_user_func_array() (Line: 113)
Drupal\Core\Render\Renderer->doTrustedCallback() (Line: 875)
Drupal\Core\Render\Renderer->doCallback() (Line: 432)
Drupal\Core\Render\Renderer->doRender() (Line: 504)
Drupal\Core\Render\Renderer->doRender() (Line: 248)
Drupal\Core\Render\Renderer->render() (Line: 484)
Drupal\Core\Template\TwigExtension->escapeFilter() (Line: 87)
__TwigTemplate_1d3037525f04008f4f83ea633e439ee8->doDisplay() (Line: 388)
Twig\Template->yield() (Line: 344)
Twig\Template->display() (Line: 359)
Twig\Template->render() (Line: 51)
Twig\TemplateWrapper->render() (Line: 33)
twig_render_template() (Line: 348)
Drupal\Core\Theme\ThemeManager->render() (Line: 491)
Drupal\Core\Render\Renderer->doRender() (Line: 248)
Drupal\Core\Render\Renderer->render() (Line: 158)
Drupal\Core\Render\MainContent\HtmlRenderer->Drupal\Core\Render\MainContent\{closure}() (Line: 638)
Drupal\Core\Render\Renderer->executeInRenderContext() (Line: 153)
Drupal\Core\Render\MainContent\HtmlRenderer->renderResponse() (Line: 90)
Drupal\Core\EventSubscriber\MainContentViewSubscriber->onViewRenderArray()
call_user_func() (Line: 111)
Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher->dispatch() (Line: 186)
Symfony\Component\HttpKernel\HttpKernel->handleRaw() (Line: 76)
Symfony\Component\HttpKernel\HttpKernel->handle() (Line: 53)
Drupal\Core\StackMiddleware\Session->handle() (Line: 48)
Drupal\Core\StackMiddleware\KernelPreHandle->handle() (Line: 28)
Drupal\Core\StackMiddleware\ContentLength->handle() (Line: 32)
Drupal\big_pipe\StackMiddleware\ContentLength->handle() (Line: 116)
Drupal\page_cache\StackMiddleware\PageCache->pass() (Line: 90)
Drupal\page_cache\StackMiddleware\PageCache->handle() (Line: 48)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle() (Line: 51)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle() (Line: 36)
Drupal\Core\StackMiddleware\AjaxPageState->handle() (Line: 51)
Drupal\Core\StackMiddleware\StackedHttpKernel->handle() (Line: 741)
Drupal\Core\DrupalKernel->handle() (Line: 19)
CommentFileSizeAuthor
#12 admin_toolbar-array-offset-on-null-3525987-12.patch718 bytesyseki

Comments

orkut murat yılmaz created an issue. See original summary.

orkutmuratyilmaz’s picture

orkutmuratyilmaz
Primary language Turkish
Location İzmir
commented
Status: Active » Closed (works as designed)

Sorry, I forgot doing "drush updb" after the update.

star-szr’s picture

star-szr
he/him
Primary language English
commented

I'm not so sure, I'm seeing this warning on a clean install.

star-szr’s picture

star-szr
he/him
Primary language English
commented

Hmm looks like the config schema has changed, so "hoverintent_functionality" was in admin_toolbar_tools.settings and now moved to admin_toolbar.settings.

pgrandeg’s picture

pgrandeg commented

Same here, appearing in a clean D11 installation. Configuration object admin_toolbar.settings is not well created after installing the module for any reason. After going to /admin/config/user-interface/admin-toolbar and saving without changes, the object exists and the error disappear

newaytech’s picture

newaytech commented

same error here after module upgrade and full cache clear.

need to save on config pages as per prior post.

pgrandeg’s picture

pgrandeg commented
Status: Closed (works as designed) » Active
alexgreyhead’s picture

alexgreyhead commented

Just to explicitly write out the fix:

Go to /admin/config/user-interface/admin-toolbar
Click "Save"
Done :-)

newaytech’s picture

newaytech commented

I just need to do that now across multiple test and production sites... is there a way to script this perhaps with drush?

alexgreyhead’s picture

alexgreyhead commented

I mean, in fairness, if display errors is turned off in production, it shouldn't be a major issue :-)

I have 15 or so affected sites but it's only causing me an eyesore on my local dev environments where displaying of errors is on.

(You can turn off error displaying at /admin/config/development/logging ¯\_(ツ)_/¯ )

A

newaytech’s picture

newaytech commented

I guess so - will knock 'em down as I come across them then...

yseki’s picture

yseki commented
StatusFileSize
new admin_toolbar-array-offset-on-null-3525987-12.patch718 bytes

Here is a patch.

alex.skrypnyk’s picture

alex.skrypnyk
he/him
Primary language English
Location Melbourne
commented

This appeared on all sites after auto-update and fails automated tests by producing an error.

Can this fix please be released as a patch version

yoon thadar yee’s picture

yoon thadar yee commented

To resolve the problem, I navigated to:
/admin/config/user-interface/admin-toolbar
Clicked "Save" without changing any settings.
This action refreshed the configuration and resolved the issue.
Fix complete. 👍

dydave’s picture

dydave commented

I don't understand .....

Site administrators are not running database updates after updating their sites anymore?

It has always been very standard to run DB updates after a site upgrade, whatever is being updated, whether core or contrib...

Running DB updates should update the necessary configuration values, see:
https://git.drupalcode.org/project/admin_toolbar/-/blob/3.x/admin_toolba...

which should prevent this type of errors from occurring.

alex.skrypnyk’s picture

alex.skrypnyk
he/him
Primary language English
Location Melbourne
commented

@dydave
I can confirm that the database update has been applied successfully.

However, if there’s a previous configuration exported - it reverts what this update does. As a result, for any sites that automatically update their dependencies, a manual configuration export is now required. This is a huge maintenance burden to now go through each website to re-export config.

Even more - if sites have updb + cim running (drush deploy), they will always end up with reverted changes. People would not even realise that there was a change as their config will not be overwritten.

I would provide an additional post deploy hook to mitigate this.

But this this specific case - can we please just fix the condition and release a patch

dydave’s picture

dydave commented

I mean .... if it's like that Alex (@alex.skrypnyk) we are never going to be able to make any changes to configuration objects in general 😅

We have to be able to update configurations in our projects, otherwise we don't do anything anymore 😅

I'm not a big fan of getting this patch applied as it adds "unnecessary" code in my sense....

dydave’s picture

dydave commented

The way we usually do this in our projects:

Update the code base locally:
composer update -W (for example with a global update)
Update the configuration:
drush cr
drush updb
Export the configuration changes:
drush cex
Commit/push the configuration changes:
git add xxxx
git commit
git push

This is always the standard procedure that we follow for any core or contrib upgrade and ensures any module is properly updated with its configuration inline before it gets imported.
(drush deploy, for example)

alex.skrypnyk’s picture

alex.skrypnyk
he/him
Primary language English
Location Melbourne
commented

drush deploy does it in bulk. so it will revert the changes that the update did. the user would not even know that there was a config change. a post deploy hook would help with this: it will run after all operations and will change the config in the DB. this config will then be shown as overridden and a developer can then run drush cex.

I don't know who does it like you described these days:

drush updb
STOP TO Export the configuration changes
drush cex

So not only there is now an error being thrown in UI and blocking automated tests in consumer site's CI, but also this now requires to break out of the established deployment process to manually re-export config.

This looks like a breaking change to me and should be accommodated in code to support both old and new version at least until the next minor version of the module.

alexgreyhead’s picture

alexgreyhead commented

Hey, don’t look at me; I found this via composer update working on my local dev :-P

Never would have known there was a problem if I’d pushed straight to prod following my “we’ll test it in production; what could possibly go wrong?” mantra :-D

dydave’s picture

dydave commented

I mean ... Alex (@alex.skrypnyk), this doesn't seem related with Admin Toolbar specifically, but rather with the way site administrators maintain and deploy their configuration on their sites.

This seems like a very generic problem, which is most likely the case with all other contrib modules and core 😅

As far as the module is concerned, we "should" be able to consider everything was done in a very standard way and we've provided a valid method to prevent the error described in this ticket from occurring.

thomwilhelm’s picture

thomwilhelm commented

Sorry for maybe asking a dumb question. But if you don't export config locally, how can you do a major upgrade from say Drupal 10.3 to 10.4? As when you run drush deploy, all the config changes performed by drush updb will be lost.

This workflow seems pretty standard and is referenced in point 8 on Drupal's own guide here: https://www.drupal.org/docs/updating-drupal/updating-drupal-core-via-com...

If you are using config management to deploy your config, make sure to export the config with drush config:export after the database update because some core updates may change the structure of the config files or introduce new values to them. Add the option --diff to view actual changes.

So I'd say a lot of developers would be following this. Maybe it's different if you are managing 100's of site.

dydave’s picture

dydave commented

Thanks a lot Thom (@thomwilhelm)!

Looks like we have the same understanding of the complaints brought up in this issue:

this doesn't seem related with Admin Toolbar specifically, but rather with the way site administrators maintain and deploy their configuration on their sites.

ressa’s picture

ressa
he/him
commented

See also Deploying a Drupal update where I attempted to document the most basic steps, and the correct order.

vishal.kadam’s picture

vishal.kadam
Location Mumbai
commented

I also received this warning when updating the module to version 3.6.0, but it was resolved after running the database update.

pgrandeg’s picture

pgrandeg commented
Status: Active » Closed (works as designed)

I enabled it today on fresh installation for d10, d11 and dcms and it is working. I don't know why it failed to me on fresh installation yesterday, but it is working good.

So the key is to run database update as everybody is confirming or, only in case of need, just save the form /admin/config/user-interface/admin-toolbar.

Please allow me to mark the ticket as closed as designed, since the discussion about configuration objects are not actually related with admin_toolbar.

ressa’s picture

ressa
he/him
commented
Issue summary: View changes

Thanks, sounds good. I have added the solution in the Issue Summary under "Proposed resolution", so that users in need of help get a solution faster. Feel free to improve it or add more details :)

ressa’s picture

ressa
he/him
commented
Issue summary: View changes
jannakha’s picture

jannakha commented
Issue summary: View changes

this is not an issue:
- run updb after update
- export config

jannakha’s picture

jannakha commented
Issue summary: View changes
ricardochefigueroa’s picture

ricardochefigueroa commented

#8 fixed my issue. Thanks.

orkutmuratyilmaz’s picture

orkutmuratyilmaz
Primary language Turkish
Location İzmir
commented

@ressa, thanks for the improvement:)

attheshow’s picture

attheshow commented

#8 Was the correct approach for us. (Running database updates after updating the code wasn't enough to resolve the issue.) Thanks! 😊🏅

dydave’s picture

dydave commented

@alex.skrypnyk: Sorry again for the additional work and noise on the updates.

A fix was committed in the DEV branch in issue #3527315-8: in admin_toolbar_toolbar_alter(), Trying to access array offset on value of type null and should be released in a patch version hopefully soon, after a few other "urgent" issues have been addressed (as many as possible).

We will try to be more careful with these types of error cases in the future.
Sorry again for the inconvenience and thanks in advance for your understanding. 🙏