Ускорение работы с полями и типами материалов

Главные вкладки

Аватар пользователя univerico univerico 14 июля 2018 в 11:57

Здравствуйте! Есть необходимость ускорить работу с полями и типами материалов путем экономии времени благодаря уходу от работы через UI (с заменой на импорт, либо drush команды или прямое редактирование файлов или бд), сразу уточняю, что в первую очередь интересуют решения для Друпал 7, и эта тема - это поиск специалиста для всех или одного из этих направлений:
1)перевод названий полей (предпочтительная система перевода на сайте i18n + Entity_translation )
2)создание полей
3)создание типов материалов
По drush командам на форуме предлагалась идея от
gun_dose о том, что через module_implements можно получить все имплементации hook_field_widget_info (так как сложность была именно с виджетами) и от bumble посмотреть реализацию стандартного профиля, написать свою drush-команду (или просто скрипт) по аналогии, также то, что мне удалось найти по этой теме обсуждалось на форуме в этой теме. По стоимости и срокам подробнее можно в личку или здесь.

Комментарии

Аватар пользователя univerico univerico 23 июля 2018 в 11:16

Еще рассмативаю вариант с помощью features, который был предложен gun_dose с самого начала и semantics в теме по почасовым консультациям .
И еще есть статья по Друпал 8 http://drupal8.ovh/en/tutoriels/283/create-a-field-a-node-entity-program... (возможно она натолкнет на какие-то мысли)

Аватар пользователя univerico univerico 30 июля 2018 в 10:33

Обновление:
По созданию полей задача частично решена благодаря
webpavilion, остатеся задача перевода метки поля с помощью drush и идея еще одного инструмента.
В принципе не важно, как это будет реализовано (от драш команды или настройки features до модуля для импорта полей и/или импортера импортеров), главная идея в ускорении повторяющихся однотипных настроек (частично изложена здесь, но теперь более четко уже оформлена).
Если уже пойти дальше, то вторая идея в том, чтобы это было что-то типа импортера настроек полей и импортера настроек импортера для этого типа материала и чтобы из одной таблицы брать данные и для того, и для другого:
1)и для создания полей типов материала (если это будет какая-то таблица для CSV для создания полей, то столбец с машинными именами пойдет и в следующий пункт)
2)и для создания импортера этого типа материла (эти же машинные имена можно использовать для mappings дважды:
а) и как название будущих столбцов для соответсвий с файлом источником CSV (в таблице для импорта материла нужно будет просто столбец с машинными именами сделать в 3 клика в редакторе названиями столбцов для импорта содержимого полей нод),
б)и как вторую част (то что в feeds справа) соответсвия импортера, т.е. как машинное имя конкретного поля, в которое значение из соответсвующей ячейки при создании ноды нужно подставлять).

Аватар пользователя univerico univerico 8 августа 2018 в 18:57

Обновление: сделала пример таблицы c пояснениями как я представляю себе таблицу источник (в 3 пункте опечатка, должно быть "полей")

Столбцов будет очень много. Для поиска можно обозначить начало блока нужных столбцов специальными "метками" - например для настроек терминов перед столбцами с этими натсройками создать ячейку termm, и потом находить их с помощью Ctrl+F :" termm"
Здесь пример столбцов таблицы для указания настроек второго шага для поля ссылки на термин

и

таблица источник перевода

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

На этом видео я пытаюсь объяснить как я предполагаю работать с этой таблицей

Получилось немного длинное объяснение, но на практике заполняться там будут 3-4 столбца, остальные (настройки) будут просто копироваться.
Здесь если нужно более подробное видео (но в принципе оно вспомогательное, если по 1-му понятно, то его можно и не смотреть)

Аватар пользователя univerico univerico 10 августа 2018 в 14:17

Появились еще 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 потом их брать в уже готовом виде и подставлять.

Аватар пользователя Orion76 Orion76 10 августа 2018 в 18:47

Теперь главный вопрос: А зачем все это?

Это не ирония и даже не сарказм..
Просто хочется понять, чего Вы хотите добиться в ИТОГЕ?
И как это можно (для чего-то нужно) применить на практике?

Аватар пользователя univerico univerico 10 августа 2018 в 19:21

Убрать однотипные рутинные повторяющиеся действия, которые можно автоматизировать с этапа создания полей и импортеров и желательно представлений. У меня сайт типа библиотеки с сильной каталогизацией. Много типов материала с разными полями. И нужно их импортировать. И потом еще как-то выводить представления. Если есть другие способы, то я с удовльствием их использую. Просто пока ничего другого в голову не пришло. Да, я понимаю, что я уже много дней трачу, чтобы сэкономить пол часа на создании полей типа материала и сэкономить столько же на создание импортера. Зачем разработчику сайта (я сейчас не о себе говорю, а в принципе) это делать, если можно сразу просто подгрузить файл и все готово.
В UI можно делать, когда нужно поэкспериментировать или новое полей какое-то попробовать. Если типы полей одни и те же (только метки разные) и все настройки и виджеты уже хорошо известны, то зачем тратить время в UI на это? Все равно же есть какой-то список полей и настроек перед созданиме типа материала, зачем вообще кому-то делать эти однотипные действия? Если кому-то это доставляет удовльствие, UI остается для любителей. Но точно так же как когда-то убрали однотипные действия при создании нод (создав Feeds и Migrate). Точно так же как когда-то создали Features для переноса существующих настроек, я хочу найти или создать инструмент для быстрого создания новых комбинаций настроек. Я хочу создать в редакторе типа libre office список полей, которые мне нужны в типе материала, и в автоматическом или полуавтоматическом режиме этот список превратить в поля типа материала и импортер и хотя бы заготовку для представления (или хотя бы что-то одно из этого).

Аватар пользователя adano adano 10 августа 2018 в 19:35
1

Вы в какой-то одной тематике работаете, с однотипными сайтами?
Вам профиль не проще создать и с ним работать?

Аватар пользователя univerico univerico 10 августа 2018 в 19:48

Тематика близкая в приницпе, но часто бывает необходимость создавать новые типы материала со новыми полями (метки полей абсолютно разные каждый раз, словари для терминов тоже могут быть разными).
А как профиль может помочь? Не соображе про какой профиль Вы говорите?Профиль типа дистрибутива Вы имеете ввиду или типа features? не пойму?
Но порфиль же для перенеса имеющегося на разные сайты. Да, бывает приходится выносить что-то на отдельный домен, но в основном на одном сайте новое нужно добавлять, т.е. смысл не в том чтобы с одного сайта на другой переносить, а чтобы на новые поля, типы материала и импортеры быстро создавать.

Может хотя бы для Друпал 8 есть такой инструмент?

Кстати еще и словари удобно было бы создавать.
Есть generate-vocabs но пока dev и только количество можно указать про имя ничего не вижу.

Аватар пользователя Orion76 Orion76 10 августа 2018 в 19:45
1

Знакомо..
Сам терпеть не могу рутинные операции и частенько с огромным удовольствием трачу недели рабочего времени чтобы сэкономить 15 минут в год, а то и всего 15 минут-)))

univerico wrote:

Если типы полей одни и те же (только метки разные) и все настройки и виджеты уже хорошо известны, то зачем тратить время в UI на это?

Тут скорее всего дело не в друпале , а в архитектуре данных Вашего приложения.
Значит как-то их можно организовать проще, чтобы не дублировать постоянно одни и те же сущности.

В drupal 8 эти проблемы, в немалом своем объеме, решены..
Про drupal 7 вспоминаю с доброй ностальгией о молодых годах и ужасом(в сравнеии с drupal 8)-)

Вашу бы энергию, да в мирных целях-)

Кстати, еще в 2011 один участник данного форума написал такой модуль: https://www.drupal.org/project/bundle_inherit

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

Согласитесь, этот подход "немного" оптимальнее Вашего. И требует на несколько порядков меньше усилий.. Как раз для нас - убежденных радикальных лентяев-)

Это если Вам надо далее развивать проект на drupal 7,

А для новых проектов настоятельно рекомендую погрузиться в drupal 8

Аватар пользователя univerico univerico 10 августа 2018 в 20:01

Orion76 wrote:

Тут скорее всего дело не в друпале , а в архитектуре данных Вашего приложения.

Значит как-то их можно организовать проще, чтобы не дублировать постоянно одни и те же сущности.

Спасибо. Думаю об этом. Чтобы типы материала и поля на что-то заменить. Но пока никаких мыслей.
Представьте, что у меня тип материала, например, музыкальная тональность
там поля типа (обозначение, ступени, опевание и т.д.) -ссылки на термин и
рядом с каждым поле изображения. Как это можно другой архитектурой сделать?
Терминами разве только. Но чтобы все вместе тогда представления, а я хочу статичные делать страницы для более прозрачного индексирования.

Аватар пользователя gun_dose gun_dose 10 августа 2018 в 21:02
1

А чем у вюьсов индексирование не прозрачное? Сколько у вас уже есть суммарно полей и типов материала на сайте? Надеюсь, вы понимаете, что чем их больше, тем сложнее сопровождать такой сайт?

Аватар пользователя univerico univerico 10 августа 2018 в 22:04

Спасибо за ответ.

gun_dose wrote:
А чем у вюьсов индексирование не прозрачное?

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

gun_dose wrote:
Сколько у вас уже есть суммарно полей и типов материала на сайте?

Ну в основном пока заготовки для импорта. Полей в каждом типе 15-30. Я могу если что сделать мультисайтинг и на отдельные домены вынести разные типы материалов.
Так чтобы было по 10-15 типов материалов не более.

gun_dose wrote:
Надеюсь, вы понимаете, что чем их больше, тем сложнее сопровождать такой сайт?

В чем сложность?

Аватар пользователя gun_dose gun_dose 10 августа 2018 в 22:31
1

Вьюс не может не проиндексироваться. Поисковикам вообще плевать, вьюс это, нода или термин таксономии. И всё равно непонятно, зачем столько полей и столько типов материалов. Можете привести пример двух типов контента со списками их полей?

По поводу сложности: у ноды нельзя поменять тип, а когда типов становится несколько десятков, то контентщик может ошибиться и создать ноду не того типа, а потом придётся пересоздавать.

Второе: вы не подумали об упрощении структуры, в результате создали уже который топик на форуме, где пытаетесь изобрести велосипед для этой обезьяньей работы.

Потому я и предлагаю вам описать то, что должно получиться в итоге, чтобы форум коллективным разумом смог помочь вам подобрать инструмент для реализации.

Опять же уверен, что paragraphs и double_field помогли бы сделать вашу структуру намного более компактной.

Аватар пользователя Semantics Semantics 10 августа 2018 в 22:52
1

Тут, вероятно, нужно смотреть в сторону EAV или properties.
Ибо таблиц в БД уже поди под тыщу, а нужны все филды практически разово.

Аватар пользователя univerico univerico 11 августа 2018 в 9:06

gun_dose wrote:

Второе: вы не подумали об упрощении структуры, в результате создали уже который топик на форуме, где пытаетесь изобрести велосипед для этой обезьяньей работы.

Думаю все время об упрощении. На текущий момент ничего удобно импортируемого и полуавтоматически переводимого (как названия полей и термины) не приходит в голову.
А несколько тем, ну это наверное тоже тяга к каталогизции, вот представьте кто-то хочет научиться пользоваться drush filed clone, а у меня все про это в этой текущей теме и вынужден человек читать весь этот топик. Я стараюсь тему выделять отдедльно когда какой-то узкий аспект выделяется, который может кому-то пригодится и всегда делаю ссыки на близкие. И по самой сути как раз обеъзянью работу хочу убрать, обезьянья работа, это когда каждый человек в поиске чего-то перелопачивает кучу информации и его труд потом повторяют еще тысячи люде заново. Пока поисковики лучше всего индексируют текст и пока заставить авторов , например, видео, подробно проставлять теги невозможно, а youtube не довел до совершентсва распознавание содержимого видео, ручная каталогизация на мой взгляд актуальна. К тому же у меня не только для каталогизции это нужно. Просто на текущий момент основная задача.

Аватар пользователя univerico univerico 11 августа 2018 в 9:12

gun_dose wrote:

Опять же уверен, что paragraphs и double_field помогли бы сделать вашу структуру намного более компактной.

Спасибо. paragraphs подумаю, как прикрутить. double_field упростил бы задачу, но типы полей не те, да и потом могут возникнуть сложности с разделением в результатах поиска или представления. В моем случае это не совсем единые и не всегда парные поля. Но спасибо для других случаев буду иметь ввиду.

Аватар пользователя univerico univerico 10 августа 2018 в 20:10

Orion76 wrote:

Согласитесь, этот подход "немного" оптимальнее Вашего. И требует на несколько порядков меньше усилий.. Как раз для нас - убежденных радикальных лентяев-)

Да, про лентяев точно )))
Если тот модуль типа bundle clone (клонирует имеещийся тип материала) то все равно, тогда проще командой драш клонировать поле с нужными настройками и новым машинными именем и переименовать просто метку потом или допилить команду, чтобы и метку сразу менять.
Если модуль позволяет как в tamper что-то пакетно добавить, то это то, что нужно.
А если нет, то мой способ требует больше усилий для создания этого нового инструмента, но меньше усилий потом в работе.
Буду изучать bundle_inherit и думать о переходе на 8.
А что из этого можно делать на 8?

Аватар пользователя Orion76 Orion76 10 августа 2018 в 20:12
1

Направление мыслей правильное..
Не помню кто сказал, но я с ним полностью согласен (возможно не дословно): Если вы делаете что-то слишком сложно, значит вы что-то не так делаете.

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

Аватар пользователя univerico univerico 10 августа 2018 в 22:07

Orion76 wrote:
: Если вы делаете что-то слишком сложно

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

Аватар пользователя Orion76 Orion76 10 августа 2018 в 20:20
1

А что из этого можно делать на 8?

например просто написать список команд drupal-console, которые оперируют создаваемыми сущностями, в shell-скрипт , и при необходимости его запускать (с динамическими аргументами).

Все сущности (и многое-многое другое) в drupal 8 - это простые текстовые конфигурационные файлы.
Которые можно написать вручную
Которые можно сгенетировать программно
.. далее по степени испорченности

и потом з-агрузить в нужный проект..

достаточно?-)

Аватар пользователя univerico univerico 10 августа 2018 в 22:13

Orion76 wrote:

например просто написать список команд drupal-console,

Спасибо. Это что-то типа создания совей drush команды?
Это проще сделать чем комнаду для драш создать?
Ну у меня есть сайт (типа моего блога) на восьмерке, но он голый почти и я потому что копаюсь с 7 все время ни composer ни drupal-console пока не могу освоить. Но придется, наверное.
Quote:
в shell-скрипт

Это как?

Аватар пользователя univerico univerico 10 августа 2018 в 22:14

Orion76 wrote:

Если будет необходимость, пишите в личку, свяжемся более удобным способом, чем смогу - помогу

Спасибо.

Аватар пользователя univerico univerico 11 августа 2018 в 8:47

Спасибо

gun_dose wrote:

Вьюс не может не проиндексироваться. Поисковикам вообще плевать, вьюс это, нода или термин таксономии. И всё равно непонятно, зачем столько полей и столько типов материалов. Можете привести пример двух типов контента со списками их полей?

А как мне тогда настроить индексирование?
Вот у меня была тема по индексированию представления
Если для закрытия идут rel="nofollow" + canonical
Quote:
на вьюсах и фасетах это должно работать из коробки

Как оно там работает именно во views?
На что оно будет ссылаться?
На разнозненные термины? А если я хочу, чтобы именно определенное сочетание проиндексривалось?
Но представления я открывать для индекса не хочу так как будет много похожих.
Quote:
Можете привести пример двух типов контента со списками их полей

По факту то что нужно сделать это смесь научного исследования с одновременным представлением его online (просто удобного обзора) и результатов ручной сортировки сведений
(либо систематизации) для более удобного поиска того, что часто используется.
Так как сейчас делаю поля по музыке напишу пример по музыке (сразу чтобы не было впросов про то, что такие сайты уже есть пишу подробно, что таких как мне надо нет, и что да моя задача очень узкая, но результат - сайт с возможностью остортировать потом что-то по определенному признаку может быть полезен исследователям в этой области и тем кто просто учится чему-то). Ну, например я учусь играть на гитаре или скрипке и захотела поиграть гаммы и изучить по очереди все основные тональности, определяю какие там тоника, доминанта, субдоминанта, учусь строить трезвучия главных ступеней для этой тональности, слушаю произведения в этой тональности или мне интересен феномен цветового слуха, хочу понять как общие особенности есть у восприятия звука и у цвета и вообще может быть как мы воспринимаем мир (ну вот например я случайно выяснила что один из моих любимых аранжировщиков современных ноты не только слышит но и "видит" и что разные композиторы с цветовым слухом немного по разному "видели" ноты, и мне стало интересно, послушать все произведения в определнных тональностях и почувствовать ассоциации с какими цветами у меня они вызовут, нужно просмотреть пару сотен роликов на youtube, чтобы найти нужное и я хочу потом этот результат выложить, если кто-то потом будет искать то сможет быстро найти то, что нужно. Представьте, что книги в библиотеке содержат подпись только названия произведения или только автора, а Вы открыли многие книги и знаете и то, и другое, и перед тем как закроете, хотите подписать недостающую инфомацию в каталоге хотя бы для части книг) Или второй момент (фрагментароность некторых данных в обучающих материалах). Например начинаю с До мажор и получается что сайтов очень, очень много и очень объемных, но одна инфорация на одном сайте, другая на другом, третья на третьем или есть учебник по музыке и там для примера приведены несколько главных ступней для некторых тональностей, а сводной таблицы для всех тональностей для этих ступней во многих учебниках нет (предположим ну или какой-нибудь другой таблицы нет). Или хочу найти произведения опредленного автора в опреденной тональности на определенном инструменте, а произведения в youtube часто содерсодержат например одно "Название призведения, имя автора и тональность"(классические) либо "Название и инструмент". А мне нужно сделать такой каталог, чтобы там по определенным темам все было в одном месте полно и под рукой.
Напимер Тип материала 1 "Тональность"
Поля: название (title), обозначения (термин) Все ступени (прим. ред. ноты) тональности (термины и изображение), дальше ступени по отдельности со специфическими названиями типа тоники 1 ступень (тоника) (термин того же слвоаря или мультиродители), 2 ступень (термин)...7 ступень (термин)
уже 11 полей и это только треть
Пример содержания полей: До мажор; C, Сdur; до, рем, ми ...си; изображение; до, ре, ми и т.д.
Самих материалов такого типа будет для начала 42.
Т.е. каждое название поля повторится 42 раза и поэтому мне удоно перевести его один раз.
Также мне нужно подставить автоподстановкой в непереводимое поле и перевод терминов (которые я тоже хочу первести один раз) содержимого полей.
В разные поля выделяю, чтобы перевод полей делался один раз.
Мне нужно чтобы проиндексированлось именно
заголовок: "До мажор" и на той же странице слово "1 ступень тоника"(из названия поля" и рядом с ним - "до"

2 тип материала "Музыкальное призведение"
И там у него полей 10
(Заголовок, тональность (сслыка на термин), инструмент (термин), видео (embeded field, исполнитель (термин)). И потом некторые произведения еще будут полем (ссылкой на сущность) для типа материала тональсти. А остальные подборки (например по атвору и инструменту) уже представлениями.

Аватар пользователя univerico univerico 11 августа 2018 в 8:51

gun_dose wrote:

то контентщик может ошибиться и создать ноду не того типа, а потом придётся пересоздавать.

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

Аватар пользователя univerico univerico 11 августа 2018 в 9:10

gun_dose wrote:

А ещё бывает, что от половины полей можно отказаться, просто нормально настроив ckeditor ?


А как импортировать тогда?

Аватар пользователя univerico univerico 11 августа 2018 в 9:39

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

Аватар пользователя gun_dose gun_dose 11 августа 2018 в 9:11
1

???
По поводу rel=nofollow - естественно, имелось в виду закрытие параметрических ссылок - фильтров и пейджеров. А сами вьюсы всегда нормально индексируются

univerico wrote:

И потом некторые произведения еще будут полем (ссылкой на сущность) для типа материала тональсти.

Это неправильно. Произведение должно ссылвться на тональность, а тональность на произведение не должна. Список произведений на странице тональности должен выводиться блоком вьюс с контекстным фильтром. Банальная логика - когда кто-то сочиняет произведение в ля-миноре, ля-минор остаётся ля-минором и никак сам по себе не меняется.

Аватар пользователя univerico univerico 11 августа 2018 в 9:17

gun_dose wrote:

По поводу rel=nofollow - естественно, имелось в виду закрытие параметрических ссылок - фильтров и пейджеров. А сами вьюсы всегда нормально индексируются

Т.е. если у меня будут, например, представления:
"Все произведения автора", потом "все произведения его для какого-то инструмента", потом "его же произведения в какой-то тональности", то как это все проиндексируется?

Аватар пользователя univerico univerico 11 августа 2018 в 9:31

gun_dose wrote:

Банальная логика - когда кто-то сочиняет произведение в ля-миноре, ля-минор остаётся ля-минором и никак сам по себе не меняется.

Я знаю одного профессионального исполнителя, который считает что нельзя исключить, что исполнение произведения может менять само произведение, причем исполнитель классической музыки, т.е. он не делает "каверов" (ну что-то типа информационного поля), нужно поинтересоваться, что он думает о влиянии произведения на тональность )))
Я предполагаю что может быть еще что-то типа гравитации и взаимного влияния. Как с луной и Землей.
А если серьезно, то как мне тогда вывести примеры произведений в тональности, если исходить из того, что это тип материала?
Может тогда просто выбрать 3-4 вручную и доюавить в поле (встроенного видео)? Или Вы думаете лучше сделать тональность термином с 30 полями и выводить в представлении вместе с произведениями?
Я просто предполагаю, что в конце всех полей тональности будет типа анонса из 3-4 произведений c ссылкой на представление по произведениям или как-то фасеты прикрутить.

Аватар пользователя univerico univerico 11 августа 2018 в 10:36

gun_dose wrote:

univerico написал:

И потом некторые произведения еще будут полем (ссылкой на сущность) для типа материала тональсти.

Это неправильно. Произведение должно ссылвться на тональность, а тональность на произведение не должна.


Я имею ввиду, что в типе материала хочу сделать поле с типом "ссылка на сущность", чтобы представить примеры произведений в тональности, а не что сам заголовок т.е. сама "тональность" будет ссылкой на произведение.
Т.е. просто для названия тональности я хочу сделать словарь без доп полей.
А потом сделать тип материала и импортировать уже информацию о тональности нодами определенного типа материала. А произведение будет иметь поле ссылки на термин (из словаря "Тональность"). У меня вопрос скорее по тому делать ли тип материала "тональность" отдельный или добавлять поля к термину"тональность".
Я просто уже не могу отследить историю применения терминов. Сначала их использовали как теги просто? Потом решили объединить и ноду и тег в одно (и для этого добавили поля к термину) и при необходимости решили их разделять, просто не выводя поля? Или наоброт короткий тег, который является только тегом это более продвинутая форма? Или как там обстояло дело? Какая логика выбора?
В принципе нет смысла наверное делать еще и тип материала если можно добавить поля к термину, но с другой стороны а вдруг где-то потом в каком-то модуле не будет средств отделить поля от заголовка и нужен бутет только заголовок, тогда можно будет использовать чистый термин.

Аватар пользователя Orion76 Orion76 11 августа 2018 в 10:52
1

Блин.. понял в чем проблема-)
@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 - при написании длинных текстов на форуме, и упрощении их прочтения и понимания собеседниками, тексты лучше, как минимум, разбивать на параграфы (по смыслу и т.п.), а еще лучше, давать разделам поста заголовки-подзаголовки.
А то пишите-пишите, стараетесь-стараетесь, а прочтут Ваш пост не все, а кто прочтет - или не поймет, или поймет не правильно-)

Аватар пользователя Orion76 Orion76 11 августа 2018 в 11:00
1

univerico wrote:

Цитата:

в shell-скрипт

Это как?

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

В windows это bat-скрипт
В linux (обычно серверная ОС web-сервера) это bash-скрипт

Аватар пользователя univerico univerico 11 августа 2018 в 11:40

Orion76 wrote:

Блин.. понял в чем проблема-)...
есть модуль ECK ( https://www.drupal.org/project/eck )

Если установить модуль Inline Entity Form ( https://www.drupal.org/project/inline_entity_form )


Спасибо большое! Очень интересно. Постараюсь приспособить под свои задачи и в любом случае пригодится.

Quote:
причем drupal-console интерактивна

Для меня интерактивная комнада это почти то же что и UI. Мне удобнее изучить сразу возможности команды, сделать заготовку (потому что иначе куча очепяток) или алиас и использовать ее.
Quote:
ЗЫ. при написании длинных текстов на форуме, и упрощении их прочтения и понимания собеседниками, тексты лучше, как минимум, разбивать на параграфы (по смыслу и т.п.), а еще лучше, давать разделам поста заголовки-подзаголовки.

Учту)) Наверное есть какая-то спешка сложность на этапе перевода из мыслей в текст, еще одно подтверждение, что множество полей, это как раз для меня, тем более с такой структурой и поиск потом такой будет более удобным. Видимо потому и создаю темы отдельные (отчасти интуитивно), чтобы это читать было удобнее. Учитывая общие замечания, буду писать в одной теме, но с параграфами и рубриками)))

Аватар пользователя univerico univerico 11 августа 2018 в 11:37

Orion76 wrote:

Вы оказывается все делаете на нодах -)) (один тип материала: node и куча его бандлов (bundle))

Да, под типами материала имеются ввиду типы материала в териминологии админки.

Аватар пользователя Orion76 Orion76 11 августа 2018 в 11:46

univerico wrote:

В смысле? В Друпал 7 тоже же из коробки? Или вы имеее ввиду что файлами можно?

В 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 - добавления-настройки полей к сущности.

Аватар пользователя univerico univerico 11 августа 2018 в 12:27

Orion76 wrote:

есть модуль ECK ( https://www.drupal.org/project/eck )

Позволяет мышкой накликать любое кол-во необходимых типов материалов

у каждого типа материала отдельная таблица БД

К типу материала можно добавить необходимые property (поля , которые хранятся в таблице типа материала

и наследуются бандлами этого типа, например как в node: title, created, updated, publiched и т.п.)

После изучения возможностей все же предположение, что этот модуль хоть и очень полезный, но мою задачу не решает полностью.

Если бы у меня был шаблон, который нужно было бы немного видоизменять, то да, это было бы решением.
Но
1)у меня почти везде метки полей разные и словари разные для терминов.
2)вопрос: там же все равно надо накликивать поля при первичном их создании хоть для сущности - properties, хоть для bundle -fields ? не могу найти, как с помощью него можно первично создавать много полей быстрее, чем обычным способом?
Придется, наверное пока пытаться допилить добавление метки к field clone и клонировать поля одного типа внутри каждого bundle.

Quote:
Если установить модуль Inline Entity Form (

Благодаря тому, что удалось его протестировать в commerce kickstart, где он прямо очень удачно влит и использую его. Интересно будет протестировать теперь в связке с ECK.

Аватар пользователя gun_dose gun_dose 11 августа 2018 в 12:30
1

Прелесть кастомных сущностей в том, что добрая половина хэндлеров для вьюсов к ним попросту отсутствует, и поэтому то, что можно накликать на нодах, приходится кодить. Кто плотно работал с коммерс в восьмёрке, тот поймёт о чём я.

Аватар пользователя gun_dose gun_dose 11 августа 2018 в 12:33
1

univerico wrote:

то как это все проиндексируется?

У страницы есть урл, заголовок и какой-то текст на ней. Вот так и проиндексоруется.

Аватар пользователя univerico univerico 11 августа 2018 в 12:55

Orion76 wrote:

univerico написал:

В смысле? В Друпал 7 тоже же из коробки? Или вы имеее ввиду что файлами можно?

В 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 - добавления-настройки полей к сущности.


Ясно. Спасибо за пояснение.
Все что выше у меня тип материала = bundles для нод,
а то что в этой терминологии тип материала у меня выше "сущность" = нода, таксономия, юзер, файл и т.д.
Далее тогда буду вместо "типа материала" лучше писать "bundles", как раз ближе к drush терминологии и к коду Друпал.
С термином "тип материала" наверное из-за перевода так получается,
и conent types и entity types так первеодят, да?
На всякий случай не буду использовать, буду писать "тип сущности".
Так можно?

Аватар пользователя univerico univerico 11 августа 2018 в 13:00

gun_dose wrote:

то, что можно накликать на нодах, приходится кодить


Но то что можно накликать для представлений для нод на Друпал 8 можно кодить или делать файлами, верно?

Аватар пользователя gun_dose gun_dose 11 августа 2018 в 13:28

Немного не так. При работе с кастомными сущностями часть стандартного функционала нужно писать самому.

Аватар пользователя univerico univerico 11 августа 2018 в 13:02

gun_dose wrote:

У страницы есть урл, заголовок и какой-то текст на ней. Вот так и проиндексоруется.

Quote:
закрытие параметрических ссылок - фильтров и пейджеров. А сами вьюсы всегда нормально индексируются

Спасибо. А можно подробнее, что именно будет закрыто и как пейджеры будут закрыты?
Где почтитать про это?

Аватар пользователя Orion76 Orion76 11 августа 2018 в 13:43

univerico wrote:

После изучения возможностей все же предположение, что этот модуль хоть и очень полезный, но мою задачу не решает полностью.

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

Аватар пользователя univerico univerico 11 августа 2018 в 14:43

Спасибо.

Orion76 wrote:

Я думаю, Вам надо просто правильно спланировать структуру данных приложения.

Правильно спланированная структура данных на порядки упрощает разработку, а в последствии - поддержку и расширение проекта.

А какие еще могут быть более правильные (хотя бы с точки зрения скорости создания структуры) варианты?
Я пока для Друпал 7 вижу только три варианта:
1)Делать bundle нод
2)Делать Терминами таксономии с полями словаря
3)Делать типами сущностей
+ еще изучу EAV и properties.
Везде свои плюсы и минусы, но везде новые поля и их настройки нужно кликать и ни один из способов не решает проблему создания большого числа полей и настроек потом под это Feeds/Migrate, Views.
Остается только делать специальный импортер полей и импортеров или из имеющегося, формулы редактора и drush fields clone или Drupal 8.

Аватар пользователя Orion76 Orion76 11 августа 2018 в 16:12

univerico wrote:

А какие еще могут быть более правильные (хотя бы с точки зрения скорости создания структуры) варианты?

Чтобы ответить на этот вопрос, необходимо знать: что, из чего и зачем делает Ваше вэб-приложение.

Аватар пользователя univerico univerico 11 августа 2018 в 17:05

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

Но возможно стоит сделать более четкое описание как часть ТЗ, если не понятно, то что там написано.

Задача создать каталог, в котором будут типы элементов (например музыкальные тональности, видеозаписи исполнений музыкальных произведений, мастерклассы по скрипке) и признаки (например для первого музыкальные ступени тональности, трезвучия тональностей; для второгоинструмент, на котором произведение исполнено, исполнитель и др).

Ну или если взять в примере того, что часто делается на сайтах (интернет магазин электроники - у меня другая тематика на самом деле но принцип я думаю похожий), то пример такой: буду писать элемент и в скобках признаки, потом пример:
телевизор (диагональ, фирма производитель, тип дисплея)
20, Philips, жк

фен (модщность, фирма производитель, возможность регулировки температуры)
2000, Philips, есть
У каждого типа элементов свой набор признаков.
Чтобы потом можно было найти все элементы с определенным набором признаков
Я предполагаю что типы элементов можно делать с помощью
1)bundle нод
2)словарей или терминов
3)типов сущностей

Для каждого признака создавать отдельное поле.

А значения для каждого признака заносить в определенные поля.

Потом фасеты или представления.

Плюс многоязычность.

Хотя я думаю все же в сторону того, что у меня действительно немного специфическая задача, но все же мне действительно нужен именно такой инструмент, как я описываю.

Аватар пользователя Orion76 Orion76 11 августа 2018 в 20:59
1

univerico wrote:

Но возможно стоит сделать более четкое описание как часть ТЗ, если не понятно, то что там написано.

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

univerico wrote:

Ну или если взять в примере того, что часто делается на сайтах (интернет магазин электроники - у меня другая тематика на самом деле но принцип я думаю похожий), то пример такой: буду писать элемент и в скобках признаки, потом пример:

телевизор (диагональ, фирма производитель, тип дисплея)

20, Philips, жк

По сути получается некая сущность с набором характеристик, назовем характеристику аттрибутом сущности, коих у нее может быть неограниченное количество.

По сути, структура аттрибута проста:
1.Наименование аттрибута
2.Значение аттрибута

Например сущность:телевизор
аттрибуты:
- наименование: диагональ, значение: 40 дюймов
- наименование: фирма производитель, значение: Philips
- наименование: тип дисплея, значение: ЖК

т.е. само собой напрашивается аттрибут сделать сущностью с 2-мя полями:
1.Наименование аттрибута
2. Значение аттрибута

А родительской сущности просто добавить многострочное поле Аттрибуты, типа entity_reference на сущность Аттрибут

Типов аттрибутов можно сделать любое необходимое кол-во.
Например некоторые аттрибуты могут иметь строго определенные наименования (поле Наименование аттрибута)
Следовательно, создаем для списка наименований словарь таксономии, в котором будут содержаться все возможные наименования аттрибута.
И естественно, поле Наименование данного типа аттрибута делаем ссылкой на термин данного словаря.

Другой тип аттрибутов может иметь произвольное наименование, следовательно в нем поле Наименование должно быть простым текстом.

Другой тип аттрибута может иметь определенное наименование из предопределенного списка, и списко возможных значений.
Для него можно сознать 2-х уровневый словарь таксономии, первый уровень которого будет соответствовать Наименованию аттрибута, а второй уровень: списку возможных его значений.

и т.д. и.т.п.

Получается, Вам необходимо не бесконечное кол-во полей-характеристик, а всего лиш одно, типа entity_reference, ссылающееся на несколько типов сущностей-аттрибутов.

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

Аватар пользователя univerico univerico 11 августа 2018 в 22:51

Спасибо большое! Я обязательно все очень внимательно проанализирую и постараюсь сопоставить этот пример со своей задачей (у меня особенность, которая накладывает ограничение на такую архитектуру при первом взгляде – что значение атрибутов у меня часто складываются из нескольких терминов таксономии и еще некоторых типов полей, и мне нужно потом иметь возможность выводить это все в поиске по отдельности, т.е. мне нужно сначала вникнуть в варианты выведения этого потом с помощью views или фасетов и посмотреть, не будет ли там ограничений) и в любом случае такой способ может пригодиться для других проектов.

И точно можно использовать хотя бы частично в этом. Для произведений, которые я хотела помещать в поле типа ссылки на сущность в тональности, как раз подходит такая архитектура. По другим более сложным нужно пробовать. Короче, нужно попробовать и посмотреть на практике.

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

Если для переноса и многократного использования существующих полей функционала достаточно, то для создания уникальных полей он очень ограничен на Друпал7.

И инструмент, который я хочу использовать, это скорее мотоцикл, если его сравнить с выше предложенным изобретением велосипеда. Т.е. сейчас нужно крутить педали самостоятельно (создавать поля в UI), а я хочу чтобы это делалось специальными средствами. Я думаю, это в любом случае актуально, ведь даже при правильной архитектуре бывает, что нужно создавать новые поля.