Convert the existing hooks into OOP hooks

@avpaderno Re: #3 Ok. I don't have the examples_toolbar() module in my MR/ local codebase. I have started on the block_example module. I am testing that the hooks work as i go. I am using Drupal 11.3 to test on. Changing the core version in the modules .info.yml files to core_version_requirement: '^11.3' so I can enable and test.

Will not be committing the info.yml files. I understand 11.4 is launched in a week or so. I wanted to make a start, even so.

To test out the cron_example module I had to fix the module. There was a public static create() function I copied from examples branch 4.0. The cron module and the cron config form are now working. It is beyond the scope of this issue. I can revert if required.

Re: #8 Ah, great. Will revert and change the forms to use autowiring. If you want this done as a separate issue, please let me know as the EmailExampleGetFormPage.php also errored and needs autowiring. I expect there will be a few more as I work my way through the modules. I would prefer to continue to commit the form fixes to this issue as I can test that the hooks are not breaking the modules in the UI that way..

I am looking for ideas on how to deal with a few outstanding PHPSTAN errors. There are a couple of \Drupal::service('some.service') calls that PHPSTAN does not like inside one of the hook classes. One call is to a service provided by the devel module. Can I use dependency injection the same way that I have handled the other \Drupal:: static call replacements I have done in the hook classes?

edited.

Please note to anyone reviewing the code, since Drupal 11.4 is not out yet, you can still test on Drupal 11.3 but will need to change all the module *.info.yml files and change the

core_version_requirement: '^11.4'

temporarily to

core_version_requirement: '^11.3'

Then you can enable the example modules.

I am working my way through your code comments. Unfortunately I was unable to add comments myself. Not sure if that can be enabled?
Re: 'ConfigFormBase already uses that trait; it is not necessary to use it.' I get an error message when I remove the use AutowireTrait;

I think I can get it to work if I follow this DI pattern from core:

final class SettingsForm extends ConfigFormBase {

  /**
   * Constructs a Navigation SettingsForm object.
   *
   * @param \Drupal\Core\Config\ConfigFactoryInterface $config_factory
   *   The factory for configuration objects.
   * @param \Drupal\Core\Config\TypedConfigManagerInterface $typed_config_manager
   *   The typed config manager.
   * @param \Drupal\Core\File\FileSystemInterface $fileSystem
   *   The file system.
   * @param \Drupal\Core\Render\RendererInterface $renderer
   *   The renderer service.
   * @param \Drupal\Core\Image\ImageFactory $imageFactory
   *   The image factory.
   * @param \Drupal\Core\Theme\ThemeManagerInterface $themeManager
   *   The theme manager.
   */
  public function __construct(
    ConfigFactoryInterface $config_factory,
    TypedConfigManagerInterface $typed_config_manager,
    protected FileSystemInterface $fileSystem,
    protected RendererInterface $renderer,
    protected ImageFactory $imageFactory,
    protected ThemeManagerInterface $themeManager,
  ) {
    parent::__construct($config_factory, $typed_config_manager);
  }

  /**
   * {@inheritdoc}
   */
  public static function create(ContainerInterface $container): static {
    return new static(
      $container->get('config.factory'),
      $container->get('config.typed'),
      $container->get('file_system'),
      $container->get('renderer'),
      $container->get('image.factory'),
      $container->get('theme.manager')
    );
  }

Were you expecting me to add a create() method?

When I add the AutowireTrait I do not need the create() method.

I see we covered this in #8:

It is described in AutowireTrait allows ContainerInjectionInterface classes to be autowired, which is valid since Drupal 10.2.0.

If you go to that link, the demo code shows use AutowireTrait; being used.

I just did a commit for 2 config forms CronExampleForm.php and ConfigSimpleExampleSettingsForm.php. They are fixed using the AutowireTrait. Without it they break.

Re: #8 and #15 and

I have gone beyond the scope of this issue. I have manually tested the fixes I have applied strictly for this issue. But because enabling the modules has in some cases blown them up with error messages I have had to fix other files and code not strictly connected with this issue. As a result I think I have made a lot of the modules work fully, probably all the modules with hooks.

I wanted to manually test dbtng_example. That forced me to fix the form(s). The module now works fully.

BTW all my manual testing is on Drupal 11.3. I am changing the core_version_requirement to ^11.3 for the modules I am testing.

I think there are quite a lot of the modules that will not work if I enable them and test all their routes manually. Since I am already fixing a lot of the modules, I would suggest a follow-up to continue that work ie to manually test each of the no-hook modules and fix any breakages whether in controllers or forms?

Thank you for the update. Good point in #19. As I was suspecting the problem is with my local version of Drupal. I am testing the module on Drupal 11.3.x. The Autowire trait was not present in FormBase in that branch:

https://git.drupalcode.org/project/drupal/-/blob/11.3.x/core/lib/Drupal/...

I need to test on Drupal main.