Я бы не стал судить, тем более не владея всей информацией (как минимум:"что там предыдущие намутили")

Как-то вот так вот "встрял" по самые ноздри.
Подвернулся заказ в каталоге статей добавить несколько разделов в иерархию каталога.
На первый взгляд сайт банальнейший иерархический каталог статей на таксономи-меню.
пару десятков "разделов" первого уровня и по десятку второго-третьего.

Ну думаю, сейчас в админе в словарь нужные разделы добавлю и готово.
А не тут-то было.
Предыдущие такого намутили!

Скорее всего просто перестраховывается, чтобы не "сломать" работающий сайт.
Чтобы программисты не боялись вносить изменения на работающий сайт, в плюс к предыдущему комменту, нужен еще отдельный сервер для доработки-тестирования сайта. (dev-server)
Это аксиома.
Да и Ваши нервы будут целее-)

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

А еще далее все уже будет зависеть только от Вашего желания и целеустремленности-)

Можно, но нудно..

самый простой вариант - добавить специальный тип материала, назовем его proxy.
В него добавить одно поле (текст или целое число) для хранения ID записи из данной таблицы.
Лучше какое-то кастомное с индексом в БД (для оптимизации поиска по данному полю)

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

к нему же добавляем и Flag.

схема БД: https://www.drupal.org/node/1785994

Перевод:

Webform не является конкурентом или заменой CCK.
Он предназначен для использования там, где каждый материал(сущность) веб-формы получает свой собственный набор настраиваемых полей.

Это отличается от подхода CCK, где он создает формы типов контента, которые создают материалы.

Последнее время замечаю какую-то нездоровую "любовь" к модулю webform.
С чего бы это?
Он бесподобен для решения тех задач, для которых он был задуман.
Использование его во всех других "неподходящих" случаев вызывает сомнения

А вообще, основная "фишка" Drupal и других подобных систем - это сущности с полями .
Вся "инфраструктура" таких систем построена вокруг этих "сущностей ", предоставляя 99% функционала, востребованного в вэбе.

А вэб-сервер в логи по этому поводу что пишет?

А чё делать? селяви же..

Буквально недавно на одном проекте, дизайн интернет-магазина делала жена заказчика, которая в это время доучивалась с какого-то офлайн-дизайнера на дизайнера web-интерфейсов.

Тоже подобные "косые" элементы вэб-страницы: горизонтальные меню из кнопок-паралеллограммов и подобные же кликабельные блоки с иконками и многострочным текстом.

Я принципиально не специализируюсь на верстке, особенно "специфичной", но для хромов и файерфоксов получилось сделать без проблем.

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

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

Скорее всего и писать дополнительный код совсем не придется.

Ну или как минимум будет понятно как и где это сделать правильно.

это не нода, а iframe c http://sabre.aviabilety.com/ru/

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

поищите в папке темы оформления файл - page-front.tpl.php
его может не быть, тогда все намного хуже, но не стоит отчаиваться-)

скорее всего в нем выводятся табы с iframe на главной странице.

Ну это просто один из вариантов сделать "генерацию" docx-файлов без лишних библиотек, так сказать, только силами drupal-ядра.
Хм.. возможно мне скоро пригодиться..-)

bumble wrote:

docx - это набор отборнейших XML-файлов, написанных машинами, для машин.

Зловеще звучит-)

Что, машины вот так взяли и всё сами написали?-)

А что там не банального, теги они и в Африке теги..-)

даже не так - текст он и в Африке текст.

• Распаковываем docx-шаблон в специальныю папочку.
• из xml-файла с контентом делаем twig-шаблон
• при запросе ноды в docx-формате прогоняем twig-шаблон через twig-"движок" .
• из "вывода" шаблона и остальных xml собираем обратно docx
• отдаем его браузеру

Даже наверное twig-конструкции вывод переменных ( {{name}} и т.п. можно будет прямо в docx-шаблоне вставлять в нужные места-)

"распарсить" шаблон какой либо библиотекой для работы с docx-форматами документов.

А вообще, docx - это банальный xml определенной структуры, завернутый в zip.

теоретически, можно на базе подобного документа сделать twig-шаблон для нужной ноды.
заполнять его стандартно и отдавать браузеру завернув в zip.

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

если не подойдет как решение, поработает "примером": https://www.drupal.org/project/views_autocomplete_filters

для автогенерации алиасов url необходимо настроить модуль pathauto: https://niklan.net/blog/19

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

Тогда, имхо, как раз логичнее и практичнее оставить только связь "фото" -> "альбом"

"фото" же связано с "участником" (наверное стандартное поле "автор")?

Останется только добавить к сущности "альбом" псевдо-поля ссылки на ссылающиеся на них фото и пользователей-участников

примеры модулей для "обратной связи" на drupal.org есть.

VasyOK wrote:

P.S. Как вы перевод Дупала делали? Специально посмотрел на своих украинских сайтах. У меня не так!

Наверное этот модуль: https://www.drupal.org/project/l10n_update

На админ-странице списка всех вьюсов есть вкладка Настройки
Там можно включить отображение SQL-запроса на странице настройки каждого вьюса.

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

Max-Z wrote:

Пользователь может создавать в Друпал албомы, а из React он может добавить фото сразу в несколько альбомов:

Хм.. если я правильно понял суть, "альбом" это сущность с "многострочным" полем типа entityreference на сущность "фото"?

Я бы с удовольствием "помог".
Но не уверен, что "результаты" моей "помощи" будут использованы по назначению.
С предыдущими попытками "помочь" именно так и произошло.
Если ничего не изменилось, то не вижу в дальнейших попытках никакого смысла.

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

Так же эти метки можно организовать в иерархическую структуру.
На базе этих "иерархических" меток удобно организовывать структуру страниц-разделов сайта.

Самый простой , достаточно распространенный, случай:

1.Создается "основной" иерархический словарь таксономии, содержащий "метки" для разделов-подразделов сайта.

2.На базе этого словаря генерируют иерархическое меню основной навигации.

Да чего там гадать, это "основы", т.е. стандарты.
Но в общем то можно даже и без них.
Надо представить, что мы "блондинки" и только что нагуглили ссылку drupal.ru/tracker про какую-то CMS Drupal.
Заходим на нее самый первый раз.

Представили?

И что мы тут видим.
Таблица текста с какими-то иконками.
Что значит текст в этой таблице и иконки? Непонятно..

О, мой профиль использован для примера!
Я не заслуживаю такой чести-) Ну да ладно..

На UX еще поработать надо..
Да вы и сами наверное понимаете над чем..

Аа.. я думал в процессе оформления заказа Клиент должен как-то "интерактивно" дополнить заказ.
А Вам надо просто по своему организовать процесс дальнейшего "дооформления" заказа.

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

Т.е. у заказа есть специальные поля: состояние (state) и статус (status)

https://drupalcommerce.org/faq/order-states