Description:
When running database updates or during early bootstrap phases, the Schema.org module throws a ContainerNotInitializedException. This occurs because the module attempts to access the module handler service before the container is fully initialized.
Steps to reproduce:
1. Install Schema.org module (version 1.0.0-alpha27)
2. Run `drush updb` or perform operations during early bootstrap
3. Observe the error: ContainerNotInitializedException
Current behavior:
The module throws an exception when trying to access \Drupal::moduleHandler() before the container is initialized.
Expected behavior:
The module should check for container and service availability before attempting to access the module handler.
Proposed solution:
Add container and service availability checks before accessing the module handler. Here's the suggested fix for schemadotorg.module:
php
// Before
\Drupal::moduleHandler()->loadAllIncludes('schemadotorg.inc');
// After
if (\Drupal::hasContainer() && \Drupal::hasService('module_handler')) {
\Drupal::moduleHandler()->loadAllIncludes('schemadotorg.inc');
}
This change ensures the module gracefully handles early bootstrap phases while maintaining its functionality.
Thanks for developing this excellent module!
Active
1.0
Code
I am starting to think that supporting implicit *.schemadotorg.inc files is a bad idea. Especially if the includes are not loaded via database update.
Maybe a module will need explicitly include their *.schemadotorg.inc files.
Issue #3494863: ContainerNotInitializedException when accessing...