Тут у вас настройки шаблона для создания записей, а не настройки существующих записей, пока вы не поставили галочку. Также, тут нет ничего касающегося dkim. А в SPF явная ошибка.

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

Вы добавили ключик в нужную DNS запись, и настроили подписывание писем на вашем почтовом сервере?
Судя по преведённой ошибке, с первым пунктом есть проблема.

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

Механизм извещения о упоминании, безусловно хорошая штука, но я пока не понимаю, чем-бы я мог помочь тут.

Тут нет никакой проблемы с сервером, тут какие-то странности в поведении форм, насколько я понимаю...
А, вообще, нужно просто два сайта в мультисайтинге, и два конфига drupal, соответственно, с одной кодовой базой, базой данных и симлинком между /sites/sitename/files. Если решится проблема с формами и $base_url, это будет работать нормально.

Когда сайт становится большим, все на вас хотят заработать, ибо хостеры, а не благотворительная организация. Чему удивляетесь?

Просто прописать мало, надо либо source ~/.profile после этого выполнить, либо перелогиниться, чтобы переменная окружения PATH приняла нужное значение.
Также, если у вас какой-нибудь zsh, вам может быть нужно использовать .zprofile

Не для всех тут, Масяня совпала с детством.

Вообще, это не то чтобы ошибка, это предупреждение, что в более свежих версиях PHP такой код будет ошибкой.
Стоит обновить views, если проблема решена в более новой версии. Но это не так критично.

Вот у меня тоже именно такая первая ассоциация.

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

Вообще-то овер сто запросов в принципе не проблема, и в этом конкретном случае тоже. Тут речь о коннектах именно.

А что, по поводу лога веб сервера?

Вообще, сравнение было между кастомным проектом на Symphony и Drupal 7, ещё вероятно, так на всякий.

Конечно нет - тебя очень даже заметно! =р

На самом деле, большая часть "под капотом", там была не на PHP, и не в контексте веб сервера, вообще. Но для мордочки, которая складывает задачи в очередь, PHP вполне не плохой выбор.

Про "тысячи визиток и небольших магазинов": шаблонизация, общий подход к проектированию однотипных решений, нормальная внутренняя документация, и так работает не мало студий, на самом деле. Заодно небольшой большой бонус: vender-lock, клиент не уйдёт так просто. Т.е. и в ваших кейсах бывают разные подходы.

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

Laravel был, но ещё не было вокруг него такого хайпа. А Yii, был уже 1.1.х даже. И тогда это был очень неплохой выбор, кстати. Кстати, и symphony была совсем не той, что сейчас - 2.0 только вышла вроде?

По поводу поддержки: А в чём именно была разница? Какие проблемы решались, в том, и другом случае? Может просто была проблема с квалификацией архитектора? Как сейчас на Drupal 8, те же проблемы не вылезают?

За счёт чего была такая разница в стоимости поддержки?
Какова была разница в стоимости/сроках разработки?
Пробовали-ли какой-нибудь yii, laravel, или какие-то другие фреймворки?

Они, просто, не так заметны.

С этой точки зрения D8, конечно лучше.

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

По тому, что говорит о себе человек, можно судить только о его ЧСВ, которое вообще никак не связано с мастерством.

Есть и скромные профи, и те что "знают себе цену". Точно также, как и профаны, есть как вполне осознающие свои ограничения, так и уверенные в том, что они просто первые в профессии...

А кому вы предлагаете портировать и писать код? Пользователю, который хочет запилить себе сайтик? Rly?
Drupal сделал огромный шаг в сторону серьёзных разработчиков, но он же был в сторону от простых пользователей CMS, и от среднего PHP разработчика, заодно.

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

Практически никогда к теме не прилагается структуры и контента. Вам необходимо самостоятельно создать нужную вам структуру, а контент можно сгенерировать с помощью https://www.drupal.org/project/devel например.

Думаю, вам надо как-то переформулировать вопрос, и объяснить, какую именно задачу вам надо решить.
Каталог интернет магазина, вероятнее всего, у вас сделан на views, и именно его шаблоны вам надо переопределять. А страница товара это вероятно node, и переопределять надо шаблоны класса node.tpl.php https://api.drupal.org/api/drupal/modules%21node%21node.tpl.php/7.x . А шаблон page.tpl.php, в принципе, редко переопределяется, и обычно он один и тот же для всех страниц.