Чтобы предоставлять хостинг произвольным клиентам с минимальными знаниями и произвольными скриптами.

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

1. Вопрос вкуса. Не стоит что-то более экзотичное только выбирать.
2. Сколько скажете скушать каждому приложению, например, сколько будет разрешено поднять процессов php и.т.п. Ну это если о памяти а не диске вопрос.
3. Не нужна. Серьёзно, совсем не нужна, никакая. Это софт для других задач.

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

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

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

Я о том, что действительно в интерфейсе шлюза не убрать /subdirectory, не заменить, например на / просто? Без этой /subdirectory не было бы и проблемы, которую вы пытаетесь старательно решать.

Это могут быть одни и те же данные по разным url с разным оформлением. Для этого совсем не обязательно делать разные виды сущностей.

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

Нынешняя структура, в первую очередь, результат некого постепенного развития. Изменить всё и сразу не так просто. А вынести библиотеки в отдельную папку, да ещё как это делается композером по умолчанию довольно просто.

Напомнить, что у нас больше одной точки входа, и так радикально не выйдет?

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

marassa wrote: Про vendor там как раз ни слова нет.

Это потому, что папка vendor в корне проекта является значением "по умолчанию".

marassa wrote: Я поправил путь в autoload.php, ему еще какого-то рожна не хватает:

Потерял вторую часть ответа:

marassa wrote: А я не могу понять, почему нельзя просто поправить нужные конфигурационные файлы существующего сайта. Но ни одна зараза нигде не пишет какие именно

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

Ой-ой. Не надо думать, что вот эти все тонны зависимостей, похожи на "крохотную (и наиболее "вылизанную") часть кода". Пора снять розовые очки. Это код практически не контролируемый вами. Очень разумно всё это держать подальше от webroot.
Сколько сайтов было сломано через разные кривые примеры к библиотекам, это прям даже Wordpress не снилось.

Мне сложно понять, зачем вообще дублировать контент? Раз необходима такая синхронизация, почему вообще не обойтись одним типом материала "мероприятие"?

Ну а если надо синхронизировать, зачем это по крону-то делать? Так-то разумнее при изменении источника, как и при создании, используя какой-нибудь hook_node_update.

Неужели там нет возможности просто домен обслуживать без добавки к url? Точно не в кривости настроек дело, а именно в ПО?

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

А зачем вообще дважды шифровать траффик? Может просто настройками сервера требовать на https достаточно стойкого шифрования. Там же можно реализовать авторизацию клиентскими сертификатами, если это нужно...

Ну и раз меняется домен, то зачем и url-то менять?

Вот только это может где-то инклюдиться, а не просто вызываться...

В drupal это можно сделать как-нибудь так: https://www.drupal.org/project/utf8mb4_convert

А на хостинге не слишком старый Mysql? Поддержка utf8mb4 появилась в mysql 5.5.

А также требует установленного Image magick/Graphics magick не слишком древнего и соответствующего php_imagick. В целом лучше чем GD, но всё же менее распространён.

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

Как ни странно, просто ничем.
Загружать заведомо чистый код.

Надо смотреть ошибки в логах. Может быть там GD не умеет webp.

GD должен поддерживать webp для работы этого модуля.
Вообще, с webp лучше работать через cwebp, но для этого он должен быть установлен.

Это совершенно бесполезная цель, и тебе как разработчику стоило бы объяснить заказчику почему, ну и самому понимать.