Warning 'helpers could not be defined' when clearing caches via admin UI [#3568817]

Problem/Motivation

After Kint 2.3.0+ installation (with configurable helpers from https://git.drupalcode.org/project/kint/-/merge_requests/12/diffs) each time caches are cleared from the admin UI, the following warning is shown:

This warning appears even though the helper functions (`d()` and `s()`) are working correctly and were successfully registered.

Steps to reproduce

- Install and enable Kint (2.3.0 or later)
- Clear all caches either from admin toolbar or from /admin/config/development/performance
- Refresh page and you will see the warning message displayed on the page

Proposed resolution

If not mistaken, HelperManager tries to re-register helper functions after cache clear. As functions already exists from initial bootstrap, \DomainException is thrown.

Proposed fix is to check if the function is already registered in Kint::$aliases before throwing the \DomainException

Patch

See attached patch file.

Comment	File	Size	Author
	kint-helper-registration-warning-fix.patch	611 bytes	mitrpaka

Comments

Comment #1

21 January 2026 at 14:58

mitrpaka created an issue. See original summary.

Comment #2

mitrpaka commented 21 January 2026 at 15:00

Issue summary:	View changes
Status:	Active	» Needs review

Comment #3

jnvsor commented 21 January 2026 at 17:54

Good idea, but since Kint::$aliases isn't keyed by helper name I'll add a static property to hold the info. I was able to reproduce this in update.php before but thought it wasn't worth fixing, but now I can't reproduce it at all and I'm very confused.

Anyway, manually reconstructed it to trigger the error and confirm it's fixed. Can you try the wip-test branch and confirm it's fixed for you?

Comment #4

mitrpaka commented 23 January 2026 at 11:53

@jnvsor Thank you for the quick reply and updated fix-proposal. I can confirm the wip-test branch resolves the issue.

> I was able to reproduce this in update.php before but thought it wasn't worth fixing, but now I can't reproduce it at all and I'm very confused.

Also tried this on vanilla Drupal installation and was not able to reproduce it either. Then I did backtrace this to figure out why HelperManager is constructed second time and in our case culprit was hook_entity_load() implementation in our custom code.

Happens also when new module is enabled from admin UI (/admin/modules).