Я просто всегда думал, что если у div’а нету свойств, то он как пустышка, его как бы и нет и он не на что не влияет, но теперь у меня сомнения в этом… Хотя странно не отступов ничего ни свойств как он может влиять на отображения и сдвигать чутка другой объект…
А как я это исправлял это вообще прикол, я проверил все файлы всеми антивирусами, своим глазом, поиском по файлам с применением регулярных выражений, даты изменений и НИЧЕГО, обычно как я ламер считаю – куда-то впихнули скрипт редиректа, ну там в 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;
Да работать то оно будет, просто зачем двойную работу то делать? Сначала апатч сжимает, потом nginx разжимает и опять сжимает.
Решил протестить отключение сжатия на 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 году, иди-ка ты вниз к любителям без сжатия :), пусть лучше они вместе там сжимают и разжимают :) ( Шутка ).
