Скорее всего, ему не хватает (правильного) пути до сокета mysql в настройках php.
Попробуйте прописать его в в соответствующей секции C:\xampp\php\php.ini, или попробуйте работать через локальный tcp (127.0.0.1), вместо сокета (localhost).

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

Ну это смотря где введёт...

Вход в базу сайта, вообще не связан с админкой сайта.

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

Вот прямо такой командой в виндовом шеле?

Разобраться с тем, как настраивать максимальное время выполнения скриптов, конечно, стоит когда-нибудь - своё рабочее окружение надо знать.
Но по поводу работы с базами вам мой очень полезный совет: Забудте на всегда о PhpMyadmin в принципе. Он убог, не удобен и не безопасен.

Используйте какой-нибудь Heidisql, или Mysql Workbench, если вам необходим графический интерфейс.
Или вообще, используйте консольные утилиты mysql и mysqldump, если речь о импорте/экспорте баз.

Windows вам не нужен. как и виртуалка на *NIX. кстати.

Eсли возникает вообще такой вопрос, вам нужен шаред с вероятностью ~100%, и не надо будет задумываться, что у вас там за окружение. Ну или сисадмин, который всё выберет, настроит и будет поддерживать, но которого вы, вероятно, позволить себе не сможете.

Т.е. как рзюме: Вам нужен просто другой тип хостинга.

Но дополнительной информаци, чтобы вам можно было бы помочь, так и не предоставили...

А что удивительного? Такая штука мало кому нужна.

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

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

Начните с того, на чём работает ваш сайт и что именно вы пытаетесь сделать, чтобы всё работало как надо.
Если у вас apache, начните с проверки, а включён-ли вообще mod_headers.

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

Каких-либо заметных подводных камней на данный момент не обнаружено, если говорить, о реализации на том же nginx.

Сделайте на тесте, как полагается, и посмотрите на практике, в отладчике браузера, который поддерживает HTTP/2.
Это будет единственный правильный ответ на ваш вопрос.

Смысл есть, тем более, всей работы, обычно, одна строка в конфиге nginx для включения этой возможности, если уже настроен SSL, а учитывая сегодняшние реалии и то, что это магазин, он уже должен, конечно, быть настроен...

7-8 Drupal нужно расширение PDO Mysql, которого похоже у вас нет.
Как не удивительно, тут Тлито, похоже угадал.

Ну и, заодно, не стоит так уже надеяться, что перенести сайт с 6 на 8 будет легко.

А который тариф вы там посчитали таким уж вкусным? BG-Start, например, где написано, что это dedicated server, и указано одно ядро и 10 гигов ssd. Ну вы же понимаете, что это виртуалка, т.е. надувательство, чтобы не сказать более правильно и не цензурно. Или E3-1270 dedicated server за $58, который вполне возможно, тоже только половинка сервера в реальности? Кстати, тот ДЦ грнхаус не советую.

P.S. За очень вкусными ценами, почти всегда есть какая-то засада. Народная мудрость: Бесплатных завтраков не бывает.

Думаю, это всё сочетание этих токенов, и не правильного конфига веб сервера.

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

Слишком мало данных для какой-либо диагностики.
Проверьте, для начала, точно-ли все сгенерированные boost правила скопировали в .htaccess?
Если да, то напишите что-ли мне в скайп, попробую помочь.

Не нежелательно, а он просто так не работает.
Я вообще не знаю, как удалось автору топика закешировать бустом страницы для авторизованного пользователя, разве что не полностью скопировать правила в .htaccess?

Т.е. в том конфиге у вас вставлен ваш приведённый выше кусок?
Тогда надо понимать, что вы не делаете там редиректа на index.php, собственно, и зачем-то подключаете обработчик php, которых у вас в этом локейшене просто нет...

И должен он выглядеть как-то так:

Боюсь, что в таком виде описанную проблему вам решить не помогут.

Для начала нужно определиться, а почему так происходит.
Начать можно с описания вашего стека - какое используется ПО, какие настройки.

Ну и проверить соответствует-ли реальность логике работы boost:
Никакие POST запросы кешироваться, по правилам генерируемым boost для Apache, не должны. Соответственно, ничто не должно бы препятствовать обработке данных формы входа, и соответственно, авториации.
Дальше, авторизованым пользователям выставляется кука, которая также ведёт к обходу кеша.

У вас фактически, нет конфига, для Drupal. Исполнения php файлов совершенно не достаточно.
Стоит изучить матчасть сначала, или хотя бы, взять вот такой конфиг как основу:
https://www.nginx.com/resources/wiki/start/topics/recipes/drupal/

Кто-то нашёл дыру на вашем сайте. Это может быть в порядке вероятности не обновлённый модуль, ядро, какой-нибудь кастомный модуль или сниппет, или даже дырка в хостинге.
Вы, конечно, её не нашли и не закрыли, и удивляетесь, что вас снова ломают?
Странный мазохизм - но по всей вероятности, это не относится к безопасности Drupal 7, а относится лишь к вашему пренебрежению безопасностью.

Мммм. А у кого-то даже одна цифра после точки может быть - есть такие счастливые люди...