Я просто намекнул, тем кто еще не сделал бэкап, чтоб шли и сделали.

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

Кстати.. хостеры наверное тоже бэкапы БД делают..
Может у хостера что-то осталось..

Что-то как-то не многолюдно..
Наверное никого тема не интересует..
Или все пошли делать бэкапы.. на всякий случай.. малоличё..-)

Drupal развивается в сторону удовлетворения как можно большего числа потребностей как можно большего числа его пользователей.
А потребности пользователей это потребности "рынка".
По-моему все достаточно логично, потому как если он не будет развиваться данным образом, его популярность снизится, а значит количество развивающих его пользователей будет уменьшаться.

А что делать? Все течет, все меняется, развивается..
Когда-то "средством передвижения" было привычно и удобно управлять при помощи кнута и уздечки.
А сейчас, ишь чего удумали - рули, педали, джойстики.. и этот.. как его.. не к ночи будь помянут.. автопилот!..
А Drupal 8 стал наконец-то дружелюбнее к разработчикам модулей и т.п., не всё же только для сайт-билдеров..
Более удобная в работе и поддержке архитектура кода и данных.
Большая часть инструментов для реализации типовых задач в ядре.

Если я правильно понимаю, @vexase хочет непосредственно сам заниматься разработкой сайта, как минимум на каких-то ее первых этапах.
Я бы не сказал, что порог вхождения в разработку Drupal чересчур высок, но он и не очень низок, даже для некоего начального уровня.

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

Если сразу, в зародыше, придушить мысль о воплощения сразу в проекте самых смелых своих фантазий,
и хотя бы первое время довольствоваться необходимым и достаточным функционалом,
собранным при помощи готовых модулей из "маркетплейса", коих тысячи,
а штук 200, наиболее часто используемых, покрывают 95% потребностей достаточно "требовательных" сайтов.
Т.е. грубо говоря: если надо быстро и недорого собрать полностью работающий прототип будущего убийцы фейсбука, то Drupal 8 идеален.

почти онлайн IDE: https://www.drupal.org/project/ace_editor
про IDE пошутил, почти Notepad ++-)

Скорее всего Вам надо разобраться почему тут

протокол http

Возможно я что-то не до конца понял, но по-моему все просто и все давно придумано до нас.
По сути, как я понимаю, нужна система учета движения материальных и не очень средств в процессе взаимодействия продавца с покупателем.
Т.е. банальная бухгалтерская система.
Большинство бухгалтерских систем работают по такому принципу: каждое движение материальных средств, т.к. заказ товара, поставка товара, оплата товара, возврат товара и т.п. фиксируется "документом".
"Документ" это такая сущность, в которой храниться информация о каком-то действии.

Непосредственно для "стандартной" миграции с 7 на 8 модуль Migrate не использовал,
но судя по содержанию ошибок, наверное на сайте друпал7 есть "дополнительные" бандлы(bundle) нод (fairy, family и т.п.) с "дополнительными" полями.
И наверное для этих бандлов где-то в админке migrate необходимо добавить миграции для этих бандлов, с настройкой соответствия полей друпад7->друпал8.
Т.е. какое поле бандла друпад7 соответствует полю соответствующего бандла друпал8.

Если коротко - верстка "по Друпалу" это колхоз.

JS для друпал-фронтендера наверное можно тоже исключить, т.к.:

Где начинается логика - там и начинается бэкенд.

Каких-то 5-10 лет назад js(в основном jquery) на фронтенде в основном отвечал за поведение простеньких виджетов.
В том же bootstrap это уже в "каропке", достаточно уметь прочитать инструкцию про подключение нужного плагина (чтобы например tooltip-popup заработал или какое нибудь мегаменю и т.п.)

С другой стороны, фронтэнд сейчас это и react-vue и прочие angular-ы, и в друпал тоже..

^8([0-4]{1}[0-9]{1}|50)$ - если числа в файле по одному на строку и "целые"

если числа разделены какими либо разделителями, то необходимо добавить для них условия вместо ^ и $

проверить можно тут: https://regex101.com/

Насколько помню, feeds и migrate по принципу работы не сильно отличаются .

У обоих есть специальная таблица для хранения связи "внешнего" и "внутреннего" ID сущности.

В migrate такой проблемы нет.
Просто в конфиге миграции указываешь, что например поле товара "категория"(в xml-файле) это внешний ID категории из миграции "категории".

Все, по этому внешнему ID из таблицы связей внешних-внутренних айдишников ищется внутренний ID(tid термина категории) и подставляется в поле "категория" импортируемой сущности "товар".

Да, даже если в аргументах функции нет нужных данных, всегда можно получить url текущей страницы и все его производные (алиас, ноду и т.п.), а также текущего юзера и все его производные (роль, права и т.п.).
И на основании этих данных принять решение: заменять css или нет

пример: https://www.drupal.org/forum/support/theme-development/2011-01-27/d7-nee...

Прописать можно все, только получиться фигня какая нибудь-)

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

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

Так что css отключать проще и лучше в css_alter-)

Все правильно, "связать" одну сущность с другой можно полем типа Reference.
В списке выбора полей, для добавления в сущность, на локализованном для русского языка Drupal, этот тип (подраздел списка полей) называется "Ссылка" (пункты подраздела: Content, File, Taxonomy Term и т.п.).

Да, наверное, логичнее было бы перевести "Reference" как "Связь" или что-то подобное.

Включите отладку темы: https://www.drupal.org/docs/8/theming/twig/debugging-twig-templates

В html-коде страницы в комментариях появится инфа об использованных для генерации компонентов страницы(вьюс, строка вьюса, нода, поля ноды и т.п.) шаблонов и наименования ХУКОВ темы для соответствующих компонентов.

Обычный сайт, обычной фирмы. Ну пусть будет строительная фирма с каталогом работ. Без калькуляторов. Каталог выполненных, галерея, контакты с формой и картой.

Да сайтик, в общем, достаточно "типовой" и скорее всего нет какой-то ощутимой разницы, на чем его делать.

Когда-то ковырял Сфинкс.. прикольная штука.. У него же вроде почти SQL-совместимый язык запросов.
Т.е. теоретически можно драйвер БД для друпал написать и использовать как родной..
Руки до сих пор чешутся, но пока не актуально.

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

Т.е. скорее всего, просто немного доработать Приватные сообщения..

Я сильно ошибаюсь?-)

Да.. самое обидное, когда отвесил полю 1 048 576 байт.. а для хранения следующего значения требуется 1 048 577..
И БД напрочь отказывается его пережевать и усвоить.
(преувеличил для наглядности-))

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

/taxonomy/term/%

Это "технический" урл (роут, route) термина таксономии..
Чтобы добавить урл типа

/taxonomy/term/%/%

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

Скорее всего Вам будет проще сделать для городов и категорий один словарь таксономии в 2-3 уровня

Да, 2-3 уровень (категории-подкатегории) для разных городов будут дублироваться, зато не надо будет делать 100500 вьюсов.

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