"Потом я всё бросил и написал с помощью ИИ скрипт загрузки" - ужас.

Видимо такие текущие реалии наступают с ИИ

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

При разработке лучше полностью отключить кеширование статики и twig шаблонов.

В файле development.services.yml пишем это:

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

Если использовать функции друпала для работы с материалами, то описанные проблемы не важны. Если в гугле вбить "drupal 7 get nodes by type", то ИИ гугла сразу выдает готовый код для получения материалов. Вы же сделали скрипт или скачали и разобрались в нем, тот, который тестирует подключение к базе. Получение и сохранение материалов в друпале не сложнее будет)

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

1. На сервере, где mysql 8 поднял бы базу от друпал 7. Чуть выше в комментариях я про это описывал.
2. В конфиге settings.php подключаем использование 2 баз. Примерно так:

Про папку web имел ввиду вот такую структуру каталогов в папке сайта - скриншот. Если у вас так же, то ngnix нужно указать смотреть в папку web.

"...Про нестандартное название сокета, не поняла..."
Тут мне сложно понять, я с FastPanel не работал. Но там общий принцип для сайтов. В конфигурации ngnix, адрес сокета должен быть такой же, как в конфигурации php-fpm.

С чем у вас связано не стандартное название сокета?
--> fastcgi_pass unix:/var/run/test.ru.sock;

У вас в папке домена есть папка "web"? Если да, то настройте, что бы ngnix в нее смотрел. Вот так:
--> set $root_path /var/www/test_xx_usr/data/www/test.ru/web;

Бывают сборки друпала, где содержимое в папке web, а вендорные библиотеки не в ней.

Когда перезапускаете процесс php-fpm, то потом перезапустите ngnix. Почему-то бывает, что ngnix потом не корректно подхватывает php-fpm процесс.

Если у вас связка Ngnix + php-fpm, то в конфиги ngnix для вашего сайта укажите, какую версию php использовать. Это делается через "fastcgi_pass", пример:

В большинстве случаев проблем не будет при поднятии базы 5.7 версии на 8 версии. Если по шагам:
1. Сделайте дамп базы(экспорт), которая на sql 5.7
2. На сервере, где sql 8 создайте пустую базу и залейте(импорт) в нее созданный дамп
3. Настройте в конфиге друпала, подключение к двум БД (если в коде требуется работать сразу с двумя БД).

Наверное у каждого своя методика, кто, как привык
Если про себя рассказать, то для начла надо понять, какую страницу вы хотите ускорить. Затем нужно понять, какие таблицы из базы участвуют в получении информации. Далее нужно понять, по каким столбцам запрашивается инфа из базы (это выражение where в запросе).

Ну вот скажем условная таблица "продукты", в выражении where участвуют 2 столбца - "цена" и "наличие".
Значит можно попробовать добавить составной индекс.

Мне в свое время очень помогла статья от Niklan, вот ссылка. В ней подробно разбирается тема кеширования.

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

На одном проекте в базе была таблица с 380 млн. записей. До добавления индексов, время выполнения запросов было от 10 сек до 3 минут в зависимости от запроса. После добавления индексов, время составило от 0.009 сек до 0,23 сек

Про вирусы правильно пишут, если есть возможность, то проверьтесь на вирусы. Наверное в таймвебе есть такая услуга.
Еще причина такой нагрузки может быть, если сайт дидосят. На днях у меня такое было. Посмотрите журнал запросов, обычно в названии файла есть это "access.log". В моем случае файл с логами увеличивался по 200 МБ в минуту.

Привет.

Надо определится со стратегией кеширования. Что кешировать, когда и на сколько. Как по мне это важнее, чем, что использовать. Если кешировать все подряд, то 20 гигов памяти улетят, не заметите)

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

Что использовать?
memcached, apcu, redis - разницы особой нет, они делают то, что хранят кеш в оперативке. Я обычно redis использую, мне с ним как то удобнее работать.

Zend OPcache - тут хз на сколько прирост будет в скорости.

Привет.

Обычно по такой схеме действую, список в порядке важности:

1. Включить логирование медленных запросов к базе (slow_query_log). Время выполнения у запросов (long_query_time) выставить 0.5 для начала. На самом деле тут от специфики сайта зависит. Я обычно начинаю с 0.5, если в лог попадет мало запросов, то уменьшаю время - 0.5, 0.4 и т.д. Если в логе запросов будет очень много, то увеличиваем время, что бы найти самые долгие.
Время выставляется в секундах, 0.5 это пол секунды.

На Drupal можно сделать любой магазин, ограничение только в фантазии). Это просто инструмент достижения цели.
Бизнес часто выбирает быстрые решения, так как они более дешевые. Условно установив тот же OpenCart/CS-Cart вы получаете сразу готовый интернет магазин, остается заполнить данные о компании и завести товары. На Drupal согласитесь, процесс посложнее будет).

Приветствую.

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

1. Opencart.
Очень хороший базовый функционал, великое множество готовых модулей. Модули есть платные, есть бесплатные. Можно без программиста создать очень хороший магазин. У меня был на поддержке магазин с 62 тыс. просмотров в сутки, 3 тыс товаров. Магазин не тормозил.

можно в гите хранить, ни кто же не спорит)

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

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

Привет.

Тут скорее вопрос удобства и зависит от ситуации. Каждый выбирает свой путь. В своей работе использую следующие подходы:

Вариант 1:
Если разработка с нуля и потом сайт на поддержке остается.
Разработка ведется на локальном сервере. Все наработки коммитятся в гит в тестовую ветку. Из тестовой ветки настроен автоматический деплой на тестовый сервер. На тестовом сервере сайт показывается клиенту перед сдачей.
Когда требуется перенести правки на живой сайт, то сливаем тестовую ветку в мастер ветку и там в ручном режиме запускаем деплой.

На днях добавлял Last Modified для Drupal 8.7. Может поможет.

В своем модуле:

Файл: MY_MODULE.services.yml

Приветствую.

Вам нужно включить режим разработки. Для этого:

1. Откройте файл
\web\sites\default\settings.php

Раскомментируйте этот код

Привет.

Перешел с OpenServer на Docker + WSL2. Тут ключевое, хранить все проекты в файловой системе линукса, который крутится в WSL2. Тогда все летать будет. Для себя отметил следующие плюсы:

1. Скорость работы сайта стала выше. Для примера, у мадженты есть команда пересборки статики, так вот, используя openserver время ее выполнения было 4-4,5 минуты. В докере 1-1,5 минуты. Про друпал сайты вообще молчу, мгновенно открываются.