Хаки: сайт должен быть уникальным #1 – WordPress
Как-то летом я от нечего делать ковырялся не помню где, и в какой-то момент меня посетила грусть осознания всеобъемлющей похожести всего на свете друг с другом по тем или иным параметрам.
Если быть кратким, то надо выделяться – и все равно, каким образом. Именно поэтому я решил опубликовать для вас запись (спустя полгода, почему-то), которая в общей интересной для нас теме – создание и развитие собственной социальной сети – поможет вам выделиться, стать уникальными, непохожими, особенными…
Я собрал для вас стандартные строки кода WordPress и BuddyPress, использовав которые, вы сможете изменить поведение/вид кода вашего сайта до неузнаваемости. Итак, часть 1, что поведает нам о WordPress…
Все ниже надо вставлять в файл /wp-config.php в корне сайта.
define('WP_MEMORY_LIMIT', '64M');
Увеличение памяти, выделяемой для выполнения php скриптов до 64 Mb. По умолчанию у нас 32 для обычной инсталляции WP, 64 – для мультисайтовой.
Меняем пути к папкам
define( 'WP_CONTENT_DIR', ABSPATH . 'content' );
define( 'WP_CONTENT_URL', get_option('siteurl') . '/content');
Этим кодом вы измените путь и url папки /wp-content/ в корне сайта на /content/. Удобно, если вы хотите скрыть, что используете WordPress (но это не единственный шаг на пути к “сокрытию”). Это надо делать обязательно вместе с предыдущим кодом.
define( 'WP_PLUGIN_DIR', WP_CONTENT_DIR . '/components' );
define( 'WP_PLUGIN_URL', WP_CONTENT_URL . '/components' );
Этим кодом вы измените путь и url папки /plugins/ в папке WP_CONTENT_DIR на /components/. Удобно, если вы хотите скрыть, что используете WordPress. Внимание: может привести к отмене работы некоторых плагинов, которые используют не глобальные переменные WordPress для указания путей к файлам, а “вшитые пути”. Вам придется немного поковыряться, чтобы все проверить.
define( 'WPMU_PLUGIN_DIR', WP_CONTENT_DIR . '/modules' );
define( 'WPMU_PLUGIN_URL', WP_CONTENT_URL . '/modules' );
Этим кодом вы измените путь и url папки /mu-plugins/ в папке WP_CONTENT_DIR на /modules/. Удобно, если вы хотите скрыть, что используете WordPress. Внимание: может привести к отмене работы некоторых плагинов, которые используют не глобальные переменные WordPress для указания путей к файлам, а “вшитые пути”. Вам придется немного поковыряться, чтобы все проверить.
К сожалению, чтобы изменить путь к папке /themes/ надо использовать фильтры, а не константы, и располагать код не в wp-config.php. Это выходит за рамки этой записи, но если кому-то интересно, то напишите в комментариях, я напишу дополнительно.
Папку /wp-admin/ переименовать нельзя, потому что внутри некоторых файлов эта папка зашита прямо в коде, без использования глобальных переменных (вот такие вот разрабы нехорошие). Как защитить эту папку (один из методов), а также папку /wp-includes/, я напишу в одном из следующих постов.
Разное глобальное
define( 'WP_DEFAULT_THEME', 'twentyten' );
Здесь можете указать шаблон, который будет актироваться, если:
- Возникла проблема с вашим текущим шаблоном и система пытается откатится, чтобы не рухнула морда сайта.
- Создан новый блог в режиме WordPress MultiSite. Этому новому блогу автоматически присваивается этот шаблон.
Вместо слова twentyten впишите название папки вашего шаблона внутри папки /themes/.
define( 'WP_LANG_DIR', WP_CONTENT_DIR . '/langs' );
Вы также можете изменить расположение папки с переводом самого WordPress. По умолчанию – в /wp-content/languages/, мы только что сделали в /content/langs/.
Защита файлов cookie
define('USER_COOKIE', 'siteuser_' . COOKIEHASH);
define('PASS_COOKIE', 'sitepass_' . COOKIEHASH);
define('AUTH_COOKIE', 'site_' . COOKIEHASH);
define('SECURE_AUTH_COOKIE', 'site_sec_' . COOKIEHASH);
define('LOGGED_IN_COOKIE', 'site_logged_in_' . COOKIEHASH);
define('TEST_COOKIE', 'site_test_cookie');
Использование в имени куков слова wordpress просто кричит о движке. Поэтому я поменял его на слово ‘site’, а вы можете сменить на ваше собственное слово (например, на доменное имя, только без каких-либо символов – только слово домена на латинице, без точек и дефисов).
Параметры для записей сайта
define( 'AUTOSAVE_INTERVAL', 60 );
Можно изменить параметр времени автосохранения записи при написании. По умолчанию – каждые 60 секунд. Если кому надо, можете выставить большее/меньшее значение.
define( 'EMPTY_TRASH_DAYS', 30 );
Показывает, через сколько дней очистится папка Корзина на странице списков записей в админке. Я, если честно, вообще не использую корзину. В этом случае можете поставить значение, равное 1.
define('WP_POST_REVISIONS', false);
Этот код отключит создание ревизий записей. Ревизии – это копии ваших записей, которые создаются при редактировании и в процессе написания. Их наличие в базе здорово ее раздувает, потому я предпочитаю отключать их. Желательно отключить, если у вас много сот записей на сайте.
Информация для отладки и исправления ошибок
define( 'WP_DEBUG', true );
Более подробно об этом я написал в записи: Debug-mode для отображения ошибок сайта.
define('WP_DEBUG_LOG', true);
Эта строка начнет записывать все ошибки WordPress в файл /wp-content/debug.log, но не будет их выводить. Работает в паре с предыдущим кодом. Если после прописывания двух этих параметров не появился файл debug.log – создайте его вручную, пустым и доступным для записи.
Переменные только для WordPress MultiSite
Это надо прописать в каком-нибудь файле, но не в wp-config.php. Иначе не будет работать переменная $wpdb. Только для опытных пользователей с большим опытом работы с WordPress!
define( 'UPLOADBLOGSDIR', WP_CONTENT_DIR . '/net.files' );
Изменение папки, в которую будут загружаться файлы всех ваших блогов. По умолчанию загружается в /wp-content/blogs.dir, а мы изменили на /content/net.files. Если вы поменяли этот параметр то вам обязательно надо поменять и тот, что ниже:
global $wpdb;
define( 'BLOGUPLOADDIR', UPLOADBLOGSDIR . "/{$wpdb->blogid}/files/" );
Этот код необходимо прописать, если вы изменили UPLOADBLOGSDIR, иначе не будет работать загрузка файлов на блогах.
К сожалению, данная запись не претендует на всеобщий охват всех возможностей подобных хаков, но большинство полезных вещей вы уже получили. Надеюсь, вы расскажете мне и прочим читателям моего сайта, чем окончились ваши пробы. Самые смелые и удивительные изменения, найденные в комментариях, я даже опубликую – для всеобщего ознакомления и ко всеобщей зависти.
В следующей записи будет обзор соответствующих глобальных переменных самого BuddyPress.
Уникальность.. это скорее всего использование движка – не WordPress))))
Ну почему же.. Не обязательно :) WP достаточно гибок, так что над ним можно издеваться вдоволь.
Вся эта уникальность будет слетать при обновлениях, и опять по новой …
Естественно, необходимо будет ручное обновление. Это во-первых. А во-вторых, не слетать ничего не будет :)
А скажи, возможно ли кук нибудь убрать из url /members/ ?
Извини, нашёл у тебя же на сайте.
А как, создать шаблон для блога под каждого пользователя в случае использования мульти сайта?
В смысле под каждого пользователя? Чтобы в зависимости от пользователя для его блога выбирался разный шаблон? Или что вы имеете в виду?
может конечно ошибаюсь.. чтоб подгружались стили для каждого юзера свои – WP Skin (вроде так)
у меня на SL от статуса юзера меняется оформление его личной страницы
Есть еще плагин от BuddyDev – не помню точно, как называется. Там фон собственной страницы можно менять.
а в новой версии ваш плагин работает? пробовали уже?
Очень хотелось бы узнать каким хаком/фильтром изменить папку с темами (themes).
Так же о защите папок wp-admin (один из ментодом я уже увидел у вас в записях) и wp-includes тоже интересно узнать.
Заранее благодарен.
Изменить папку с темами:
register_theme_directory($path),где $path – абсолютный путь к папке, куда вы хотите складывать ваши темы.
wp-admin – у меня уже видели (+можно погуглить). wp-includes – никак. Переименоывать эту папку нельзя. Стандартной переменной WPINC – тоже. Во многих местах вшит этот путь напрямую – поломается часть функционала, если изменить.
Большое спасибо за ответ.
С wp-includes не особо велика беда. Постараюсь “закрыть” везде прямые обращения к этой папке (за той же библиотекой jQuery и подобными файлами из страниц сайта) перенеся все эти файлы в нужное мне место.
Пробую по-максимуму скрыть использование ВордПресса.
Цель таких манипуляций – доказать заказчику на примере своего сайта, что от выбора системы не особо сильно зависит работа сайта (стабильность и скорость), главное чтоб было удобно управлять контентом.
А как связано скрытие со стабильностью и скоростью?
По сути связи с технической стороны нет. Но заказчик принципиально не хочет использовать WordPress, и причиной этому ставит медленную скорость работы и прочие (часто надуманные) проблемы системы. Показывал ему пару сайтов на ВП, которые и работают шустро и посещаемость имет нормальную, но как только он видит что используется ВП (он это в коде страницы смотрит), то сразу же у него появляются “заморочки”. Вот и хочу сделать так, чтоб пользователь в 99% случаев не смог узнать какая система используется на сайте.
Это нереально. Все равно определить знающему человеку, что это WordPress – дело 1-2 минут максимум. Я занимался таким сокрытием – ну ботов обмануть можно, а толку-то?
Вы лучше расскажите ему про оптимизацию. И про то, сколько он денег сэкономит, если будет использовать WP – ведь не придется писать API, админку и прочее.
Понятно, спасибо. Предрассудки стоит побеждать :)
Разъясните пожалуйста неграмотному новичку как это проделывается и где с изменением пути папки темы… А то я поменял назв. папки wp-content на другое на начальном этапе установки WP, а теперь есть проблема с работоспособностью темы, есть подозрения что из-за изменения папки wp-content. Проясните мне про изменение пути папки тем пожалуйста.
Добрый день
спасибо полезные функции
скажите пожалуйста, вот на этом сайте http://benword.com/how-to-hide-that-youre-using-wordpress/ показано комплексное решение по скрытию WordPress (в частности ссылка на https://github.com/retlehs/roots), может у вас будет время и возможность сделать пост на эту тему. Спасибо
Не вижу в этом никакого смысла. В той статье ничего не было указано про изменение
/wp-content/папки – только папка загрузки.Да и вообще, некоторые плагины будут ломаться, если вы уберите
/wp-content/./wp-admin/ и /wp-includes/ переместить нельзя… Так что полностью не получится скрыть.
Имхо это пустая трата времени.
Если у вас возникла необходимость скрыть, что сайт сделан на ВП, то может лучше его сделать на другом движке?
Во времена ВП 2, мы сделали сайт на своем движке, но со всеми атрибутами ВП, даже дырки фейковые оставили. Весело было смотреть, как его ломают.
Ух ты, это интересно. Хотите написать пост об этом (можно и тут, прямо на CD, гостевой)? Как написали, что оставили, как ломали?
Было это достаточно давно и всего не припомню. В те времена у нас было несколько клиентов на вордпрессе. Тогда в нем было еще предостаточно дырок, и в интернете ходили инструкции, и как ломать, и как патчить. Клиентов постоянно взламывали, а мы им помогали все вернуть, починить, запатчить, что б не ломали. Естественно за эту дополнительную услугу брали какую-то денежку. А потом клиент переезжал на версию на единичку больше в третьем знаке и все повторялось. Короче, мы тогда уже неплохо знали этот движок и его больные места.
Наш главный сайт был написан на самодельном движке, а верстка главной страницы была утащена из популярной верстки вордпресса. К первому апреля решили пошутить по сисадмински и вернули в верстку все атрибуты вордпресса, вплоть до ссылок на вп и некоторые баги. Прописали пути wp-. Сделали фейковые странички регистрации и другие шалости.
Так, “ломая” известным образом, зловред получал доступ к “админской” страничке. Там он первым делом пытался сделать пост, но он никак не публиковался, то формат не соответствует, то размер поста слишком большой, то еще какие ошибки. Дескать у нас стоит плагин, контролирующий правильность поста. При попытке отключить плагин, он как бы отключался, а потом говорил, что требуется пароль фтп. Иногда даже публикация проходила, но выдавалась ошибка – недостаточно памяти для процесса.
Самое интересное заключалось в том, что эта фейковая страничка, конечно же ничего не публиковала, а только отображала в нашем интерфейсе, что и кто сейчас делает и нажимает. А у нас была еще и возможность менять надписи в диалоговом окошке ошибки.
Зловреды часами сидели на фейковой админке, пытаясь хоть что-то сделать, а мы им писали отказы и подсказки. Постепенно мы увеличивали функционал. Стало “возможно” менять разные опции и даже пароль сисадмина, который менялся, а адрес никак не хотел меняться и подтверждение уходило на якобы старый адрес.
Это было очень весело, пока не навалился очередной аврал и нам стало не до того.
“для последних версий WP и BP – скорее всего лимиты по памяти нужно расширять не до 64, а до 128))) + менять пути к папкам… если в этом нет крайней необходимости – лучше не менять)
64 и то жирно. У меня после нескольких экспериментов лимит памяти 52Мб. Этого вполне достаточно для вп+бп с кучей клиентов.
при использовании APC, XCache – вроде как да, но чтоб скомпилировать – нужно больше
Мы экспериментируем по зажиманию ресурсов. APC, XCache нет совсем (нужно будет кэширование, поставим ngnix). VPS для нашей сборки имеет 40% ядра процессора, увеличенный своп. Лимит файла загрузки 4Мб. Вот с этим и были проблемы – большие файлы картинок не обрабатывались, ресурсов не хватало на лимите 50Мб для процесса. Сделали 52Мб – все стало обрабатываться нормально.
мораль – если зажать процессор, то никакой памятью это не компенсируешь, будет тормозить.
Спасибо, инфа пригодилась, хотя зашел сюда в поисках другого – возник какой-то косяк в самом движке и ссылки на скрипты и стили из плагинов стали включать в себя путь на сервере до них…
По теме же – что-то из перечисленного делает плагин Better WP Security, а что-то стало для меня новостью и попутно решая свою проблему воспользовался вашими советами.
Еще раз спасибо.
А я вот когда прописала все настройки в wp-config.php то мне почему-то пути не переименовались.. В чем причина подскажите пожалуйста. Вот копирую состав того что я написала.
define('WP_MEMORY_LIMIT','64M');
define('WP_CONTENT_DIR', ABSPATH'content');
define('WP_CONTENT_URL',get_option('siteurl').'/content');
define('WPMU_PLUGIN_DIR',WP_CONTENT_DIR.'/modules');
define('WPMU_PLUGIN_URL',WP_CONTENT_URL.'/modules');
define('USER_COOKIE','siteuser_'.COOKIEHASH);
define('PASS_COOKIE','sitepass_'.COOKIEHASH);
define('AUTH_COOKIE','site_'.COOKIEHASH);
define('SECURE_AUTH_COOKIE','site_'.COOKIEHASH);
define('LOGGED_IN_COOKIE','site_logged_in_'.COOKIEHASH);
define('TEST_COOKIE','site_test_cookie');
define('WP_DEBUG',true);
define('WP_DEBUG_LOG',true);
И после прописания в конфиге этих настроек вместо сайта белый фон. Поооччччееемммууу???
У вас ошибка.
ABSPATH'content'Пропущена точка. И это прописано после определения переменной ABSPATH? Если нет, поменяйте на
dirname(__FILE__)И вы папки переименовали согласно новой структуре?
get_option(‘siteurl’) может и не работать в том файле. Тогда надо
'http://'.$_SERVER['SERVER_NAME']Да и вообще, смотрите error_log вашего сайта или сервера (зависит от настроек сервера). Там все ошибки есть, по ним легко починить.