14 июля 2018 в 11:57
Здравствуйте! Есть необходимость ускорить работу с полями и типами материалов путем экономии времени благодаря уходу от работы через UI (с заменой на импорт, либо drush команды или прямое редактирование файлов или бд), сразу уточняю, что в первую очередь интересуют решения для Друпал 7, и эта тема - это поиск специалиста для всех или одного из этих направлений:
1)перевод названий полей (предпочтительная система перевода на сайте i18n + Entity_translation )
2)создание полей
3)создание типов материалов
По drush командам на форуме предлагалась идея от
gun_dose о том, что через module_implements можно получить все имплементации hook_field_widget_info (так как сложность была именно с виджетами) и от bumble посмотреть реализацию стандартного профиля, написать свою drush-команду (или просто скрипт) по аналогии, также то, что мне удалось найти по этой теме обсуждалось на форуме в этой теме. По стоимости и срокам подробнее можно в личку или здесь.
Комментарии
Еще рассмативаю вариант с помощью features, который был предложен gun_dose с самого начала и semantics в теме по почасовым консультациям .
И еще есть статья по Друпал 8 http://drupal8.ovh/en/tutoriels/283/create-a-field-a-node-entity-program... (возможно она натолкнет на какие-то мысли)
Актуально?
Да
Обновление:
По созданию полей задача частично решена благодаря
webpavilion, остатеся задача перевода метки поля с помощью drush и идея еще одного инструмента.
В принципе не важно, как это будет реализовано (от драш команды или настройки features до модуля для импорта полей и/или импортера импортеров), главная идея в ускорении повторяющихся однотипных настроек (частично изложена здесь, но теперь более четко уже оформлена).
Если уже пойти дальше, то вторая идея в том, чтобы это было что-то типа импортера настроек полей и импортера настроек импортера для этого типа материала и чтобы из одной таблицы брать данные и для того, и для другого:
1)и для создания полей типов материала (если это будет какая-то таблица для CSV для создания полей, то столбец с машинными именами пойдет и в следующий пункт)
2)и для создания импортера этого типа материла (эти же машинные имена можно использовать для mappings дважды:
а) и как название будущих столбцов для соответсвий с файлом источником CSV (в таблице для импорта материла нужно будет просто столбец с машинными именами сделать в 3 клика в редакторе названиями столбцов для импорта содержимого полей нод),
б)и как вторую част (то что в feeds справа) соответсвия импортера, т.е. как машинное имя конкретного поля, в которое значение из соответсвующей ячейки при создании ноды нужно подставлять).
Вторая ссылка в комменатрии не та, имелась ввиду та же тема, которая указана и в начале комментария
Обновление: сделала пример таблицы c пояснениями как я представляю себе таблицу источник (в 3 пункте опечатка, должно быть "полей")
Столбцов будет очень много. Для поиска можно обозначить начало блока нужных столбцов специальными "метками" - например для настроек терминов перед столбцами с этими натсройками создать ячейку termm, и потом находить их с помощью Ctrl+F :" termm"
Здесь пример столбцов таблицы для указания настроек второго шага для поля ссылки на термин
и
таблица источник перевода
таблица со значениями уже для импорта ноды, а импортер для этого типа материала предполагается создать с помощью импортера импортера (или специального модуля) на основании первой таблицы (но в названия столбцов можно брать не машинные имена, а более понятные метки)
На этом видео я пытаюсь объяснить как я предполагаю работать с этой таблицей
Получилось немного длинное объяснение, но на практике заполняться там будут 3-4 столбца, остальные (настройки) будут просто копироваться.
Здесь если нужно более подробное видео (но в принципе оно вспомогательное, если по 1-му понятно, то его можно и не смотреть)
Появились еще 3 гипотезы о путях решения (точнее две, а одна ранее предложенная gun_dose и semantics расшириалсь):
1 и 2 можно использовать вместе
Вот пример редактирвания файла features из этой статьи
Я прелагаю делать то же самое, но не редактировать, а дописывать. Только нужно дописать во всех нужных местах.
И для этого предлагаю использовать модуль (способ1) или формулы редактора (способ 2).
1)в качестве модуля можно попробовать использовать для этого что-то типа feeds_tamper, но для features (или может быть уже есть модуль такой?) и можно будет тогда новый тип материала не только с импортером, но и с представлением интегрировать сразу.
Т.е. использовать функционал встраивания, который уже есть в features, но сделать типа плагина, который бы на основании определенных данных редактировал бы и файл .info, и другие, например файл features.views.inc и другие
2)сделать в редакторе специальные ячейки, в которых добавить формулы автоподстановки значений к значениям других ячеек источников,
например к содержимому какой-то ячейки с машинными именем добавлять
"echo... " и дальше имя файла в который нужно подставить и еще что-то типа $... = и т.д., все это можно перемежать со значениями ячеек, (т.е. фактичсеки сделать то, что делается в определнных файлах при нажимании кнопочек через UI)
сделать пару десятков таких формул в редакторе, потом генерировать на основании этого файл и просто вставить по SSH, если нужно то генерировать еще и комнады cd в нужных местах
3)если нужно работать с переменными, то можно также в редакторе генерировать комнады группы variable для drush потом их брать в уже готовом виде и подставлять.
Для расширения features, в т.ч. для переменных, наверное, если потребуется можно еще использовать strongarm
Теперь главный вопрос: А зачем все это?
Это не ирония и даже не сарказм..
Просто хочется понять, чего Вы хотите добиться в ИТОГЕ?
И как это можно (для чего-то нужно) применить на практике?
Убрать однотипные рутинные повторяющиеся действия, которые можно автоматизировать с этапа создания полей и импортеров и желательно представлений. У меня сайт типа библиотеки с сильной каталогизацией. Много типов материала с разными полями. И нужно их импортировать. И потом еще как-то выводить представления. Если есть другие способы, то я с удовльствием их использую. Просто пока ничего другого в голову не пришло. Да, я понимаю, что я уже много дней трачу, чтобы сэкономить пол часа на создании полей типа материала и сэкономить столько же на создание импортера. Зачем разработчику сайта (я сейчас не о себе говорю, а в принципе) это делать, если можно сразу просто подгрузить файл и все готово.
В UI можно делать, когда нужно поэкспериментировать или новое полей какое-то попробовать. Если типы полей одни и те же (только метки разные) и все настройки и виджеты уже хорошо известны, то зачем тратить время в UI на это? Все равно же есть какой-то список полей и настроек перед созданиме типа материала, зачем вообще кому-то делать эти однотипные действия? Если кому-то это доставляет удовльствие, UI остается для любителей. Но точно так же как когда-то убрали однотипные действия при создании нод (создав Feeds и Migrate). Точно так же как когда-то создали Features для переноса существующих настроек, я хочу найти или создать инструмент для быстрого создания новых комбинаций настроек. Я хочу создать в редакторе типа libre office список полей, которые мне нужны в типе материала, и в автоматическом или полуавтоматическом режиме этот список превратить в поля типа материала и импортер и хотя бы заготовку для представления (или хотя бы что-то одно из этого).
Вы в какой-то одной тематике работаете, с однотипными сайтами?
Вам профиль не проще создать и с ним работать?
Тематика близкая в приницпе, но часто бывает необходимость создавать новые типы материала со новыми полями (метки полей абсолютно разные каждый раз, словари для терминов тоже могут быть разными).
А как профиль может помочь? Не соображе про какой профиль Вы говорите?Профиль типа дистрибутива Вы имеете ввиду или типа features? не пойму?
Но порфиль же для перенеса имеющегося на разные сайты. Да, бывает приходится выносить что-то на отдельный домен, но в основном на одном сайте новое нужно добавлять, т.е. смысл не в том чтобы с одного сайта на другой переносить, а чтобы на новые поля, типы материала и импортеры быстро создавать.
Может хотя бы для Друпал 8 есть такой инструмент?
Кстати еще и словари удобно было бы создавать.
Есть generate-vocabs но пока dev и только количество можно указать про имя ничего не вижу.
Знакомо..
Сам терпеть не могу рутинные операции и частенько с огромным удовольствием трачу недели рабочего времени чтобы сэкономить 15 минут в год, а то и всего 15 минут-)))
Тут скорее всего дело не в друпале , а в архитектуре данных Вашего приложения.
Значит как-то их можно организовать проще, чтобы не дублировать постоянно одни и те же сущности.
В drupal 8 эти проблемы, в немалом своем объеме, решены..
Про drupal 7 вспоминаю с доброй ностальгией о молодых годах и ужасом(в сравнеии с drupal 8)-)
Вашу бы энергию, да в мирных целях-)
Кстати, еще в 2011 один участник данного форума написал такой модуль: https://www.drupal.org/project/bundle_inherit
Он очень простой и очень полезный, позволяет сделать сущность-шаблон (с общим набором полей) и другие сущности наследовать от нее.
Причем, там есть 2 режима наследования:
- дочерняя сущность полностью не зависит от изменения набора полей родителя
- дочерняя сущность полностью наследует все изменения набора полей родительской.
Согласитесь, этот подход "немного" оптимальнее Вашего. И требует на несколько порядков меньше усилий.. Как раз для нас - убежденных радикальных лентяев-)
Это если Вам надо далее развивать проект на drupal 7,
А для новых проектов настоятельно рекомендую погрузиться в drupal 8
Спасибо большое. Изучу.
Спасибо. Думаю об этом. Чтобы типы материала и поля на что-то заменить. Но пока никаких мыслей.
Представьте, что у меня тип материала, например, музыкальная тональность
там поля типа (обозначение, ступени, опевание и т.д.) -ссылки на термин и
рядом с каждым поле изображения. Как это можно другой архитектурой сделать?
Терминами разве только. Но чтобы все вместе тогда представления, а я хочу статичные делать страницы для более прозрачного индексирования.
А чем у вюьсов индексирование не прозрачное? Сколько у вас уже есть суммарно полей и типов материала на сайте? Надеюсь, вы понимаете, что чем их больше, тем сложнее сопровождать такой сайт?
Спасибо за ответ.
Ну я имею ввиду что нормальное индексирование. Представления вообще могут не проиндексриваться же?
К тому же если я сделаю терминами все равно поля для теримнов придется создавать. Но буду думать в сторону терминов, пока просто не ложится все у меня в такую архитекртуру. А Вы думаете, что лучше терминами делать отдельными и представлением выводить?
Ну в основном пока заготовки для импорта. Полей в каждом типе 15-30. Я могу если что сделать мультисайтинг и на отдельные домены вынести разные типы материалов.
Так чтобы было по 10-15 типов материалов не более.
В чем сложность?
Вьюс не может не проиндексироваться. Поисковикам вообще плевать, вьюс это, нода или термин таксономии. И всё равно непонятно, зачем столько полей и столько типов материалов. Можете привести пример двух типов контента со списками их полей?
По поводу сложности: у ноды нельзя поменять тип, а когда типов становится несколько десятков, то контентщик может ошибиться и создать ноду не того типа, а потом придётся пересоздавать.
Второе: вы не подумали об упрощении структуры, в результате создали уже который топик на форуме, где пытаетесь изобрести велосипед для этой обезьяньей работы.
Потому я и предлагаю вам описать то, что должно получиться в итоге, чтобы форум коллективным разумом смог помочь вам подобрать инструмент для реализации.
Опять же уверен, что paragraphs и double_field помогли бы сделать вашу структуру намного более компактной.
Тут, вероятно, нужно смотреть в сторону EAV или properties.
Ибо таблиц в БД уже поди под тыщу, а нужны все филды практически разово.
А ещё бывает, что от половины полей можно отказаться, просто нормально настроив ckeditor ?
Думаю все время об упрощении. На текущий момент ничего удобно импортируемого и полуавтоматически переводимого (как названия полей и термины) не приходит в голову.
А несколько тем, ну это наверное тоже тяга к каталогизции, вот представьте кто-то хочет научиться пользоваться drush filed clone, а у меня все про это в этой текущей теме и вынужден человек читать весь этот топик. Я стараюсь тему выделять отдедльно когда какой-то узкий аспект выделяется, который может кому-то пригодится и всегда делаю ссыки на близкие. И по самой сути как раз обеъзянью работу хочу убрать, обезьянья работа, это когда каждый человек в поиске чего-то перелопачивает кучу информации и его труд потом повторяют еще тысячи люде заново. Пока поисковики лучше всего индексируют текст и пока заставить авторов , например, видео, подробно проставлять теги невозможно, а youtube не довел до совершентсва распознавание содержимого видео, ручная каталогизация на мой взгляд актуальна. К тому же у меня не только для каталогизции это нужно. Просто на текущий момент основная задача.
Спасибо. paragraphs подумаю, как прикрутить. double_field упростил бы задачу, но типы полей не те, да и потом могут возникнуть сложности с разделением в результатах поиска или представления. В моем случае это не совсем единые и не всегда парные поля. Но спасибо для других случаев буду иметь ввиду.
Да, про лентяев точно )))
Если тот модуль типа bundle clone (клонирует имеещийся тип материала) то все равно, тогда проще командой драш клонировать поле с нужными настройками и новым машинными именем и переименовать просто метку потом или допилить команду, чтобы и метку сразу менять.
Если модуль позволяет как в tamper что-то пакетно добавить, то это то, что нужно.
А если нет, то мой способ требует больше усилий для создания этого нового инструмента, но меньше усилий потом в работе.
Буду изучать bundle_inherit и думать о переходе на 8.
А что из этого можно делать на 8?
Направление мыслей правильное..
Не помню кто сказал, но я с ним полностью согласен (возможно не дословно): Если вы делаете что-то слишком сложно, значит вы что-то не так делаете.
Чую, задачка интересная.. иногда люблю поломать над такими голову..
Если будет необходимость, пишите в личку, свяжемся более удобным способом, чем смогу - помогу
Возможно, реализовать кодом такой функционал сложно, но по будущей работе с источником и сама логика и и алгоритм процесса на мой взгляд как раз достаточно просты и ничего лишнего.
например просто написать список команд drupal-console, которые оперируют создаваемыми сущностями, в shell-скрипт , и при необходимости его запускать (с динамическими аргументами).
Все сущности (и многое-многое другое) в drupal 8 - это простые текстовые конфигурационные файлы.
Которые можно написать вручную
Которые можно сгенетировать программно
.. далее по степени испорченности
и потом з-агрузить в нужный проект..
достаточно?-)
Спасибо. Это что-то типа создания совей drush команды?
Это проще сделать чем комнаду для драш создать?
Ну у меня есть сайт (типа моего блога) на восьмерке, но он голый почти и я
потому что копаюсь с 7 все времяни composer ни drupal-console пока не могу освоить. Но придется, наверное.Это как?
Спасибо.
Спасибо
А как мне тогда настроить индексирование?
Вот у меня была тема по индексированию представления
Если для закрытия идут rel="nofollow" + canonical
Как оно там работает именно во views?
На что оно будет ссылаться?
На разнозненные термины? А если я хочу, чтобы именно определенное сочетание проиндексривалось?
Но представления я открывать для индекса не хочу так как будет много похожих.
По факту то что нужно сделать это смесь научного исследования с одновременным представлением его online (просто удобного обзора) и результатов ручной сортировки сведений
(либо систематизации) для более удобного поиска того, что часто используется.
Так как сейчас делаю поля по музыке напишу пример по музыке (сразу чтобы не было впросов про то, что такие сайты уже есть пишу подробно, что таких как мне надо нет, и что да моя задача очень узкая, но результат - сайт с возможностью остортировать потом что-то по определенному признаку может быть полезен исследователям в этой области и тем кто просто учится чему-то). Ну, например я учусь играть на гитаре или скрипке и захотела поиграть гаммы и изучить по очереди все основные тональности, определяю какие там тоника, доминанта, субдоминанта, учусь строить трезвучия главных ступеней для этой тональности, слушаю произведения в этой тональности или мне интересен феномен цветового слуха, хочу понять как общие особенности есть у восприятия звука и у цвета и вообще может быть как мы воспринимаем мир (ну вот например я случайно выяснила что один из моих любимых аранжировщиков современных ноты не только слышит но и "видит" и что разные композиторы с цветовым слухом немного по разному "видели" ноты, и мне стало интересно, послушать все произведения в определнных тональностях и почувствовать ассоциации с какими цветами у меня они вызовут, нужно просмотреть пару сотен роликов на youtube, чтобы найти нужное и я хочу потом этот результат выложить, если кто-то потом будет искать то сможет быстро найти то, что нужно. Представьте, что книги в библиотеке содержат подпись только названия произведения или только автора, а Вы открыли многие книги и знаете и то, и другое, и перед тем как закроете, хотите подписать недостающую инфомацию в каталоге хотя бы для части книг) Или второй момент (фрагментароность некторых данных в обучающих материалах). Например начинаю с До мажор и получается что сайтов очень, очень много и очень объемных, но одна инфорация на одном сайте, другая на другом, третья на третьем или есть учебник по музыке и там для примера приведены несколько главных ступней для некторых тональностей, а сводной таблицы для всех тональностей для этих ступней во многих учебниках нет (предположим ну или какой-нибудь другой таблицы нет). Или хочу найти произведения опредленного автора в опреденной тональности на определенном инструменте, а произведения в youtube часто содерсодержат например одно "Название призведения, имя автора и тональность"(классические) либо "Название и инструмент". А мне нужно сделать такой каталог, чтобы там по определенным темам все было в одном месте полно и под рукой.
Напимер Тип материала 1 "Тональность"
Поля: название (title), обозначения (термин) Все ступени (прим. ред. ноты) тональности (термины и изображение), дальше ступени по отдельности со специфическими названиями типа тоники 1 ступень (тоника) (термин того же слвоаря или мультиродители), 2 ступень (термин)...7 ступень (термин)
уже 11 полей и это только треть
Пример содержания полей: До мажор; C, Сdur; до, рем, ми ...си; изображение; до, ре, ми и т.д.
Самих материалов такого типа будет для начала 42.
Т.е. каждое название поля повторится 42 раза и поэтому мне удоно перевести его один раз.
Также мне нужно подставить автоподстановкой в непереводимое поле и перевод терминов (которые я тоже хочу первести один раз) содержимого полей.
В разные поля выделяю, чтобы перевод полей делался один раз.
Мне нужно чтобы проиндексированлось именно
заголовок: "До мажор" и на той же странице слово "1 ступень тоника"(из названия поля" и рядом с ним - "до"
2 тип материала "Музыкальное призведение"
И там у него полей 10
(Заголовок, тональность (сслыка на термин), инструмент (термин), видео (embeded field, исполнитель (термин)). И потом некторые произведения еще будут полем (ссылкой на сущность) для типа материала тональсти. А остальные подборки (например по атвору и инструменту) уже представлениями.
хочу ограничить количество видимых типов, предполагаю попробовать ролями это сделать
или можно создать каталог типов материала систематизирванный (создать страницу каталога и чтобы назвнаия типов вели на страницу создания определенного типа)
Спасибо. Изучу
А как импортировать тогда?
Кстати, я вот думаю о встроенном использовании терминов внтури текста простого. Как их можно удобно встроить в текст из редактора или импортируемый, или про импорт точнее как можно их вычленить при импорте, какие лучше поискать модули которые бы парсили и в случае совпадения делали слово ссылкой на термин? и как такой функционал можно встроить в специфические типы материала типа quiz?
???
По поводу rel=nofollow - естественно, имелось в виду закрытие параметрических ссылок - фильтров и пейджеров. А сами вьюсы всегда нормально индексируются
Это неправильно. Произведение должно ссылвться на тональность, а тональность на произведение не должна. Список произведений на странице тональности должен выводиться блоком вьюс с контекстным фильтром. Банальная логика - когда кто-то сочиняет произведение в ля-миноре, ля-минор остаётся ля-минором и никак сам по себе не меняется.
Т.е. если у меня будут, например, представления:
"Все произведения автора", потом "все произведения его для какого-то инструмента", потом "его же произведения в какой-то тональности", то как это все проиндексируется?
Я знаю одного профессионального исполнителя, который считает что нельзя исключить, что исполнение произведения может менять само произведение, причем исполнитель классической музыки, т.е. он не делает "каверов" (ну что-то типа информационного поля), нужно поинтересоваться, что он думает о влиянии произведения на тональность )))
Я предполагаю что может быть еще что-то типа гравитации и взаимного влияния. Как с луной и Землей.
А если серьезно, то как мне тогда вывести примеры произведений в тональности, если исходить из того, что это тип материала?
Может тогда просто выбрать 3-4 вручную и доюавить в поле (встроенного видео)? Или Вы думаете лучше сделать тональность термином с 30 полями и выводить в представлении вместе с произведениями?
Я просто предполагаю, что в конце всех полей тональности будет типа анонса из 3-4 произведений c ссылкой на представление по произведениям или как-то фасеты прикрутить.
Я имею ввиду, что в типе материала хочу сделать поле с типом "ссылка на сущность", чтобы представить примеры произведений в тональности, а не что сам заголовок т.е. сама "тональность" будет ссылкой на произведение.
Т.е. просто для названия тональности я хочу сделать словарь без доп полей.
А потом сделать тип материала и импортировать уже информацию о тональности нодами определенного типа материала. А произведение будет иметь поле ссылки на термин (из словаря "Тональность"). У меня вопрос скорее по тому делать ли тип материала "тональность" отдельный или добавлять поля к термину"тональность".
Я просто уже не могу отследить историю применения терминов. Сначала их использовали как теги просто? Потом решили объединить и ноду и тег в одно (и для этого добавили поля к термину) и при необходимости решили их разделять, просто не выводя поля? Или наоброт короткий тег, который является только тегом это более продвинутая форма? Или как там обстояло дело? Какая логика выбора?
В принципе нет смысла наверное делать еще и тип материала если можно добавить поля к термину, но с другой стороны а вдруг где-то потом в каком-то модуле не будет средств отделить поля от заголовка и нужен бутет только заголовок, тогда можно будет использовать чистый термин.
Блин.. понял в чем проблема-)
@univerico
Вы оказывается все делаете на нодах -)) (один тип материала: node и куча его бандлов (bundle))
Для Drupal 7
есть модуль ECK ( https://www.drupal.org/project/eck )
Позволяет мышкой накликать любое кол-во необходимых типов материалов
у каждого типа материала отдельная таблица БД
К типу материала можно добавить необходимые property (поля , которые хранятся в таблице типа материала
и наследуются бандлами этого типа, например как в node: title, created, updated, publiched и т.п.)
Если установить модуль Inline Entity Form ( https://www.drupal.org/project/inline_entity_form )
который позволяет добавлять-редактировать сущность поля entity_reference непосредственно в форме родительской сущности, то функционал модуля ECK будет практически подобен функционалу модуля Paragraphs
и еще немного шире..
Для Drupal 8
Добавление кастомных сущностей (типов материала) из "коробки"
Добавление к кастомному типу материала необходимых полей, которые будут наследоваться его бандлами - из "коробки"
базовые команды composer и drupal-console не сложные.
Загрузка модуля с drupal.org: composer require drupal/[ИМЯ МОДУЛЯ (можно скопировать из адресной строки страницы модуля на drupal.org)]
причем drupal-console интерактивна, т.е. ей достаточно указать команду (например generate:module а потом geberate:entity:content) и она спросит все необходимые дополнительные параметры команды
ЗЫ. @univerico - при написании длинных текстов на форуме, и упрощении их прочтения и понимания собеседниками, тексты лучше, как минимум, разбивать на параграфы (по смыслу и т.п.), а еще лучше, давать разделам поста заголовки-подзаголовки.
А то пишите-пишите, стараетесь-стараетесь, а прочтут Ваш пост не все, а кто прочтет - или не поймет, или поймет не правильно-)
исполняемый в консоли операционной системы файл со списком консольных команд.
грубо говоря, просто выполняет этот список команд, но так же можно передавать в него аргументы,
использовать циклы и ветвления.
В windows это bat-скрипт
В linux (обычно серверная ОС web-сервера) это bash-скрипт
Спасибо большое! Очень интересно. Постараюсь приспособить под свои задачи и в любом случае пригодится.
Для меня интерактивная комнада это почти то же что и UI. Мне удобнее изучить сразу возможности команды, сделать заготовку (потому что иначе куча очепяток) или алиас и использовать ее.
Учту)) Наверное есть какая-то
спешкасложность на этапе перевода из мыслей в текст, еще одно подтверждение, что множество полей, это как раз для меня, тем более с такой структурой и поиск потом такой будет более удобным. Видимо потому и создаю темы отдельные (отчасти интуитивно), чтобы это читать было удобнее. Учитывая общие замечания, буду писать в одной теме, но с параграфами и рубриками)))Да, под типами материала имеются ввиду типы материала в териминологии админки.
В drupal (7,8) есть 2 таких понятия:
Тип материала (entity type)
Бандл (bundle)
Тип материала (entity type)
Стандартные:
node
user
comment
и т.д
каждый тип материала имеет в БД свою таблицу для хранения данных
Бандл (bundle)
Это то, что Вы добавляете в админ меню Структура - Типы материалов
для entity type: node
По аналогии с node можно добавить дополнительные типы материалов (в drupal 8 при помощи друпал-консоли, в drupal 7 - модуль ECK)
И уже для этого типа материала добавить необходимые бандлы, которые имеют некоторые общие поля-property, объявленные в entity type, и любые дополнительные, добавленные через стандартный вэб-интерфейс Drupal - добавления-настройки полей к сущности.
После изучения возможностей все же предположение, что этот модуль хоть и очень полезный, но мою задачу не решает полностью.
Если бы у меня был шаблон, который нужно было бы немного видоизменять, то да, это было бы решением.
Но
1)у меня почти везде метки полей разные и словари разные для терминов.
2)вопрос: там же все равно надо накликивать поля при первичном их создании хоть для сущности - properties, хоть для bundle -fields ? не могу найти, как с помощью него можно первично создавать много полей быстрее, чем обычным способом?
Придется, наверное пока пытаться допилить добавление метки к field clone и клонировать поля одного типа внутри каждого bundle.
Благодаря тому, что удалось его протестировать в commerce kickstart, где он прямо очень удачно влит и использую его. Интересно будет протестировать теперь в связке с ECK.
Прелесть кастомных сущностей в том, что добрая половина хэндлеров для вьюсов к ним попросту отсутствует, и поэтому то, что можно накликать на нодах, приходится кодить. Кто плотно работал с коммерс в восьмёрке, тот поймёт о чём я.
У страницы есть урл, заголовок и какой-то текст на ней. Вот так и проиндексоруется.
Ясно. Спасибо за пояснение.
Все что выше у меня тип материала = bundles для нод,
а то что в этой терминологии тип материала у меня выше "сущность" = нода, таксономия, юзер, файл и т.д.
Далее тогда буду вместо "типа материала" лучше писать "bundles", как раз ближе к drush терминологии и к коду Друпал.
С термином "тип материала" наверное из-за перевода так получается,
и conent types и entity types так первеодят, да?
На всякий случай не буду использовать, буду писать "тип сущности".
Так можно?
Но то что можно накликать для представлений для нод на Друпал 8 можно кодить или делать файлами, верно?
Немного не так. При работе с кастомными сущностями часть стандартного функционала нужно писать самому.
Спасибо. А можно подробнее, что именно будет закрыто и как пейджеры будут закрыты?
Где почтитать про это?
Я же уже написал)))
Я думаю, Вам надо просто правильно спланировать структуру данных приложения.
Правильно спланированная структура данных на порядки упрощает разработку, а в последствии - поддержку и расширение проекта.
Спасибо.
А какие еще могут быть более правильные (хотя бы с точки зрения скорости создания структуры) варианты?
Я пока для Друпал 7 вижу только три варианта:
1)Делать bundle нод
2)Делать Терминами таксономии с полями словаря
3)Делать типами сущностей
+ еще изучу EAV и properties.
Везде свои плюсы и минусы, но везде новые поля и их настройки нужно кликать и ни один из способов не решает проблему создания большого числа полей и настроек потом под это Feeds/Migrate, Views.
Остается только делать специальный импортер полей и импортеров или из имеющегося, формулы редактора и drush fields clone или Drupal 8.
Чтобы ответить на этот вопрос, необходимо знать: что, из чего и зачем делает Ваше вэб-приложение.
В одном из длинных "нечитаемых" комменатриев без абзацев )))
который начинается со слов "По факту то что нужно сделать это смесь научного исследования с одновременным представлением его online (просто удобного обзора) и результатов ручной сортировки сведений
(либо систематизации) для более удобного поиска того, что часто используется."
Описано.
Но возможно стоит сделать более четкое описание как часть ТЗ, если не понятно, то что там написано.
Задача создать каталог, в котором будут типы элементов (например музыкальные тональности, видеозаписи исполнений музыкальных произведений, мастерклассы по скрипке) и признаки (например для первого музыкальные ступени тональности, трезвучия тональностей; для второгоинструмент, на котором произведение исполнено, исполнитель и др).
Ну или если взять в примере того, что часто делается на сайтах (интернет магазин электроники - у меня другая тематика на самом деле но принцип я думаю похожий), то пример такой: буду писать элемент и в скобках признаки, потом пример:
телевизор (диагональ, фирма производитель, тип дисплея)
20, Philips, жк
фен (модщность, фирма производитель, возможность регулировки температуры)
2000, Philips, есть
У каждого типа элементов свой набор признаков.
Чтобы потом можно было найти все элементы с определенным набором признаков
Я предполагаю что типы элементов можно делать с помощью
1)bundle нод
2)словарей или терминов
3)типов сущностей
Для каждого признака создавать отдельное поле.
А значения для каждого признака заносить в определенные поля.
Потом фасеты или представления.
Плюс многоязычность.
Хотя я думаю все же в сторону того, что у меня действительно немного специфическая задача, но все же мне действительно нужен именно такой инструмент, как я описываю.
Если Вы хотите, чтобы Вас поняли максимально правильно, Вы мыслите в нужную сторону.
По сути получается некая сущность с набором характеристик, назовем характеристику аттрибутом сущности, коих у нее может быть неограниченное количество.
По сути, структура аттрибута проста:
1.Наименование аттрибута
2.Значение аттрибута
Например сущность:телевизор
аттрибуты:
- наименование: диагональ, значение: 40 дюймов
- наименование: фирма производитель, значение: Philips
- наименование: тип дисплея, значение: ЖК
т.е. само собой напрашивается аттрибут сделать сущностью с 2-мя полями:
1.Наименование аттрибута
2. Значение аттрибута
А родительской сущности просто добавить многострочное поле Аттрибуты, типа entity_reference на сущность Аттрибут
Типов аттрибутов можно сделать любое необходимое кол-во.
Например некоторые аттрибуты могут иметь строго определенные наименования (поле Наименование аттрибута)
Следовательно, создаем для списка наименований словарь таксономии, в котором будут содержаться все возможные наименования аттрибута.
И естественно, поле Наименование данного типа аттрибута делаем ссылкой на термин данного словаря.
Другой тип аттрибутов может иметь произвольное наименование, следовательно в нем поле Наименование должно быть простым текстом.
Другой тип аттрибута может иметь определенное наименование из предопределенного списка, и списко возможных значений.
Для него можно сознать 2-х уровневый словарь таксономии, первый уровень которого будет соответствовать Наименованию аттрибута, а второй уровень: списку возможных его значений.
и т.д. и.т.п.
Получается, Вам необходимо не бесконечное кол-во полей-характеристик, а всего лиш одно, типа entity_reference, ссылающееся на несколько типов сущностей-аттрибутов.
PS. Я понимаю, что возможно, приведеный Вами пример (про товары) далек от того что необходимо реализовать в Вашем проекте, но раз Вы говорите, аналогии достаточно близки, скорее всего данный пример организации структуры данных Вам поможет систематизировать и упростить структуру данных Вашего приложения.
Спасибо большое! Я обязательно все очень внимательно проанализирую и постараюсь сопоставить этот пример со своей задачей (у меня особенность, которая накладывает ограничение на такую архитектуру при первом взгляде – что значение атрибутов у меня часто складываются из нескольких терминов таксономии и еще некоторых типов полей, и мне нужно потом иметь возможность выводить это все в поиске по отдельности, т.е. мне нужно сначала вникнуть в варианты выведения этого потом с помощью views или фасетов и посмотреть, не будет ли там ограничений) и в любом случае такой способ может пригодиться для других проектов.
И точно можно использовать хотя бы частично в этом. Для произведений, которые я хотела помещать в поле типа ссылки на сущность в тональности, как раз подходит такая архитектура. По другим более сложным нужно пробовать. Короче, нужно попробовать и посмотреть на практике.
Но сразу хочу сказать, что видимо по причине того, что я хотела показать возможную область применения я увела эту тему несколько в сторону обсуждения архитектуры, на самом деле на Ваш первый вопрос(зачем это нужно) я думаю достаточно было бы сказать: "для ускорения работы с уникальными полями".
Если для переноса и многократного использования существующих полей функционала достаточно, то для создания уникальных полей он очень ограничен на Друпал7.
И инструмент, который я хочу использовать, это скорее мотоцикл, если его сравнить с выше предложенным изобретением велосипеда. Т.е. сейчас нужно крутить педали самостоятельно (создавать поля в UI), а я хочу чтобы это делалось специальными средствами. Я думаю, это в любом случае актуально, ведь даже при правильной архитектуре бывает, что нужно создавать новые поля.