Dmitriy_2014

А как я это исправлял это вообще прикол, я проверил все файлы всеми антивирусами, своим глазом, поиском по файлам с применением регулярных выражений, даты изменений и НИЧЕГО, обычно как я ламер считаю – куда-то впихнули скрипт редиректа, ну там в js файлы, может php, .htaccess и т.п., все пусто, ну думаю капец, ни вирусов, ни подозрений, НИЧЕГО, а редирект есть. Пришлось наехать (Умолять помочь :)) на техническую поддержку, к слову о том нужна ли она и должна ли помогать своим клиентам на VPS сервере, и надо отдать должное – пацаны с технической поддержки помогли, оказывается достаточно было изменить в базе данных в какой-то таблице и уже не помню в какой-то ячейке одну или две ссылки на свой сайт, и он заработал.

Но тут не вина разработчиков WordPress’а, а вина разработчиков плагина, но благо они легко меняются.

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

Был как-то взлом моего сайта, но надо отдать должное не из-за ядра движка, а плагина, по-моему, это был Yuzo Related Posts или Easy WP SMTP, но ничего особенного – был сделан редирект/перенаправление на какой-то вирусный обвешанный рекламой чужой сайт, как-то им удалось изменить в базе данных или в основных настройках где пишется ваш url сайта на чужой.

Не знаю может у меня настройки не правильные в nginx.conf:

    # Включаем сжатие

    gzip on;

    # Запрещает сжатие ответа методом gzip для IE6

    gzip_disable "msie6";

    # Разрешаем использовать статику

    gzip_vary on;

    # Разрешить сжатие для всех проксированных запросов

    gzip_proxied any;

    # Уровень gzip-компрессии

    gzip_comp_level 6;

    # Выделяем буфер для gzip

    gzip_buffers 16 8k;

    # Определяет MIME типы, для которых будет работать сжатие

    gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript;

Решил протестить отключение сжатия на Apache сервере в файле .htaccess так называемого модуля mod_deflate.c т.к. говорят смысла нету, но как я и предполагал лично для моего странного сервера это плохой совет, уж не знаю почему, ни хочу никого обидеть, но после отключения сжатие пропало…

Проверка по команде:

curl -H "Accept-Encoding: gzip" -I www.vk.com

Не выдала Content-Encoding: gzip, а ранее выдавало.

Сайт для проверки сжатия а-ля gidnetwork.com выдал:

Web page compressed?               No

Compression % 0.0

До этого:

Web page compressed?               Yes

Compression % 70.3

Ну и в инструментах разработчика браузера по циферкам в колонке Size (Хотя там непонятно, некоторые были типа сжатые.).

Это у меня связано с моими методологиями разработки – вроде все работает не трогай | если решился настраивать, то давай ломай все до конца, переверни верх дном, сравняй с землей | принцип сапера, отрезаем аккуратненько по одному проводку ( Шутка ).

Я сейчас отключу сжатие в Apache, а потом окажется что оно не работает, или как-то не так работает или не полностью работает, а поисковые системы скажут ууу братан у тебя сжатия нет в 2020 году, иди-ка ты вниз к любителям без сжатия :), пусть лучше они вместе там сжимают и разжимают :) ( Шутка ).

И как я понимаю это уже тоже не актуально и можно убрать:

# Запрещает сжатие ответа методом gzip для IE6

gzip_disable "msie6";