Warning: Trying to access array offset on null in admin_toolbar_toolbar_alter()

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

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

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

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

same error here after module upgrade and full cache clear.

need to save on config pages as per prior post.

Just to explicitly write out the fix:

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

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

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

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

Here is a patch.

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

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. 👍

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.

@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.

I mean .... if it's like that Alex (@alexgreyhead) 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....

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)

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

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

I mean ... Alex, 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.

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.

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.

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

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

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.

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 :)

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

#8 fixed my issue. Thanks.

@ressa, thanks for the improvement:)

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

@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. 🙏