web.config не имеет никакого отношения к nginx.

Доступ к конфигу apache для этого vhost есть? Показать можете?

А в error.log что-нибудь есть?

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

Давайте её посмотрим.

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

[⚠️Глянец ] или даже [☣️ Глянец ]

Небывалый случай, но я тут полностью согласен с VasyOK. Это просто легенда же.

Внимательно посмотрел на скриншоты, и с трудом, но понял, о чём на самом деле пишет VasyOK.
Да это ж Глянец - слово для понимающих говорящее много. Сочувствую нынешнему разработчику. =[ ] Там действительно может быть всё что угодно...
Поясню примером: https://drupal.ru/node/127651#comment-665144

UPD: Т.к. пример не доступен, напишу суть - там фактически был зашит бекдор в сайт этими товарищами. А качество было ниже плинтуса.

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

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

Что memcached, что redis, быстрые key-value, и отлично работают. Собственно, как бекенд кеша drupal, они фактически идентичны, но в целом, redis обладает большими возможностями, и может быть интереснее, если использовать не только для кеша.
С другой стороны, memcached очень прост и надёжен.

Если вы используете php в режиме fastcgi, то зачем вам вообще apache? С mpm_event, он в принципе не так уж плох, но всё-же и так он тяжелее того же nginx, который прилично работает и с http2.

Ну и в целом, не всё так просто как описано выше, т.к. у большинства с apache mpm_prefork, будет в комплекте mod_php, и он не будет нормально работать с mpm_event.

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

Посмотреть в целом стоит как настроен сервер, прежде всего mysql. Посмотреть что с нагрузкой. Поискать узкие места. Заглянуть в логи, какие именно запросы отдают 500, и проанализировать почему.

Надо только утчонить, что это путь не абсолютный, а относительно корня сайта. А вместо default может быть и что-то другое.
Ну и скорее, надо проверить существование и права на этот каталог, а также проверить права на sites/*/files. Т.к. проблемы создания в этом каталоге папок от имени веб сервера быть не должно.

Вообще говоря, а зачем вам тут спешить?

Если хочется 404 быстро обрабатывать, есть fast404, и как доп модуль, и как механизм ядра. Но лучше в принципе как можно меньше запросов отдавать через drupal, и отдавать на статику, например, 404 просто как http заголовок вообще, а не страницу - ведь это нужно для браузера а не клиента, собственно. Это делается правильной конфигурацией веб сервера.

У вас битый ibdata1. В сообщении об ошибке довольно подробно описано, что делать дальше, и даже есть ссылка на документацию (http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html).

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

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

К тому же, меня весьма огорчила сама форма проведения такого экзамена в виде теста.

Не такой уж сложный тест по Drupal на Upwork, и если сертификационный тест на Back End Specialist проще, то всё как-то печально.

Трекер и кеш, это вещи мало совместимые в принципе.

Может есть, может нет, кто же знает? Откуда берётся $CONNECT, например, и проверяется-ли что соединение установилось? Т.е. не видя всего кода на вопрос не ответить.

Точнее есть ответ - изначально всё сделано не так как надо. У Drupal, если о нём вообще разговор, есть https://www.drupal.org/docs/7/api/database-api, и именно его надо использовать для работы с базой.

Это именно тот модуль, который вам нужен.
Вероятно, проблема в том, что вы устанавливаете слишком новую версию php-mailer, последняя поддерживаемая модулем 2.2.1, а phpmailer-fe вам вообще не нужен. Нужную версию, довольно непросто сейчас найти - она безнадёжно устарела. Вот ссылка: https://github.com/PHPMailer/PHPMailer/releases/tag/v2.2.1

Вообще, вам стоит мигрировать хотя бы на drupal 7.

В php есть класс для работы с датами/временем: http://php.net/manual/ru/class.datetime.php который умеет, как собирать дату из строки по формату, так и форматировать её в строку, или в unix time, который, вероятно вам нужен, с помощью DateTime::getTimestamp.

Как выше, очень правильно написали, вам нужен статический кеш, и скорее всего, большую часть проблем сможет решить https://www.drupal.org/project/boost а остальные оптимизация страниц, которые не получится кешировать на долго.

А как это относится к вопросу? Думаете у автора prefork, и максимум в пару обработчиков установлен? Вряд-ли. А иначе, ничего похожего на блокировку тут не получить. И никакой mpm апача не поможет, если просто не хватает вычислительных ресурсов, которые скушал ffmpeg по соседству запущенный...