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

Тогда может быть созданы всё-же tablespace, или одна из баз создана при innodb_file_per_table, а вторая нет.

Ritka wrote: вместе поставить Redis и Memcache на один сайт нельзя?

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

Ritka wrote: далее Redis работает в разы быстрее Memcache

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

С этим ключом будут пропускаться вот эти команды: https://dev.mysql.com/doc/refman/5.7/en/create-tablespace.htm и https://dev.mysql.com/doc/refman/5.7/en/create-logfile-group.html
Обычно, это можно безболезненно пропустить.

Не только может, но и должен. Его кеш хранить в базе не очень разумно - это даже прямо на странице модуля на d.org в самом начале написано. Рекомендую ещё раз внимательно его прочесть: https://www.drupal.org/project/entitycache

Чтобы было понятнее: Redis или memcached это хранилища кеша, которые может использовать, в частности, Entity cache. Т.е. совсем другого порядка вещи, они не пересекаются с Entity cache функционально.

В том виде, как вы описываете - нет. А вот если перед ним обратного прокси какого-нибудь, это плохо, особенно, если Apache в режиме prefork.
Также, то, что иногда вылезает установка, говорит о проблемах с mysql. Стоит посмотреть его лог.

А вообще, что у вас за окружение, из какого набора ПО оно состоит? Кто и как его настраивал?

Достаточно сравнить состояние контриба во времена расцвета 7 и сейчас. Очень многое не будет уже мигрировано на 8+, очень многое висит без ментейнеров и.т.п. Совсем не только крупные организации и клиенты были двигателем всего этого.

Возможно, для фрилансера-одиночки Drupal будет сложен, если у такого разработчика узкий горизонт планирования.

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

Какие там сотни и тысячи сайтов? Где хоть один кейс такого использования сотен, и тем более, тысяч сайтов" хоть в одной корпорации? Их всего тысячи будут, всех сайтов сколько-то крупных организаций на drupal, тем более на 8/9. Для действительно сложных проектов больших компаний используются свои инструменты, чаще всего, ну и php довольно редко вообще используется. Ниша Drupal, это в лучшем случае, мелко-средний бизнес, который уже может себе позволить одного/ небольшую команду разработчиков нанять(ну и чаще аутсорсную), но свой кастомный проект не тянет, или он не нужен по тз.

Он не сравнивается тут технически с drupal, он сравнивается подходом к пользователям(не потребителям контента, а создателям/вадельцам сайтов). Не надо путать. Такое сравнение более чем оправдано.

Оно бы хорошо, но это монета о двух сторонах: с таким подходом ниша которую занимает Drupal очень сильно сужается.
И "экосистеме", если уж глобально задуматься, приносят пользу совсем не только разработчики в ней варящиеся. Развивать и продвигать платформу которая массово используется куда проще. И привлекать в неё новых разработчиков, кстати, тоже.

Так и есть. Теперь много каталогов, например, которые раньше очень удобно делались на Drupal, делают на том же WP, что несколько извращение, и технически ужасное решение, но простое.
И в самой неприятной ситуации те, кто сайты на 7 уже сделал.

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

Это совсем не так однозначно.
Drupal7 и 8/9 очень сильно отличаются тем, на кого они рассчитаны в рамках того же продукта. И это проблема, в общем-то проявление которой мы тут видим в этом обсуждении.
У 7 был неплохой ещё баланс возможностей/сложности, и можно было не быть разработчиком, чтобы сделать на нём приличный сайт. 8+ это уже явно продукт ориентированный профессиональных разработчиков. Кому-то стало удобнее. Кому-то стало намного сложнее, потому, что придётся освоить ещё несколько больших концепций, например, работу в консоли как таковую, что уже весьма не мало.

Это первая же концепция, которую надо усвоить, если вообще как-то пересекаться с *nix. И уж точно до того, как что-то делать на собственной vps/сервере.

1. Вообще, это не так. Это может быть и другой пользователь, а веб сервер должен иметь возможность читать, везде и писать в */files. Но и запускать композер надо тогда от этого пользователя. Просто когда это один пользователь, удобнее зачастую.
2. А вот тут всё правильно. От рута работать, конечно, не надо, только править какой-нибудь системный конфиг/ставить софт.

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

В вашем случае, у вас не те кавычки в GRANT, и в Mysql 8 создание пользователя и управление привилегиями разделено. Правильный запрос будет выглядеть так:

CREATE USER "mytestus"@"localhost" IDENTIFIED BY "mytestp7777";
GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, INDEX, ALTER, CREATE TEMPORARY TABLES ON testdrupal.* TO "mytestus"@"localhost";

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

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

По такой информации - никто.

Начать надо хотя бы с того, что именно должно заниматься конвертацией видео. Работало-ли это когда-нибудь. Какие ещё есть ошибки в логах и.т.п.
Причин у указанного ворнинга может быть довольно много.

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

Как выше написано, модули в таком окружении устанавливаются с помощью composer, конечно.

Сначала, надо обновить mysql сервер до 5.7.8+(как именно это сделать, сильно зависит от того, где запущен ваш сайт), а уже потом обновлять данные в базе с помощью update.php.

Первая, это монтирование папки на хост машине с данными Mysql в контейнер.
Вторая строка, это монтирование внешней папки с начальными данными для инициалиализации mysql в контейнер. В папку можно положить, sql скрипты создающие какие-нибудь базы, пользователей, загружающие какие-нибудь данные и.т.п. Надо оно вам или нет, вопрос к вам.

Не, это не модно и не технологично.

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

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