Бессовестно вольный перевод с комментариями, первоисточник drupal.org/project/entity_usage. Модуль Entity Usage был весьма ожидаем (автором), но впервые упомянут только в июле 2016 года, т.е. с запозданием примерно в 15 лет по отношению к «десктоповому варианту» соответствующей фунциональной возможности программы AuthorIT. Редакция от 19.03.2021.

Создан 17.03.2021 11:46:11

Данный модуль является инструментом отслеживания отношений (связей) между сущностями в Drupal (8 и более поздних). В настоящее время поддерживаются следующие методы отслеживания:

• сущности, связанные через поля entity_reference;
• сущности, связанные через поля link;
• стандартные HTML-ссылки внутри текстовых полей;
• медиа-объекты, встроенные (внедренные - embedded) в текстовые поля WYSIWYG с помощью Media Library в составе ядра Drupal;
• сущности, встроенные в текстовые поля с помощью модуля Entity Embed;
• сущности, встроенные в текстовые поля с помощью модуля LinkIt;
• сущности, связанные через поля block_field;
• сущности, связанные через поля entity_reference_revisions, т.е. абзацы (paragraphs);
• сущности, связанные через поля dynamic_entity_reference;
• сущности, связанные с помощью конструктора макетов (Layout Builder). Поддерживаемые методы:
  1. встроенные (Core's inline) (не подлежащие повторному использованию) блоки содержимого и
  2. сущности, выбранные с помощью дополнительного модуля (contributed) Entity Browser Block.

Как работает Drupal Entity Usage

«A relationship between two entities is considered so when a source entity points to a target entity through one of the methods described above», что в яндексовом переводе означает «Связь между двумя сущностями рассматривается таким образом, когда исходная сущность указывает на целевую сущность с помощью одного из методов, описанных выше».

Теперь все сказанное стоит пояснить словами и рисунками. Некая сущность _1.1 требование 1.1 (50638) внедрена сразу в четыре сущности - ТРЕБОВАНИЯ (54183), ОПИСАНИЕ (54184), ОБОСНОВАНИЕ (54388) и ИНСТРУКЦИЯ (54191) через поле Entity Embed.

В AuthorIT такое внедрение можно представить с помощью команды Show Relationships, результат будет примерно таков:

Объект _1.1 требование 1.1 внедрен в структуры сразу четырех книжек. Какая из сущностей целевая, а какая исходная - хрен разберет. Важен сам факт внедрения.

Возможно настроить, какие типы сущностей должны отслеживаться в качестве исходных и какие типы сущностей должны отслеживаться в качестве целевых. По умолчанию отслеживаются все объекты контента (кроме файлов и пользователей).

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

В данном случае используется только Ссылка на сущность, все остальные можно просто поотключать за ненадобностью.

Когда исходный объект создается, обновляется или удаляется, все активные плагины вызываются для регистрации потенциальных связей. Круто, но в целом понятно.

Сущности контента могут иметь ссылку локальной задачи (Вкладку) на своей канонической странице, связывающую сущность с информационной страницей «Использование», где пользователи могут видеть, откуда (с кем!) эта сущность связана. По умолчанию локальные задачи не отображаются. Вы можете настроить, какие типы сущностей должны иметь локальную задачу, отображающую информацию об использовании.

Еще круче, иллюстрируется самым первым рисунком.

Возможно также отображать информацию об использовании (usage) с помощью Views или пользовательского кода (см. документацию).

А это информация весьма полезная: с помощью Views, очевидно, можно будет показать не только связи объекта _1.1 требование 1.1 с книжками, а именно точки входа данного в структуры каждой книги. Сделать это можно, добавив идентификатор в тег article объекта, тогда ссылка будет выводить прямо на объект по его id.

Документация на Entity Usage

Официальная документация находится в онлайн-справочнике и в файле README.txt модуля Entity Usage. При обнаружении неполноты или неточностей в документацию имеет смысл открыть проблему (issue на странице модуля).

Известные ограничения Entity Usage

Здесь заметочка: продолжают подавляться заголовки 2-го уровня heading2, поэтому и не видны, но срабатывают по идентификаторам или якорям.

Плагины отслеживают одно использование на объект на поле (Plugins track one usage per entity per field)

The module will register only one usage of the same target entity per field - модуль Entity Usage будет регистрировать только одно использование одного и того же целевого объекта в каждом поле.

Простестировано только с MySQL (Only tested with MySQL)

This module has only been tested with MySQL databases - модуль Entity Usage тестировался только с базами данных MySQL. Да и хрен с ним.

Масштабируемость (Scalability)

«Some site setups might present scalability issues, particularly if you have many nested entities in a relationship chain that are saved together (paragraphs, etc), or usage pages with lots of source entities to be displayed - некоторые настройки сайта могут представлять проблемы с масштабируемостью, особенно если у вас есть много вложенных сущностей в цепочке отношений, которые сохраняются вместе (абзацы и т.д.), или страницы использования с большим количеством исходных сущностей для отображения».

Намек понятен - не плодить сущности и не пытаться делать вложения во вложения. Это придется проверить экспериментальным путем, покольку в отдельных документах уже свыше сотни вложенных сущностей.

Интеграция с Views

Интеграция с Views имеется, надо пробовать добавлять к ссылкам идентификатор текущей ноды через знак #.

Такой вариант с Views в Drupal Entity Usage не прокатывает, поскольку не формируются поля соответствующих ссылок, а только поле числа входимостей. То, что некий топик автоматически входит в состав структур некоего числа сборных документов - удобно. Можно грузить документы комплекта по одному, а не комплектом целиком. Значение входимости будет инкрементироваться автоматически по мере загрузки документов. Но при этом не формируются ссылки входимости по якорям или идентификаторам.

Что можно можно поиметь непосредственно из таблиц базы данных?

Таблицы, содержащие данные по входимости

Из первой таблицы становится очевидным, что под якорем или идентификатором должен быть target_id, ссылка формируется так - source_id#(node-)target_id.

Из второй таблицы ссылка может быть сформирована так - entity_id#(node-)field_entity_embed_target_id.

Таблицы, содержащие данные по входимости, как выясняется, реально содержат исчерпывающую информацию, необходимую и достаточную для организации ссылок входимости, но об этом в следующей статье 👹