Is "event_subscriber" a reserved naming convention for services? Are there guidelines to follow?

Ryan Hartman

17.09.2023, 17:45

So I was working on a project today, and an event subscriber we had written the better part of a year ago was determined to no longer be firing. Here is the definition:

services:
  my_module.event_subscriber:
    class: Drupal\my_module\EventSubscriber\XYZFeeds
    tags:
      - { name: event_subscriber }

I went through the normal debugging, and found that the event was not being added to the registry. Further debugging uncovered that having the name contain event_subscriber was causing it to not get picked up. If I changed that to anything else it would work, for example:

services:
  my_module.my_module_xyz_subscriber:
    class: Drupal\my_module\EventSubscriber\XYZFeeds
    tags:
      - { name: event_subscriber }

I cannot find any documentation that explicitly states that you cannot use that phrase in a service name.The only convention I am aware of is to always prefix the service name with the module it comes from.

Did something change from D8 to D9, or does this come from the Symfony Framework components that are part of Drupal?

0 + 0

подписчики событий

Jaypan

17.09.2023, 18:03

Как выглядит ваша служебная декларация?

Ответить

Ryan Hartman

17.09.2023, 18:08

@Jaypan обновил вопрос с фрагментами кода до/после.

Ответить

4uk4

17.09.2023, 19:29

`my_module.event_subscriber` может быть зарезервирован, поскольку он уже используется.

Ответить

Рейтинг:2

Drupal

Clive

17.09.2023, 19:20

Похоже, что он не зарезервирован/запрещен Drupal или Symfony — у меня это отлично работает в 9.3.13 после добавления кода и перестроения кеша (без дополнительных шагов):

custom_module.services.yml

Сервисы:
  custom_module.event_subscriber:
    класс: Drupal\custom_module\EventSubscriber\XYZFeeds
    теги:
      - {имя: event_subscriber}

src/EventSubscriber/XYZFeeds.php

<?php

пространство имен Drupal\custom_module\EventSubscriber;

используйте Drupal\Core\Config\ConfigCrudEvent;
используйте Drupal\Core\Config\ConfigEvents;
используйте Symfony\Component\EventDispatcher\EventSubscriberInterface;

класс XYZFeeds реализует EventSubscriberInterface {

  общедоступная статическая функция getSubscribedEvents() {
    возвращаться [
      ConfigEvents::SAVE => 'configSave',
      ConfigEvents::DELETE => 'configDelete',
    ];
  }


  общедоступная функция configSave (ConfigCrudEvent $event) {
    $config = $event->getConfig();
    \Drupal::messenger()->addStatus('Сохраненная конфигурация: ' . $config->getName());
  }

  общедоступная функция configDelete(ConfigCrudEvent $event) {
    $config = $event->getConfig();
    \Drupal::messenger()->addStatus('Удалена конфигурация: ' . $config->getName());
  }

}

Это выдает ожидаемые сообщения о сохранении/удалении конфигурации, поэтому, вероятно, ваша проблема связана с чем-то более локализованным.

Одна из идей для дальнейшей отладки, которая приходит на ум, состоит в том, чтобы убедиться, что у вас нет пользовательского (или даже вспомогательного) кода, который изменяет службу, возможно, даже удаляет ее. Это можно сделать с помощью поставщик услуг, поэтому поиск соответствующих папок для Поставщик услуг может быть первым шагом.

Также стоило бы попробовать изменить первую часть идентификатора, а не вторую, чтобы увидеть, действительно ли это так. event_subscriber это вызывает проблему или строку в целом:

Сервисы:
  my_module_test.event_subscriber:
    класс: Drupal\my_module\EventSubscriber\XYZFeeds
    теги:
      - {имя: event_subscriber}

Если измененная версия работает с .event_subscriber, по крайней мере, вы исключили это как проблему.