10 полезных хук-хаков для WordPress

ВВЕДЕНИЕ

Хуки являются очень полезными фишками в WordPress. Они позволяют как бы «посадить» пользовательскую функцию «на крючок» функции существующей, разрешая тем самым изменять функциональность WordPress без внесения изменений в файлы ядра движка. В этой статье мы представляем Вам 10 особенно полезных, готовых к использованию хуков для WordPress, с примерами и пояснениями их исходников.

ЧТО ТАКОЕ ХУК?

Для достижения определенного эффекта нам нужно слегка изменить принцип работы WordPress. Некоторые модификации необходимо внести в файлы, которые были названы разработчиками файлами ядра – они нужны для того, чтобы WordPress работал должным образом.
Но изменение файлов ядра – плохая идея: это может создать брешь в системе безопасности блога. Также, все модификации исчезнут, как только Вы обновите движок до новой версии.
Однако, расширение функциональности все же необходимо. Для этого разработчиками был придуман Plugin API.
Хуки являются одним из главных блоков для построения плагинов. Почти каждый подключаемый плагин использует хуки для расширения функциональности WordPress.

КАК ИСПОЛЬЗОВАТЬ ХУКИ В ВАШЕМ БЛОГЕ

Пока Вы не написали свой плагин, Вы должны записать хуки в файл functions.php. Этот файл находится в директории wp-content/themes/yourtheme (где /yourtheme – директория, в которой находится текущая тема).
Вот пример, который показывает, как подключить Вашу пользовательскую функцию к функции ядра движка:

  1. add_action ( ‘publish_post’, ‘myCustomFunction’ );

В этом примере мы подключили пользовательскую функцию myCustomFunction() к функции ядра publish_post(). Функция myCustomFunction() будет выполняться при каждом выполнении функции publish_post().
Конечно, мы можем также удалить хук, используя функцию remove_action():

  1. remove_action ( ‘publish_post’, ‘myCustomFunction’ );

 

1. ОТКЛЮЧАЕМ АВТОМАТИЧСКОЕ ФОРМАТИРОВАНИЕ В WORDPRESS

 

Проблема.

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

Решение.

Просто вставьте в файл functions.php нижеследующий код:

  1. function my_formatter($content) {
  2. $new_content = »;
  3. $pattern_full = ‘{(\[raw\].*?\[/raw\])}is’;
  4. $pattern_contents = ‘{\[raw\](.*?)\[/raw\]}is’;
  5. $pieces = preg_split($pattern_full, $content, 1, PREG_SPLIT_DELIM_CAPTURE);
  6. foreach ($pieces as $piece) {
  7. if (preg_match($pattern_contents, $piece, $matches)) {
  8. $new_content .= $matches[1];
  9. } else {
  10. $new_content .= wptexturize(wpautop($piece));
  11. }
  12. }
  13. return $new_content;
  14. }
  15. remove_filter(‘the_content’, ‘wpautop’);
  16. remove_filter(‘the_content’, ‘wptexturize’);
  17. add_filter(‘the_content’, ‘my_formatter’, 99);

После того, как Вы это сделали, можете использовать тэг [raw] для того, чтобы текст поста был не отформатирован автоматически:

[raw]This text will not be automatically formatted.[/raw]

 

Объяснение кода.

Первым делом, мы создаем функцию, которая, основываясь на регулярных выражениях, находит тэг [raw] в содержании Вашего поста.
Далее, мы привязываем нашу функцию my_formatter() к функции the_content(), что означает выполнение нашей функции всякий раз, когда вызывается функция the_content().
Для того, чтобы отключить автоформатирование, мы использовали функцию remove_filter().

2. ОПРЕДЕЛЯЕМ БРАУЗЕР ПОСЕТИТЕЛЯ ПРИ ПОМОЩИ ХУКОВ

 

Проблема.

Кросс-браузерная совместимость – это наиболее распространенная проблема в web-разработке. Вы сэкономите много нервов и времени, если сможете определить браузер пользователя, зашедшего на Ваш блог, а затем создав CSS-класс для тэга body под каждый из браузеров.

Решение.

Ничего сложного: просто вставьте нижеследующий код в файл functions.php, сохраните его – все готово!

  1. add_filter(‘body_class’,‘browser_body_class’);
  2. function browser_body_class($classes) {
  3. global $is_lynx, $is_gecko, $is_IE, $is_opera, $is_NS4, $is_safari, $is_chrome, $is_iphone;
  4. if($is_lynx) $classes[] = ‘lynx’;
  5. elseif($is_gecko) $classes[] = ‘gecko’;
  6. elseif($is_opera) $classes[] = ‘opera’;
  7. elseif($is_NS4) $classes[] = ‘ns4’;
  8. elseif($is_safari) $classes[] = ‘safari’;
  9. elseif($is_chrome) $classes[] = ‘chrome’;
  10. elseif($is_IE) $classes[] = ‘ie’;
  11. else $classes[] = ‘unknown’;
  12. if($is_iphone) $classes[] = ‘iphone’;
  13. return $classes;
  14. }

После того, как Вы сохраните файл, функция автоматически будет добавлять CSS-класс, соответствующий пользовательскому браузеру, для тэга body:

  1. <body class=«home blog logged-in safari»>

 

Объяснение кода.

WordPress имеет глобальные переменные, которые возвращают true, если пользователь использует соответствующий браузер. Если пользователь использует браузер Google Chrome, то переменная $is_chrome примет значение true. Вот для чего мы и создаем функцию browser_body_class(). После этого мы присоединяем ее к WordPress функции body_class().

3. ОПРЕДЕЛЕНИЕ ТЕКСТА ПО УМОЛЧАНИЮ В РЕДАКТОРЕ TinyMCE

 

Проблема.

Многие блоггеры почти всегда используют для своего блога один и тот же формат. Сообщения в моем блоге WpRecipes.com всегда отображаются одинаково: текст, код, еще немного текста.
Можно сэкономить немало времени, если научить TinyMCE отображать какой-нибудь текст по умолчанию.

Решение.

Как всегда, решением является хук. Копируем код в файл functions.php и смотрим, как он работает.

  1. add_filter(‘default_content’, ‘my_editor_content’);
  2. function my_editor_content( $content ) {
  3. $content = «If you enjoyed this post, make sure to subscribe to my rss feed.»;
  4. return $content;
  5. }

 

Объяснение кода.

Этот код хоть и простой, но очень мощный. Просто создаем функцию, которая возвращает требуемый текст (в этом примере мы определяем текст, который спрашивает у посетителей о подписке на RSS-ленту), и присоединяем ее к WordPress-функции default_content(). Вот так.

4. ВСТАВЛЯЕМ КОНТЕНТ АВТОМАТИЧЕСКИ ПОСЛЕ КАЖДОГО ПОСТА

 

Проблема.

В большинстве блогов для вывода контента после каждого поста файл single.php, но вот беда: этот контент не будет отображаться в RSS-ленте. Хуки помогут исправить эту проблему.

Решение.

Все то же самое – просто копируем следующий код в файл fucntions.php.

  1. function insertFootNote($content) {
  2.         if(!is_feed() && !is_home()) {
  3.                 $content.= «<div class=’subscribe’>»;
  4.                 $content.= «<h4>Enjoyed this article?</h4>»;
  5.                 $content.= «<p>Subscribe to our  <a href=’http://feeds2.feedburner.com/WpRecipes’>RSS feed</a> and never miss a recipe!</p>»;
  6.                 $content.= «</div>»;
  7.         }
  8.         return $content;
  9. }
  10. add_filter (‘the_content’, ‘insertFootNote’);

 

Объяснение кода.

Суть функции insertFootNote() проста: он лишь конкатенирует желаемый текст к переменной $content, в которой хранится содержание поста.
Затем, мы присоединяем нашу функцию insertFootNote() к функции the_content().
Видите в строке 2 вот такой код:

  1. if(!is_feed() && !is_home()) {

Если Вам нужно, чтобы текст попадал в RSS-ленту, то замените предыдущий код на этот:

  1. if (!is_home()) {

Вот и все.

5. ОТКЛЮЧАЕМ СООБЩЕНИЕ С ПРОСЬБОЙ ОБНОВИТЬСЯ В ПАНЕЛИ УПРАВЛЕНИЯ WORDPRESS

 

Проблема.

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

Решение.

Просто вставьте следующий код в файл fucntions.php.

  1. if (!current_user_can(‘edit_users’)) {
  2.   add_action( ‘init’, create_function( ‘$a’, «remove_action( ‘init’, ‘wp_version_check’ );» ), 2 );
  3.   add_filter( ‘pre_option_update_core’, create_function( ‘$a’, «return null;» ) );
  4. }

После того, как Вы сохраните файл functions.php, сообщения Вы больше не увидите.

Объяснение кода.

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

6. ОТКЛЮЧАЕМ АВТОСОХРАНЕНИЕ ПОСТОВ

 

Проблема.

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

Решение.

Для того, чтобы отключить автосохранение поста, просто откройте файл functions.php и вставьте в него следующий код.

  1. function disableAutoSave(){
  2.     wp_deregister_script(‘autosave’);
  3. }
  4. add_action( ‘wp_print_scripts’, ‘disableAutoSave’ );

 

Объяснение кода.

И вновь, ничего сложного: мы просто создаем функцию, которая отключается автосохранение и привязываем ее к WordPress-функции wp_print_scripts().

7. ИЗБАВЛЯЕМСЯ ОТ ПОВТОРЯЮЩЕГОСЯ КОНТЕНТА НА СТРАНИЦАХ С КОММЕНТАРИЯМИ

 

Проблема.

Повторяющийся контент эта довольно распространенная SEO-проблема.
Введенная в WordPress версии 2.7 система разбиения комментариев на страницы эту проблему не решает.
Для предупреждения повторяющегося контента в комментариях будем использовать атрибут rel=«canonical».

Решение.

Копируем следующий код и вставляем его в файл functions.php.

  1. function canonical_for_comments() {
  2. global $cpage, $post;
  3. if ( $cpage > 1 ) :
  4. echo «\n«;
  5.    echo «<link rel=’canonical’ href='»;
  6.    echo get_permalink( $post->ID );
  7.    echo «‘ />\n«;
  8.  endif;
  9. }
  10. add_action( ‘wp_head’, ‘canonical_for_comments’ );

 

Объяснение кода.

Сначала, мы создаем функцию, которая добавляет к каждой странице с комментариями, кроме первой, тэг link с атрибутом rel=«canonical». Затем, присоединяем эту функцию к WordPress-функци wp_head().

8. ПОЛУЧЕНИЕ ПОСТА ИЛИ СТРАНИЦЫ В КАЧЕСТВЕ PHP-ПЕРЕМЕННОЙ

 

Проблема.

Возможность получить текущий пост или целую страницу в качестве PHP переменной – действительно крутая вещь. Скажем, Вы можете заменять некоторые части контента при помощи функции str_replace() или делать с ним еще что-нибудь.

Решение.

И снова ничего сложного. Делаем все то же самое: вставляем следующий код в файл functions.php.

  1. function callback($buffer) {
  2. // modify buffer here, and then return the updated code
  3. return $buffer;
  4. }
  5. function buffer_start() {
  6. ob_start(«callback»);
  7. }
  8. function buffer_end() {
  9. ob_end_flush();
  10. }
  11. add_action(‘wp_head’, ‘buffer_start’);
  12. add_action(‘wp_footer’, ‘buffer_end’);

 

Объяснение кода.

Для того, чтобы этот хак работал, необходимы три функции:

  • callback(): эта функция возвращает страницу целиком как переменную $buffer. Вы можете модифицировать ее как угодно, например, при помощи регулярных выражений;
  • buffer_start(): эта функция начинает буферизацию. Ее мы присоединяем к функции wp_head();
  • buffer_end(): эта функция очищает буфер. Ее мы присоединяем к функции wp_footer().

 

9. ИСПОЛЬЗУЕМ ХУКИ И CRON ДЛЯ СОБЫТИЙ ПО РАСПИСАНИЮ

 

Проблема.

Вы, наверное, уже знаете, что WordPress может использовать события по расписанию. К примеру, можно публиковать посты в конкретное, установленное заранее, время. Используя хуки и wp-cron, мы можем запросто задать расписание для нашего собственного события. В следующем примере мы заставим блог отправлять нам сообщения на e-mail один раз каждый час.

Решение.

Вставляем следующий код в файл functions.php.

  1. if (!wp_next_scheduled(‘my_task_hook’)) {
  2. wp_schedule_event( time(), ‘hourly’, ‘my_task_hook’ );
  3. }
  4. add_action( ‘my_task_hook’, ‘my_task_function’ );
  5. function my_task_function() {
  6. wp_mail(‘you@yoursite.com’, ‘Automatic email’, ‘Hello, this is an automatically scheduled email from WordPress.’);
  7. }

 

Объяснение кода.

Первое, что мы сделаем, конечно, — это создадим функцию, которая будет выполнять требуемое действие. В этом примере эта функция называется my_task_function() и она просто отправляет письмо на указанный e-mail адрес.
Для того, чтобы запланировать выполнение этой функции, мы будем использовать функцию wp_schedule_event(). Последним аргументом, передаваемым ей, будет наш хук, поэтому мы «цепляем» нашу функцию my_task_function() к my_task_hook.

10. СПИСОК ВСЕХ «ХУКНУТЫХ» ФУНКЦИЙ

 

Проблема.

Когда что-то идет не так, здорово может пригодиться список всех «хукнутых» функций.

Решение.

Как и все предыдущие фрагменты кода следующий также необходимо вставить в файл functions.php. Только не забудьте удалить его после использования. Если Вы этого не сделаете, то сообщения будут появляться и после отладки.

  1. function list_hooked_functions($tag=false){
  2.  global $wp_filter;
  3.  if ($tag) {
  4.   $hook[$tag]=$wp_filter[$tag];
  5.   if (!is_array($hook[$tag])) {
  6.   trigger_error(«Nothing found for ‘$tag‘ hook», E_USER_WARNING);
  7.   return;
  8.   }
  9.  }
  10.  else {
  11.   $hook=$wp_filter;
  12.   ksort($hook);
  13.  }
  14.  echo ‘<pre>’;
  15.  foreach($hook as $tag => $priority){
  16.   echo «<br />&gt;&gt;&gt;&gt;&gt;\t<strong>$tag</strong><br />»;
  17.   ksort($priority);
  18.   foreach($priority as $priority => $function){
  19.   echo $priority;
  20.   foreach($function as $name => $properties) echo «\t$name<br />»;
  21.   }
  22.  }
  23.  echo ‘</pre>’;
  24.  return;
  25. }

После того, как Вы вставите этот код в файл functions.php, вызовите функцию list_hooked_functions(). Она и покажет Вам список всех «хукнутых» функций.

  1. list_hooked_functions();

 

Объяснение кода.

Данный код выясняет, передается ли имя хука в качестве аргумента функции. Если передается, то на экран выводится имя хука. Также можно посмотреть хуки только для определенной функции:

  1. list_hooked_functions(‘wp_head’);

Дешево и сердито или Зачем разрабатывать сайт с нуля, если есть WordPress?

Разработка уникального сайта достаточно дорогое удовольствие, доступное далеко не каждой компании, не говоря уже про начинающих бизнесменов. Сама разработка и тем более программирование уникальных модулей обойдется совсем не дешево. По данным компании Goal Europe, стоимость одного человеко-часа разработчика в Америке составляет около $40-60, в России (Москве и Санкт-Петербурге) от $20 до $30, в Украине этот показатель держится на уровне $20-25 (Киев), а в регионах не превышает $15 в час. Помимо разработчиков необходим еще как минимум UI/UX дизайнер. Стоимость опытного UI/UX дизайна сопоставима со стоимостью квалифицированного разработчика. Каждый дизайнер имеет свой стиль: кто-то любит чистые и легкие интерфейсы, кто-то пытается максимально разбавить функциональный сайт всевозможной графикой, а некоторые считают, что нет ничего лучше флэта и упорно продвигают это дизайн направление. В этой статье речь пойдет о том, как не потеряться во всех нюансах и разработать функциональный и эффективный сайт?

Но сегодня для того, чтобы начать свой бизнес в интернете не нужно заказывать услуги таких дорогостоящих специалистов, как разработчики и UI/UX дизайнеры. Отличная альтернатива разработке индивидуального сайта – это адаптация шаблонного сайта. Это значительно дешевле, проще и быстрее. Но как определиться, с какой системой работать и какой шаблон выбрать?

Существует масса шаблонов написанных для различных систем управления контентом CMS (англ. Content management system), таких как WordPress, Drupal, Joomla, Magenta и прочие. По данным ресурса builtwith половина сайтов в интернете сделаны на базе WordPress.

Почему именно WordPress?

Все очень просто – нет конкретной причины, здесь играет сумма факторов, таких как:
простота использования
бесплатное использование
удобство и масштабируемость системы
обширная документация
большое сообщество поддержки
постоянное обновление системы
множество разнообразных плагинов и шаблонов
разноплановость применения
адаптивность под мобильные платформы
дружелюбность к SEO
и множество других преимуществ

Среди основных достоинств WordPress платформы можно выделить:

Абсолютно бесплатная CMS система

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

Множество плагинов

Возможности WordPress можно расширить с помощью бесплатных или платных плагинов. Более того, подключая плагин вы получаете постоянное обновление и поддержку. За относительно небольшую стоимость платных плагинов можно постоянно поддерживать на должном уровне техническую составляющую сайта за счет обновлений самого WordPress и плагинов. Среди самых распространенных плагинов для вордпресс:
WooCommerce – плагин для создания интернет-магазина на базе WordPress.
WPML – популярный плагин для создания многоязычного сайта.
Contact Form 7 – плагин для создания контактных форм.
NextGEN Gallery – плагин для создания и управлении галереями.
Yoast SEO – плагин для оптимизации SEO данных сайта.

Существует огромное разнообразие других бесплатных и платных плагинов, некоторые из них можно найти на официальном сайте WordPress.

Адаптивность

Практически все доступные шаблоны для WordPress являются адаптивными, это подразумевает, что они будут отлично выглядеть на экранах любого мобильного девайса или планшета. Это очень важно для конечного потребителя, поскольку трафик с мобильных устройств растет день ото дня. Совсем не хочется, чтобы посетители уходили с сайта из-за того, что не могут получить корректное отображение информации на своем телефоне. К тому же, если разрабатывать уникальный сайт, то разработчики обязательно возьмут дополнительные деньги за проработку адаптивности.

Дружелюбность к SEO

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

Огромное сообщество поддержки

Распространенность и популярность WordPress влечет за собой положительные нюансы: множество необходимой информации на большом количестве бесплатных ресурсов, посвященных этой платформе. Кроме того, сам WordPress предоставляет отличную документацию.
Список форумов и блогов, посвященных WordPress:
wordpress.org/support
wordpress.com
wordpress.co.ua
wpcafe.org
www.siteground.com/tutorials/wordpress
www.wp-info.ru
wordpressinside.ru
oddstyle.ru
www.wpbeginner.com
ithemes.com
forums.envato.com/tags/wordpress
www.wp101.com

Множество относительно недорогих разработчиков

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

Платные и бесплатные шаблоны

Что касается шаблонов, так называемых тем, то их разнообразие поражает даже самое яркое воображение. Сегодня существует множество маркетплейсов с тысячами разнообразных темплейтов для WordPress. Среди лидеров рынка такие ресурсы, как:
www.themeforest.net
www.templatemonster.com
themeisle.com
creativemarket.com

Маркетплейсы

Однозначным лидером среди ресурсов с WordPress темами является Themeforest, как по количеству шаблонов, так и по их качеству. Общее количество WordPress шаблонов на маркете приблизительно 6,5 тысяч.

А постоянное повышение требований к шаблонам позволяет удержать планку на весьма высоком уровне. Модераторы themeforest ориентированы на визуальную составляющую шаблона, важен визуальный wow-эффект. Некоторые шаблоны имеют награды престижных дизайн конкурсов, таких как:
www.cssdesignawards.com
www.awwwards.com
www.csswinner.com
welovewp.com
flatui.com
builtwithbootstrap.com

Но при этом функциональность шаблона и чистота кода также являются важными параметрами для попадания шаблона на themeforest. Соответственно, комплекс высоких требований к товарам, размещенным в каталоге, позволяет поддерживать качество на должном уровне. Вот пример долгого и мучительного процесса утверждения WP шаблона на themeforest.

Бесплатные или платные шаблоны?

Однозначно среди бесплатных шаблонов есть весьма достойные. Однако если задача сделать стильный и функциональный сайт, то рекомендация выбирать среди платных шаблонов. Средняя стоимость платных тем составляет от 29 до 64 долларов. Однако за эти деньги в большинстве случаев включены некоторые платные плагины. Самые часто используемые плагины в платных темах – это Visual Composer и Slider Revolution. Только стоимость этих двух плагинов уже равна стоимости платного шаблона. А некоторые премиум темы включают в себя намного больше плагинов. По мимо всего, за деньги, потраченные на шаблон, обеспечена первоклассная поддержка: специалисты технической поддержки помогут разобраться с разнообразными возникшими вопросами. Возможности кастомизации платных шаблонов достаточно широки. Например, мультипурпоз темы отлично подойдут как для корпоративного сайта большой компании, так и для личного сайта-порфолио. Ну и, конечно же, существуют узконаправленные шаблоны заточенные под конкретные направления деятельности: например, сайты, посвященные свадебной тематике, или сайты юридических компаний.

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

Проекты на WordPress: советы по оптимизации

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

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

Подробных инструкций по установке и настройке WordPress в Интернете опубликовано немало. В этой статье мы бы хотели затронуть вопросы, которым в большинстве публикаций о WordPress не уделяется достаточно внимания. Мы расскажем о том, как оптимизировать работу сайтов на WordPress, а также дадим ряд рекомендаций по повышению уровня безопасности и стабильности работы. Во всех примерах используется Ubuntu 12.04.

Настраиваем СУБД

Выбор СУБД

Как известно, для работы WordPress необходима СУБД MySQL. В последнее время широкое распространение получили альтернативные реализации (форки) этой СУБД, наиболее популярными из которых являются Percona Server и MariaDB. Во многих инструкциях по установке, опубликованных в Интернете, рекомендуется использовать MariaDB.

Мы же рекомендуем использовать Percona Server, так как этот форк по сравнению со стандартным MySQL является более производительным и стабильным. Кроме того, Percona обладает более широкими возможностями для сбора системной статистики.

Чтобы установить Percona на сервер, нужно сначала импортировать ключи:
$ apt-key adv —keyserver keys.gnupg.net —recv-keys 1C4CBDCDCD2EFD2A

Затем нужно добавить в файл /etc/apt/sources.list следующие репозитории:
deb http://repo.percona.com/apt precise main
deb-src http://repo.percona.com/apt precise main

И выполнить команду:
$ sudo apt-get update

После этого можно устанавливать percona-server при помощи стандартного менеджера пакетов:
$ sudo apt-get install percona-server-server percona-server-client

Выбираем движок: MyISAM или InnoDB?

Самыми популярными движками в MySQL-базах являются MyISAM и InnoDB. Если движок выбран неправильно, то возникают проблемы с производительностью и консистентностью.

Рассмотрим особенности этих движков более подробно.

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

Несомненными преимуществами этого движка являются также полнотекстовый поиск и компрессия. Формат данных в MyISAM — кроссплатформенный, что позволяет без проблем переносить данные с одного сервера на другой путем простого копирования бинарных файлов (таблиц) баз данных.

InnoDB используется в современных версиях MySQL как движок по умолчанию.
В отличии от MyISAM InnoDB поддерживает транзакции и внешние ключи. В Percona Server используется собственный движок — XtraDB, полностью совместимый с InnoDB. Данные в InnoDB/XtraDB кэшируются. Когда большая часть данных считывается из кэша, производительность InnoDB/XtraDB в разы выше, чем у MyISAM.

Статей, посвященных сравнению MyISAM с InnoDB/XtraDB, а также MySQL c его форками, опубликовано немало (см., в частности, тест производительности здесь). Мы не будем вдаваться в теоретические подробности и ограничимся практическим советом: MyISAM нужно выбирать только в случаях, когда нужен полнотекстовый поиск. Со всеми остальными задачами прекрасно справятся InnoDB/XtraDB. Кстати, в MySQL/Percona Server 5.6+ полнотекстовый поиск для InnoDB уже поддерживается.

Оптимизация конфигурации СУБД

По мере развития сайта количество данных в БД будет расти, и возникнет необходимость изменений настроек базы данных. Чтобы обеспечить оптимальную работу сайта, желательно регулярно проверять, насколько оптимально настроена действующая конфигурация MySQL. Такую проверку проще всего осуществлять с помощью специальных скриптов, самым известным и популярным из которых является mysqltuner.pl. Его можно скачать при помощи следующих команд:
$ wget https://raw.githubusercontent.com/major/MySQLTuner-perl/master/mysqltuner.pl
$ chmod +x ./mysqltuner.pl
$ ./mysqltuner.pl

Этот скрипт собирает статистику MySQL и выдает рекомендации по улучшению существующих настроек.

Настраиваем веб-сервер

Параметры Apache

Настройки apache хранятся в файле /etc/apache2/apache2.conf

В конфигурационном файле Apache имеется такой параметр, как max_clients — максимальное количество процессов, запускаемых для параллельной обработки клиентских запросов. На первый взгляд может показаться, что для этого параметра нужно устанавливать максимальное значение. В реальной практике, однако, все бывает по-другому.

Допустим, один процесс Apache может потребить 20 Мб оперативной памяти. Если для параметра max_clients выставлено значение 200, то при пиковой нагрузке под все процессы потребуется 200×20 Мб = 4Гб памяти — и это только под Apache! В результате нехватки памяти даже самые простые запросы будут выполняться крайне медленно. И программное обеспечение на сервере может перестать работать.

Поэтому слишком большое значение параметра max_clients выставлять не желательно. Если количество запросов превысит установленное значение, то все эти запросы будут поставлены в очередь и обработаны, как только освободятся занятые процессы.

В целях повышения производительности рекомендуется также отключить keepalive-соединения, исправив соответствующую строку в конфигурационном файле:
KeepAlive off

Backend+Frontend = Apache +Nginx

Любой более или менее высоконагруженный веб-проект должен иметь многоуровневую архитектуру (об этом мы уже писали). Для большинства проектов на базе WordPress вполне подойдет двухуровневая архитектура Backend — Frontend. Мы рекомендуем использовать следующую связку: в качестве бэкенда Apache, в качестве фронтенда — Nginx.

Впрочем, возможен и другой вариант — php-fpm в качестве бэкенда, а в качестве фронтенда — все тот же Nginx (см. инструкции по настройке, например, здесь и здесь). Во многих публикациях утверждается, что связка php-fpm+Nginx работает быстрее или потребляет намного меньше памяти. С этими утверждением, однако, вряд ли можно однозначно согласиться.

К тестам, опубликованным в Интернете, нужно относиться со здоровой долей скептицизма: нередко php-fpm+Nginx показывает лучшие результаты лишь потому, что Apache не был настроен должным образом (см., например, отчет о тестировании и его критический разбор; см. также любопытную дискуссию здесь). На основании собственного опыта можем сказать, что для большинства проектов на WordPress комбинация Apache+Nginx вполне подойдет. Выбор решения должен основываться не только и столько на приросте производительности, сколько на специфке решаемых задач и соображениях технологического удобства. А Apache, на наш взгляд, отличается большей гибкостью конфигурирования. Он может использоваться и как отдельный веб-сервер, и как бэкенд для Nginx, и как фронтенд для php-fpm.

Общая схема работы выглядит так: Nginx принимает запросы от пользователей, которые затем либо передает Apache, либо обрабатывает самостоятельно. Apache будут передаваться запросы, связанные с обработкой динамического контента — например, php-скриптов. Nginx самостоятельно обрабатывает запросы на отдачу статики — например, графики, JS, CSS, текстовых файлов, XML-файлов.

Apache обработав запрос и передав содержимое Nginx, отключается и переходе к обработке других запросов. Благодаря этому работа существенно ускоряется (что немаловажно, например, при медленном интернет-подключении).

Кроме того, раздачу динамических запросов можно ускорить с помощью сервера Memcached (см., например, инструкцию по установке и настройке здесь).

Обеспечиваем безопасность

Для расширения функциональности WordPress используются многочисленные плагины. В этих плагинах постоянно обнаруживаются различные уязвимости, и из-за этого некоторые системные администраторы относятся к ней несколько предвзято. Сайты на базе WordPress действительно часто становятся мишенью для атак, но со временем разработчики совершенствуют плагины, устраняя существующие бреши безопасности. Ниже мы дадим еще несколько советов по настройке WordPress, с помощью которых можно сделать сайт менее уязвимым.

Защититесь от вредоносных программ и уязвимостей в скриптах на сервере, на котором установлен WordPress. Мы рекомендуем использовать сканер ClamAV+Maldet. С инструкцией по установке и настройке AV можно ознакомиться здесь. Для поиска уязвимостей можно также воспользоваться программой WPScan.

Измените префикс таблиц в базе данных. По умолчанию в базе данных WordPress установлен префикс «wp_». Это упрощает использование уязвимостей с MySQL-инъекцией: если известно имя таблицы, в нее гораздо проще вставить вредоносный код, изменить в ней информацию или вообще удалить. В новых версиях WordPress появилась возможность выбора префикса при установке.

Если вы используете раннюю версию WordPress, то изменить префикс можно с помощью специализированных плагинов. Наиболее известным и популярным является Prefix Changer. Следует, однако, учесть, что многие из этих плагинов не всегда работают корректно, поэтому перед их использованием рекомендуется сохранить резервную копию базы данных.

Переместите файл wp-config.php. В файле wp-config.php хранятся важные параметры настройки WordPress, которую желательно защитить от несанкционированного доступа. По умолчанию этот файл сохраняется в корневом каталоге, но его можно переместить на каталог выше. Не обнаружив файла wp-config.php в корневом каталоге, WordPress будет искать его автоматически.

Получите SSL-сертификат и включите SSL-шифрование. Для этого в файл wp-config нужно добавить следующие строки:
/* Enable SSL Encryption */
define(‘FORCE_SSL_LOGIN’, true);
define(‘FORCE_SSL_ADMIN’, true);

Удалите информацию о версии WordPress. Если злоумышленник узнает, что вы используете устаревшую версию WordPress, то он может воспользоваться имеющимися уязвимостями и взломать ваш сайт. Поэтому информацию о версии лучше удалить.

Во-первых, нужно удалить файл: ваш_сайт/readme.html, из которого можно без труда узнать, какую версию WordPress вы используете.

Об используемой версии можно также узнать из файла header.php, который находится в папке с темой. Он содержит следующую строку:

Можно удалить всю эту строку целиком. Если в файле header.php вашей темы оформления нет такой строки, то, скорее всего она вставляется автоматически WordPress’ом при вызове функции wp_head(). В таком случае удалить информацию о версии из секцииможно, добавив в файл functions.php следующий код:
remove_action(’wp_head’, ’wp_generator’);
function selectel_remove_version() {
return ’’;
}
add_filter(’the_generator’, ’selectel_remove_version’);

Измените ключи безопасности. В упомянутом выше файле wp-config.php есть раздел с ключами безопасности. Выглядит он так:
define(’AUTH_KEY’, ’’);
define(’SECURE_AUTH_KEY’, ’’);
define(’LOGGED_IN_KEY’, ’’);
define(’NONCE_KEY’, ’’);

Ключи используются для хэширования паролей. Очень часто на этот раздел не обращают внимания даже опытные пользователи. Между тем изменить ключи безопасности довольно просто: достаточно зайти на страницу https://api.wordpress.org/secret-key/1.1 и скопировать сгенерированные ключи в файл wp-config.php. Эту процедуру достаточно осуществить всего один раз во время первичной настройки сайта.

Ограничьте доступ к папкам wp-content и wp-includes. Из соображений безопасности рекомендуется закрыть доступ к содержимому папок wp-content и wp-includes. Нужно закрыть доступ к любым файлам, кроме графики, JS и СSS. Для этого нужно в каждой папке создать файл .htaccess и поместить в него такой код:
Order Allow,Deny
Deny from all
Allow from all

Создайте пустой файл wp-content/plugins/index.html. Благодаря этому станет недоступной информация о том, какие плагины вы используете. В плагинах WordPress могут содержаться уязвимости, и этим могут воспользоваться злоумышленники.

Чтобы сделать листинг недоступным, можно также добавить в файл .htaccess, хранящийся в папке с плагинами, следующую строку:
Options -Indexes

Ограничьте доступ к папке wp-admin.

Чтобы ограничить доступ, нужно в этой папке создать файл .htaccess и поместить в него следующий код:
AuthUserFile /dev/null
AuthGroupFile /dev/null
AuthName «Access Control»
AuthType Basic
order deny,allow
deny from all
# указываем, например. IP-адрес домашнего компьютера
allow from
# здесь указываем адрес один или несколько IP-адресов, с которых мы будем писать в блог на работе
allow from
allow from

Ограничивать доступ определенным набором IP-адресов не всегда удобно. Можно настроить доступ к папке wp-admin только по паролю. Для этого нужно создать файл .htauth:
$ htpasswd -c /home/yourdirectory/.htauth

И поместить его на один уровень выше директории /public_html/
Затем нужно создать в папке wp-admin файл .htaccess и поместить в него следующий код:
AuthName «Admins Only»
AuthUserFile /home/yourdirectory/.htauth
AuthGroupFile /dev/null
AuthType basic
require user <имя пользователя>

Заключение

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

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

Под прессом. Ломаем и защищаем WordPress своими руками

WordPress — это удобная блог-платформа для публикации статей и управления ими, на которой базируется огромное число различных сайтов. Из-за своей распространенности эта CMS уже давно является лакомым куском для злоумышленников. К сожалению, базовые настройки не обеспечивают достаточного уровня защиты, оставляя многие дефолтные дырки незакрытыми. В этой статье мы пройдем типичным путем «типового» взлома сайта на WordPress, а также покажем как устранить выявленные уязвимости.

Введение

На сегодняшний день WordPress среди систем управления контентом популярнее всего. Его доля составляет 60,4% от общего числа сайтов, использующих CMS-движки. Из них, согласно статистике, 67,3% сайтов базируется на последней версии данного программного обеспечения. Между тем за двенадцать лет существования веб-движка в нем было обнаружено 242 уязвимости различного рода (без учета уязвимостей, найденных в сторонних плагинах и темах). А статистика сторонних дополнений выглядит еще печальней. Так, компания Revisium провела анализ 2350 русифицированных шаблонов для WordPress, взятых из различных источников. В результате они выяснили, что более половины (54%) оказались зараженными веб-шеллами, бэкдорами, blackhat seo («спам») ссылками, а также содержали скрипты с критическими уязвимостями. Поэтому устраивайся поудобней, сейчас мы будем разбираться, как провести аудит сайта на WordPress и устранить найденные недостатки. Использовать будем версию 4.1 (русифицированную).

Индексирование сайта

Первым этапом любого теста обычно бывает сбор информации о цели. И тут очень часто помогает неправильная настройка индексирования сайта, которая позволяет неавторизованным пользователям просматривать содержимое отдельных разделов сайта и, например, получить информацию об установленных плагинах и темах, а также доступ к конфиденциальным данным или резервным копиям баз данных. Чтобы проверить, какие директории видны снаружи, проще всего воспользоваться Гуглом. Достаточно выполнить запрос Google Dorks типа site:example.com intitle:«index of» inurl:/wp-content/. В операторе inurl: можно указать следующие директории:

/wp-content/
/wp-content/languages/plugins
/wp-content/languages/themes
/wp-content/plugins/
/wp-content/themes/
/wp-content/uploads/

Если сможешь просмотреть /wp-content/plugins/, следующий шаг по сбору информации об установленных плагинах и их версиях значительно упрощается. Естественно, запретить индексирование можно с помощью файла robots.txt. Так как по умолчанию он не включен в установочный пакет WordPress, его необходимо создать самому и закинуть в корневую директорию сайта. Мануалов по созданию и работе с файлом robots.txt довольно много, поэтому оставлю эту тему для самоподготовки. Приведу лишь один из возможных вариантов:

User-Agent: *
Disallow: /cgi-bin
Disallow: /wp-login.php
Disallow: /wp-admin/
Disallow: /wp-includes/
Disallow: /wp-content/
Disallow: /wp-content/plugins/
Disallow: /wp-content/themes/
Disallow: /?author=*
Allow: /

Если в файлах, хранящихся в папке uploads, имеются сведения конфиденциального характера, добавляем к этому списку строчку: Disallow: /wp-content/uploads/. С другой стороны, в файле robots.txt не рекомендуется размещать ссылки на директории, которые были созданы специально для хранения чувствительной информации. Иначе этим самым ты облегчишь злоумышленнику задачу, так как это первое место, куда обычно все заглядывают в поисках «интересненького».

Определение версии WordPress

Еще один важный шаг — идентификация версии CMS. Иначе как подобрать подходящий сплоит? Существует три быстрых способа для определения используемой на сайте версии WordPress:

1. Найти в исходном коде страницы. Она указана в метатеге generator: /> или же в тегах : .
2. Найти в файле readme.html (рис. 1), который входит в состав установочного пакета и находится в корне сайта. Файл может иметь и другие названия типа readme-ja.html.
3. Найти в файле ru_RU.po (рис. 2), который входит в состав установочного пакета и расположен по адресу /wp-content/languages/: «Project-Id-Version: WordPress 4.1.1\n».

Рис. 1. Версия WordPress в файле readme.html

Рис. 2. Подсматриваем версию WordPress в файле ru_RU.po

Один из вариантов защиты в данном случае — ограничить доступ к файлам readme.html и ru_RU.po с помощью .htaccess.

Автоматизация процесса тестирования

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

Nmap:

— определение версии и темы с помощью скрипта http-wordpress-info

nmap -sV —script http-wordpress-info

— подбор пароля по словарям

nmap -p80 —script http-wordpress-brute —script-args ‘userdb=users.txt,passdb=passwords.txt’ example.com

Metasploit:

— модуль для определения версии: auxiliary/scanner/http/wordpress_scanner;
— модуль для определения имени пользователя auxiliary/scanner/http/wordpress_login_enum.

WPScan:

— перечисление установленных плагинов: wpscan —url www.exmple.com —enumerate p;
— перечисление установленных тем: wpscan —url www.exmple.com —enumerate t;
— перечисление установленного timthumbs: wpscan —url www.example.com —enumerate tt;
— определение имени пользователя: wpscan —url www.example.com —enumerate u;
— подбор пароля по словарю для пользователя admin: wpscan —url www.example.com —wordlist wordlist.txt —username admin;
— подбор пароля с использованием связки имя пользователя / пароль с числом потоков, равным 50: wpscan —url www.example.com —wordlist wordlist.txt —threads 50.

Определение установленных компонентов

Теперь давай соберем информацию об установленных плагинах и темах независимо от того, активированы они или нет. Прежде всего такую информацию можно выудить из исходного кода HTML-страницы, например по JavaScript-ссылкам, из комментариев и ресурсов типа CSS, которые подгружаются на страницу. Это самый простой способ получения информации об установленных компонентах. Например, строчки ниже указывают на используемую тему twentyeleven:

Далее, HTTP-заголовки, такие как X-Powered-By, могут указывать на наличие плагина (например, на плагин W3 Total Cache).
Так как информация о плагинах не всегда отображается в исходном коде HTML-страницы, то обнаружить установленные компоненты можно с помощью утилиты WPScan (см. врезку). Только не забывай, что перебор путей плагинов зафиксируется в логах веб-сервера.
Получив данные об установленных компонентах, уже можно приступать к поиску уязвимостей своими силами либо найти общедоступные эксплойты на ресурсах типа rapid7 или exploit-db.

Определение имени пользователей

По умолчанию в WordPress каждому пользователю присваивается уникальный идентификатор, представленный в виде числа: example.com/?author=1. Перебирая числа, ты и определишь имена пользователей сайта. Учетная запись администратора admin, которая создается в процессе установки WordPress, идет под номером 1, поэтому в качестве защитной меры рекомендуется ее удалить.

Брутфорс wp-login

Рис. 3. Ошибки при аутентификации пользователя

Зная имя пользователя, можно попробовать подобрать пароль к панели администрирования. Форма авторизации WordPress на странице wp-login.php весьма информативна (рис. 3), особенно для злоумышленника: при вводе неправильных данных появляются подсказки о неверном имени пользователя или пароле для конкретного пользователя. Разработчикам известно о данной особенности, но ее решили оставить, так как подобные сообщения удобны для пользователей, которые могли забыть свой логин и/или пароль. Проблему подбора пароля можно решить, используя стойкий пароль, состоящий из двенадцати и более символов и включающий буквы верхнего и нижнего регистра, числа и спецсимволы. Или же, например, при помощи плагина Login LockDown.

Security-плагины для WordPress

— Login LockDown — ограничивает количество неудачных попыток авторизации;
— Revisium WordPress Theme Checker — ищет типичные вредоносные фрагменты в темах WordPress;
— Sucuri Security — проводит мониторинг и обнаружение вредоносного кода;
— iThemes Security (бывший Better WP Security) — многофункциональный плагин для защиты WordPress;
— BackUpWordPress — делает резервное копирование файлов и БД;
— Google Captcha (reCAPTCHA) — устанавливает капчу при регистрации, авторизации, восстановлении паролей и в форме комментариев.

Заливаем Shell

После того как мы сбрутили пароль, ничто не мешает залить шелл на скомпрометированный веб-ресурс. Для этих целей вполне сгодится фреймворк Weevely, который позволяет генерировать шелл в обфусцированном виде, что делает его обнаружение довольно сложным. Чтобы не вызывать подозрения, полученный код можно вставить в любой файл темы (например, в index.php) через редактор темы консоли WordPress. После чего с помощью того же Weevely можно подключиться к машине жертвы и вызывать различные команды:

python weevely.py http://test/index.php Pa$$w0rd

[+] weevely 3.1.0

[+] Target:test
[+] Session: _weevely/sessions/test/index_0.session

[+] Browse the filesystem or execute commands starts the connection
[+] to the target. Type :help for more information.

weevely> :help

Подключаем .htaccess

Для запрета доступа к чувствительной информации лучше воспользоваться файлом .htaccess — это файл конфигурации, используемый в Apache Web Server. Рассмотрим возможности этого файла с точки зрения безопасности. С его помощью можно: запретить доступ к директориям и файлам, заблокировать различные SQL-инъекции и вредоносные скрипты. Для этого стандартный файл .htaccess для CMS WordPress 4.1 нужно немного расширить. Чтобы закрыть список файлов и папок, добавляем:

Options +FollowSymLinks -Indexes

RewriteCond %{QUERY_STRING} base64_encode[^(]*\([^)]*\) [OR] заблокирует ссылки, содержащие кодировку Base64. Избавиться от ссылок, содержащих тег