Автоматический деплой WordPress темы/плагина с Bitbucket

Времена, когда приходилось ручками заливать изменения файлов на prod-сервер — стремительно проходят, и на смену им приходят системы контроля версий и автоматизированный деплой. Ведь это чертовски удобно, когда ты один или с командой можешь работать над проектом, обкатывать изменения на локальном/тестовом сервере, и уже протестированный код отправлять на «боевой» сервер простым коммитом или слиянием. Ничего более не запуская, Карл!
Временами так же приходиться работать над проектами, построенными на (пускай и по дизайну очень убогому) WordPress, у которого очень низкий порог вхождения как у разработчиков, так и у конечных заказчиков (с первого раза правильно прочитал «конечных заказчиков»?).
Почему бы не настроить автоматический деплой кода из приватного репозитория на Bitbucket.org (или GitHub — не принципиально, но на нем нет халявных бесплатных репозиториев) на «боевой» сервер под управлением этой CMS?

Давай сперва определимся с некоторыми моментами:

  • В репозитории будет храниться только тема. Хранить в репозитории код самого WP и плагинов с wordpress.org смысла не имеет, так как авто-обновление (надеюсь, включенное и настроенное по умолчанию) делает это совершенно бессмысленным. Можно аналогичным способом деплоить и кастомные плагины;
  • Конфиги для nginx так же в репозиторий не попадают. Да, можно было бы подключать их директивой include /path/to/theme/config/*nginx*.conf, но это и потенциальная возможность править от имени пользователя php конфиги nginx, и необходимость ему же дать право перезапускать его. Нельзя так делать;
  • Использовать мы будем webhooks, а это ещё тот костыль по большому счету, так как не дает гарантии корректного выполнения кода на prod-сервере по причине отсутствия контроля состояния запроса;
  • Синхронизацию БД придется делать любыми другими средствами, если они необходимы. О миграциях и прочих «вкусных» штучках задумываться есть смысл при разработке именно плагина, и реализовывать их придется самостоятельно;
  • Придется разрешить php выполнять функцию exec().

Но не смотря на озвученные выше очевидные минусы — это в дохрена раз удобнее, чем ничего. Работать будем под CentOS 7.

Подробнее под катом

Сниппеты для WordPress (ч. 1)

Кэп, «по умолчанию» все сниппеты добавляются в ./wp-content/%theme%/functions.php твоей темы

Изменяем путь к статике темы

В ряде случаев полезно вынести всю статику на отдельный субдомен или директорию в корне сайта. Так мы и путь к теме скрываем, и располагаем статический контент «поближе» да поудобнее:

if(!defined('THEME_ASSETS_URL')) {
  $home_url = esc_url(home_url('/'));
  define('THEME_ASSETS_URL', $home_url.'assets', true);
} else {
  define('THEME_ASSETS_URL', get_template_directory_uri(), true);
}

В корне сайта создаем директорию /assets, и после в теме используем, например, таким образом:

wp_enqueue_style('responsive', THEME_ASSETS_URL.'/css/responsive.css');
// или
echo '<img src="'.THEME_ASSETS_URL.'/images/user.png" alt="" />';

Заменяем путь к файлу style.css темы

В дополнение к описанному выше сниппету — заменяем %site_url%/wp-content/themes/%theme_name%/style.css на %site_url%/assets/style.css:

add_filter('stylesheet_uri', 'wpi_stylesheet_uri', 10, 2);
function wpi_stylesheet_uri($stylesheet_uri, $stylesheet_dir_uri){
  return THEME_ASSETS_URL.'/style.css';
}

Подробнее под катом

Тотальная защита WordPress

В прошлом посте мы рассматривали методы повышения безопасности WordPress с помощью nginx. В данной же записи мы рассмотрим дополнительные меры противодействия сбору информации о работающей CMS (и плагинах), версии WP и некоторым типам атак на сайт.

Помогать нам будет уже не только nginx — но и fail2ban вкупе с некоторыми дополнениями и настройками самого WP.

Обозначим проблемы безопасности, которые «по умолчанию» имеют место быть:

  1. WordPress вставляет данные о своей версии в различные места генерируемого контента;
  2. Стандартные настройки его имеют довольно много потенциально слабых мест;
  3. Стандартные настройки доступа к сайту позволяют без особых трудностей собрать потенциальному взломщику довольно много информации;
  4. «Из коробки» отсутствуют какие-либо средства против перебора директорий и паролей.

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

Подробнее под катом

Плагин для WordPress «Site maintenance mode»

Один из заказчиков попросил реализовать возможность переключения сайта на WordPress в так называемый «Режим обслуживания», при котором ни модераторы, ни посетители не могут получить доступ к контенту сайта, кроме самого администратора. Так же были выставлены следующие требования:

  1. Возможность выбора категорий пользователей, для которых закрывается доступ к сайту;
  2. Настройка страницы, которая выводится конечному пользователю, с использованием HTML, JS и CSS;
  3. Наличие кнопки включения режима на прямо странице консоли, без необходимости лазить в настройки.

Подробнее под катом

Скрываем версию WordPress

Маленький но довольно полезный плагин для повышения безопасности сайта на WordPress, который всё что делает — это скрывает версию CMS, удаляя:

  • Во-первых теги <meta generator="..." /> (и иже с ними), что генерирует сам Wordoress;
  • Во-вторых из запросов к css и js файлам подстроку ?ver=%версия%, которая всё беспощадно палит.

Подробнее под катом

Отключаем RSS в WordPress

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

Подробнее под катом

Повышение безопасности WordPress с помощью nginx

Первая часть доступна по этой ссылке. Так же у данного поста имеется обновленная версия этой ссылке

Проанализировав логи одного блога на WordPress заметил, что присутствует довольно большое количество запросов к страницам, которых не существует. Посмотрев внимательнее стало очевидно, что имеет место как сбор данных как об используемой CMS, так и попытки эксплуатировать различные уязвимости плагинов, тем и самого WP.

Запрошенные страницы имели примерно следующий вид:

/wp-admin/admin-ajax.php?action=revslider_show_image&img=../wp-config.php
/wp-admin/admin-ajax.php?action=revolution-slider_show_image&img=../wp-config.php
/wp-content/themes/infocus/lib/scripts/dl-skin.php
/wp-admin/admin-ajax.php?action=showbiz_show_image&img=../wp-config.php
/wp-content/plugins/google-mp3-audio-player/direct_download.php?file=../../../wp-config.php
/wp-admin/admin-ajax.php?action=kbslider_show_image&img=../wp-config.php
/wp-content/themes/parallelus-mingle/framework/utilities/download/getfile.php?file=../../../../../../wp-config.php
/wp-content/plugins/db-backup/download.php?file=../../../wp-config.php
/wp-admin/admin-ajax.php?action=revslider_ajax_action&img=../wp-config.php
/wp-content/plugins/wp-filemanager/incl/libfile.php?path=../../&filename=wp-config.php&action=download
/wp-content/themes/churchope/lib/downloadlink.php?file=../../../../wp-config.php
/magmi/web/plugin_upload.php

Для повышения безопасности мы будем использовать nginx, путем добавления описанных ниже правил в секцию server {...} нашего блога

Подробнее под катом