Отключить CSS/JS в теме WordPress

В процессе доработки или оптимизации темы оформления WordPress, может возникнуть необходимость отключить загрузку неиспользуемых CSS или JS-файлов внутри HTML-документа. Как правило, в данной ситуации ограничиваются самым простым вариантом решения данного вопроса — удалением из шаблона функций wp_enqueue_style или wp_enqueue_skript, отвечающих за регистрацию стилей и скриптов в WordPress.

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

В WordPress можно удалять из очереди и отменять регистрацию стилей и скриптов при помощи функций:

  • wp_deregister_script()
  • wp_deregister_style()
  • wp_dequeue_script()
  • wp_dequeue_style()

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

В большинстве случаев, чтобы отключить CSS и JS файлы рекомендуется использовать wp_dequeue_style и wp_dequeue_script. Для этого необходимо добавить код в файл functions.php вашего WordPress шаблона.

Рассмотрим использование функции на примере отключения загрузки шрифтов Google Web Fonts:

function wp_dequeue_google_fonts() {
	wp_dequeue_style( 'twentyfifteen-fonts' );
}
add_action( 'wp_enqueue_scripts', 'wp_dequeue_google_fonts', 20 );

В примере выше: в качестве параметра для работы функции wp_dequeue_style() мы указали идентификатор twentyfifteen-fonts ранее зарегистрированного CSS.

Имя идентификатора можно найти в коде функции подключения скрипта wp_enqueue_script().

Следует отметить, для отключения CSS или JS файлов в теме WordPress, вызов функции wp_dequeue_google_fonts должен происходить после вызова функции wp_enqueue. Поэтому для отключения CSS или JS файлов в теме WordPress, лучше всего использовать код функции в конце файла functions.php.

Отображаем похожие записи в WordPress

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

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

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

В зависимости от ваших потребностей, скрипт можно изменить под свои нужды: изменить количество отображаемых ссылок (строка 1), задать параметры сортировки (строка 18). По умолчанию похожие записи отображаются в случайном порядке, вы можете изменить параметры сортировки на одно из значений ниже:
rand — случайно;
title — по названию;
date — по дате публикации;
modified — по дате последнего изменения.

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

<?php do_related_posts(); ?>

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

.related-posts {
   /* ... */
}
.related-posts h4 {
   /* ... */
}
.related-posts ul li {
   /* ... */
}
.related-posts a {
   /* ... */
}

Настройка Nginx fastcgi_cache для WordPress

Как показывает опыт, только лишь с помощью утилиты ApacheBench можно положить WordPress на среднестатистическом VPS. Проблема заключается том, что в большинстве случаев PHP является узким местом в работе веб-сервера. Использование OPCache позволяет значительно ускорить работу PHP скриптов, но это не изменить ситуацию, когда при высокой посещаемости скрипты будут создавать серьезную нагрузку на CPU.

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

Главный недостаток использования fastcgi_cache — отсутствие встроенного механизма для удаления из кэша потерявших свою актуальность страниц. Зато данная проблема легко решается за счет использования специального плагина для WordPress, который при наличии изменений на сайте будет давать команду Nginx очищать кэш.

Для начала необходимо убедится, что на сервере установлен Nginx с поддержкой fastcgi_cache_purge. Для этого нужно выполнить следующую команду:

nginx -V 2>&1 | grep nginx-cache-purge -o

В результате выполнения команды вы должны увидеть следующее:

nginx-cache-purge

В противном случае необходимо установить Nginx c поддержкой с поддержкой модуля fastcgi_cache_purge. В зависимости от потребностей вашего сайта, можно вообще отказаться от данной функции. Для этого необходимо убрать из конфигурационного файла Nginx секцию location ~ /purge(/.*).

Для того чтобы дать сигнал Nginx какая страница была изменена, мы будем использовать WordPress плагин Nginx Helper. После каждого обновления записи он автоматически даст команду Nginx удалить страницу из кэша. После активации плагина в настройках необходимо включить опцию «Enable Cache Purge» и задать соответствующие правила.

Если на вашем сервере достаточно свободной памяти, то я рекомендую использовать ramdisk для хранения содержимого fastcgi_cache. На серверах с Debian или Ubuntu кэша рекомендуется использовать смонтированный как tmpfs в RAM каталог /var/run. При этом следует учитывать, что по умолчанию для него зарезервировано 20% от используемой в системе RAM.

Для проверки свободного места необходимо выполнить команду:

df -h /var/run

Результат выполнения команды:

Filesystem      Size  Used Avail Use% Mounted on
tmpfs           2.1G  316K  2.1G   1% /run

В моем случае, для использования fastcgi_cache можно выделить до 2Гб памяти.

Обычно под fastcgi_cache я выделяю 100Мб памяти, время жизни страниц в кэше устанавливаю равным 60 минутам. обычно эти настройки подбираются опытным путем на основе конкретного сайта и характеристик сервера. Для использования fastcgi_cache в Nginx необходимо добавить в конфигурационный файл /etc/nginx/nginx.conf следующие настройки:

fastcgi_cache_path /var/run/nginx-cache levels=1:2 keys_zone=WORDPRESS:100m inactive=60m;
fastcgi_cache_key "$scheme$request_method$host$request_uri";
fastcgi_cache_use_stale error timeout invalid_header http_500;
fastcgi_ignore_headers Cache-Control Expires Set-Cookie;

Отдельно следует уделить внимание опции fastcgi_cache_use_stale, она указывает веб-серверу что если PHP перестанет отвечать, Nginx должен отдать страницу из кэша.

Секция server описывающая настройки сайта, должна выглядеть следующим образом:

server {
	server_name example.com www.example.com;

	root /usr/local/nginx/html;
	index index.php index.html;

	set $skip_cache 0;

	# Отключаем кэш для POST-запросов
	if ($request_method = POST) {
		set $skip_cache 1;
	}   
	if ($query_string != "") {
		set $skip_cache 1;
	}   

	# Не кэшировать страницы админки, rss и sitemap
	if ($request_uri ~* "/wp-admin/|/xmlrpc.php|wp-.*.php|/feed/|index.php|sitemap(_index)?.xml") {
		set $skip_cache 1;
	}   

	# Отключить кэш для пользователей прошедших авторизацию или оставивших комментарий
	if ($http_cookie ~* "comment_author|wordpress_[a-f0-9]+|wp-postpass|wordpress_no_cache|wordpress_logged_in") {
		set $skip_cache 1;
	}

	location / {
		try_files $uri $uri/ /index.php?$args;
	}    

	location ~ .php$ {
		try_files $uri = 404;
		fastcgi_pass unix:/var/run/php-fpm.sock;
		fastcgi_index index.php;
		fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
		include fastcgi_params;

		fastcgi_cache_bypass $skip_cache;
	        fastcgi_no_cache $skip_cache;
		fastcgi_cache WORDPRESS;
		fastcgi_cache_valid 60m;
	}

	location ~ /purge(/.*) {
	    fastcgi_cache_purge WORDPRESS "$scheme$request_method$host$1";
	}	

}

После изменений, необходимо проверить конфигурацию и применить настройки Nginx.

nginx -t
service nginx reload

Для проверки работы кэширования необходимо открыть Chrome в режиме инкогнито, открытые в браузеры страницы должны попасть в кэш Nginx. Для проверки содержимого fastcgi_cache используем команду:

ls -la /var/run/nginx-cache

Закрываем доступ к админке WordPress

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

Один из самых распространенных методов защиты админки сайта — использование HTTP-авторизации на уровне веб-сервера. Для этого нам необходимо предварительно сгенерировать файл .htpasswd, в котором будут хранится данные для авторизации. Затем указываем путь к .htpasswd в конфигурационном файле Nginx. Теперь при переходе по адресу /wp-admin или /wp-login.php Nginx запросит данные для авторизации.

Для генерации пароля необходимо использовать утилита генерации паролей .htpasswd. Пример конфигурации Nginx:

server {
    listen       80;
    server_name  localhost;

    location / {
        root   /usr/share/nginx/html;
        index  index.html index.htm;
    }

    location ~ ^/(wp-admin|wp-login.php) {
        auth_basic "closed site";
        auth_basic_user_file conf/.htpasswd;
        location ~ .php$ {
            root           html;
            fastcgi_pass   127.0.0.1:9000;
            fastcgi_index  index.php;
            fastcgi_param  SCRIPT_FILENAME  /scripts$fastcgi_script_name;
            include        fastcgi_params;
        }
    }
    
    location ~ .php$ {
        root           html;
        fastcgi_pass   127.0.0.1:9000;
        fastcgi_index  index.php;
        fastcgi_param  SCRIPT_FILENAME  /scripts$fastcgi_script_name;
        include        fastcgi_params;
    }
}

Для удобства можно вынести секцию location ~ .php$ в отдельный файл:

# nano /etc/nginx/php-fpm.conf

location ~ .php$ {
    root           html;
    fastcgi_pass   127.0.0.1:9000;
    fastcgi_index  index.php;
    fastcgi_param  SCRIPT_FILENAME  /scripts$fastcgi_script_name;
    include        fastcgi_params;
}

Тогда конфигурация Nginx будет выглядеть следующим образом:

server {
    listen       80;
    server_name  localhost;

    location / {
        root   /usr/share/nginx/html;
        index  index.html index.htm;
    }

    location ~ ^/(wp-admin|wp-login.php) {
        auth_basic "closed site";
        auth_basic_user_file conf/.htpasswd;

        include php-fpm.conf;
    }
    
    include php-fpm.conf;
}

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

server {
    listen       80;
    server_name  localhost;

    location / {
        root   /usr/share/nginx/html;
        index  index.html index.htm;
    }

    location ~ ^/(wp-admin|wp-login.php) {
        allow 82.82.82.82;    // Указываем адрес вашего подключения
        allow 82.82.82.0/24;  // Или подсети вашего провайдера (ip-calculator.ru)
        deny all;

        include php-fpm.conf;
    }
    
    include php-fpm.conf;
}

Изменяем title страниц в WordPress

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

function theme_name_wp_title( $title, $sep ) {
	global $page, $paged;

	if ( is_home() || is_front_page() ) {
		$title = get_bloginfo( 'name', 'display' ) . ' - ' . get_bloginfo( 'description', 'display' );
	}
	if ( is_page() ) {
		$title = get_the_title();
	}
	if ( is_single() ) {
		$title = get_the_title();
	}
	if ( is_category() ) {
		$title = single_cat_title( 'Рубрика: ', false );
	}
	if ( is_archive() && !is_category()) {
		$title = 'Месяц: ' . get_the_date( _x( 'F Y', 'monthly archives date format', 'twentyten' ) );
	}
	if ( is_search() ) {
		$title = 'Результаты поиска: ' . get_search_query();
	}
	if ( is_tag() ) {
		$title = single_tag_title('Метка: ', false);
	}
	if ( ( $paged >= 2 || $page >= 2 ) && ! is_404() ) {
		$title .= '. Страница ' . $paged . '.';
	}
	return $title;
}
add_filter( 'pre_get_document_title', 'theme_name_wp_title', 10, 2 );

Начиная с WordPress 4.4 функция wp_title() упразднена, вместо нее необходимо использовать pre_get_document_title.

Неправильное отображение Gist в Twenty Fifteen

При использовании стандартной темы WordPress Twenty Fifteen, блоки кода вставленные из Gist отображаются некорректно. Для исправления проблемы необходимо добавить в таблицу стилей темы:

.gist table {
	table-layout: auto !important;
}

Транслитерация ссылок в WordPress

Небольшой мод классического плагина транслитерации ссылок в WordPress. Список изменений:

  • добавлена транслитерация имен загружаемых изображений,
  • из таблицы транслитерации удалены буквы в верхнем регистре,
  • транслитерация выполняется по стандарту ISO 9:1995.