1. Главная
  2. univerico

univerico: Комментарии

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

11 августа 2018 в 11:37

Orion76 wrote:

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

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

11 августа 2018 в 10:36

gun_dose wrote:
univerico написал:

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

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

11 августа 2018 в 9:39

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

11 августа 2018 в 9:17

gun_dose wrote:

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

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

11 августа 2018 в 9:12

gun_dose wrote:

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

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

11 августа 2018 в 9:06

gun_dose wrote:

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

Думаю все время об упрощении. На текущий момент ничего удобно импортируемого и полуавтоматически переводимого (как названия полей и термины) не приходит в голову.

11 августа 2018 в 8:51

gun_dose wrote:

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

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

11 августа 2018 в 8:47

Спасибо

gun_dose wrote:

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

А как мне тогда настроить индексирование?
Вот у меня была тема по индексированию представления

10 августа 2018 в 22:13

Orion76 wrote:

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

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

10 августа 2018 в 22:07

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

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

10 августа 2018 в 22:04

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

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

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

10 августа 2018 в 20:10

Orion76 wrote:

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

Да, про лентяев точно )))

10 августа 2018 в 20:01

Orion76 wrote:

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

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

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

10 августа 2018 в 19:48

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

10 августа 2018 в 19:21

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

10 августа 2018 в 14:17

Появились еще 3 гипотезы о путях решения (точнее две, а одна ранее предложенная gun_dose и semantics расшириалсь):
1 и 2 можно использовать вместе
Вот пример редактирвания файла features из этой статьи

7 августа 2018 в 9:16

Еще обходной вариант выключить flexslider через drush и почистить кэш и уже потом разбираться, или его чинить или аналог поставить вместо него. Можно будет хотя бы отчет посмотреть через UI.
А что в самом этом файле рядом с 387?