Бессовестно вольный перевод с комментариями, первоисточник drupal.org/project/entity_usage. Модуль Entity Usage был весьма ожидаем (автором), но впервые упомянут только в июле 2016 года, т.е. с запозданием примерно в 15 лет по отношению к «десктоповому варианту» соответствующей фунциональной возможности программы AuthorIT. Редакция от 19.03.2021.
В чем польза от бес ПОЛЕ зных сущностей Drupal? Трудно сказать. Но первое, что приходит в голову - это отсутствие необходимости манипуляций с запросами к базе данных Drupal, если речь идет о динамике. При загрузке значения поля «на лету» получается лишнее обращение к БД, в данном же случае такое обращение исключается. Это хорошо.
Можно по аналогии избавиться и от полей связанных сущностей. Можно вообще прикрутить HTML-код страницы не только Confluence, а даже Git или любого другого источника. Прогер пишет там себе что-то в Git, а его писанина синхронно обновляется в Drupal, что может быть очень удобно при глубоком детальном и дотошном документировании какого-нибудь программного обеспечения.
Автор при создании контента применяет AuthorIT, подготавливая при этом минимум два HTML-файла: один под анонс (teaser), а другой уже непосредственно под Body. Перед кодом файла анонса добавляется нолик, как в сов. секретных приказах Сталина. В частности, данную статью можно посмотреть в исходниках (форматах хранения):
добавив перед ними доменное имя.
Как-то так...
Внедрение страницы Confluence в сущность Drupal более очевидно и понятно всем, не один же автор будет периодически возвращаться и читать всю эту ахинею 😜
Итак, на любой пользовательской странице Confluence имеется меню •••, что в переводе означает Другие действия. Если двинуться дальше (Дополнительные сведения), то можно запросто Просмотреть формат хранения и убедиться в том, что страничка не только хранится в чистеньком HTML-коде, но имеет еще и уникальный идентификатор pageId в адресной строке браузера. Вот этим pageId и следует оперировать, используя способы загрузки контента сущностей Drupal без применения полей, а именно:
Вот и вся любовь.
Как написать техническое задание для сайта на Drupal так, чтобы заказчик был удовлетворен результатом разработки, а разработчик (как это обычно и случается) не оказался в дураках? Делимся универсальным решением, проверенным на практике и позволяющим быстро и легко разработать функциональную часть ТЗ для сайта на Drupal любого уровня сложности> Редакция от 10.05.2021.
Кастомные (в пользовательском контексте) переменные в Drupal 8 могут применяться для хранения и представления исходных (вводных) данных проекта, в состав которых входят наименование проекта, наименование продукта проекта, даты инициации и завершения проекта, заказчик, руководитель, куратор, все заинтересованные стороны, все участники проекта и многое-многое другое, в том числе параметры ссылок на внешние системы управления проектами (вроде Jira или Redmine).
Переменные могут существенно изменяться от проекта проекту, а могут и несущественно. Но в любом случае имеет смысл где-то их определить, зафиксировать документально и сохранить, а по мере необходимости вытаскивать на свет Божий и многократно повторно использовать в проектных документах. Все то же относится и к токенам. Редакция от 26.03.2021.
Любопытный модуль Drupal 7 HTML import. Если хорошо структурированный стилями заголовков документ ворда сохранить в формате HTML, а затем хорошенько почистить с помощью Dreamweaver, то можно получить ноды из заголовков.
Сокращенный перевод описания, комментарии после развертывания, настройки и проверки работоспособности. Редакция от 04.04.2021.
Библиотека взаимоувязанных документов, привязанная к отечественным стандартам разработки, проектирования и документирования, выполненная в многопользовательском глобально-сетевом варианте. В качестве движка применяется Drupal с минимально необходимым числом «контрибных» модулей и модулей ядра. Почти никакого программирования. Последовательность действий при подготовке и импорте контента в Drupal для организации нод, «портирование» ранее созданной и обкатанной библиотеки. Редакция от 12.03.2021.
Способы загрузки контента сущностей Drupal без применения полей могут быть реализованы с помощью шаблонов страниц. Для Drupal 7 основным шаблоном будет node.tpl.php, для Drupal 8 и 9 - node.html.twig. Данные шаблоны копируются из каталогов /modules/node и /core/modules/node соответственно в каталоги используемой темы оформления.
Затем оба эти файла переименовываются под тип материала. Тип материала лучше создать свой собственный, например topic. В этом случае шаблоны будут иметь наименования node--topic.tpl.php и node--topic.html.twig.
Далее немножко логики (вместо конкретного кода):
Вот и весь расклад.
Цитата из русского перевода руководства пользователя Drupal:
«В пределах сущности, данные хранятся как отдельные поля, каждое из которых содержит один тип данных, такие как форматированный или обычный текст, изображения или другие файлы или даты. Типы полей могут быть определены через ядро Drupal или модули.
Поля могут быть добавлены администратором для подтипа сущности, так что все сущности этого подтипа имеют одинаковый набор доступных полей. Например, Продавец тип материала на сайте городской ярмарки может иметь поля для Имя продавца, логотипа, URL сайта и описания, в то время как Основная страница тип материала может иметь только поля для заголовка и текста. Когда вы создаете или редактируете сущности, вы определяете значения для полей в сущности».
Всегда ли сущностям Drupal необходимы поля? Возможно ли обойтись без полей, как обойтись без полей и что это даст? Редакция от 14.03.2021.
Copyright © «Техническая документация» 2008-2021. Заимствуйте наши материалы с блеском! При воспроизведении материалов портала обязательна установка активной гиперссылки на источник — страницу с этой публикацией на tdocs.su.
Связь по эл. почте admin @ tdocs . su (без пробелов), тел. +7(967) 044-84-77 или в форме Контакты.
Редакция от 20.06.2018.