90% а может и больше сайтов, пользуются контактной формой и так повелось, что как правило за работу этой контактной формы отвечает плагин Contact Form 7 плагину этому уже не первый год и он отлично зарекомендовал себя как плагин для простой контактной формы или для сложных форм заказов с условиями и множеством полей.

В декабре 2018 в плагин добавили совместимость Google Recaptcha v3 и полностью отказались от v2 (там где нужно нажимать «Я не Робот» и отгадывать картинки).

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

Если посетитель заполняет форму с подозрительного адреса (допустим общественный Wi-Fi) который гугл посчитает «Плохим источником», то при заполнении формы пользователь не получит уведомление о том, что что-то не так с капчей, да и что с ней может быть если ее нет. Он будет просто получать уведомление о том, что при отправке сообщения возникла ошибка, попробуйте еще раз. И даже после того как он несколько раз нажмет отправить, ситуация не изменится, в итоге кто-то потеряет драгоценный лид не важно заказ это, обращение или вопрос.

На данный момент как справиться с этой ситуацией не меняя версию капчи я не нашел. Чтобы возобновить работу контактной формы, пришлось доставить еще один плагин, который говорит Contact Form 7 использовать Google Recaptcha v2, сгенерировать ключи для второй версии капчи и ввести их заново в настройках Contact Form 7.

Если у вас установлен плагин Contact Form 7 и используется невидимая капча Google Recaptcha v3 рекомендую проверить работу контактной формы с разных компьютеров / телефонов, возможно не все обращения через контактную форму доходят до адресата.

Запись Внимание Google Recaptcha v3 + Contact Form 7 впервые появилась Блог про блоги от Дмитрия Донченко.

Лично я на данном этапе наших взаимоотношений с ним его просто ненавижу. Возможно это звучит громко, но он этого заслуживает.

Когда вы зашли в админку и видите объявление о том что: «Грядет новый издательский опыт» не повторяйте ошибок многих и не нажимайте «Установить Guttenberg».

Вместо этого лучше нажать «Установить Classic Editor».

Почему именно так?

1. Оказывается при включенном Guttenberg редакторе, плагины которые делаю кирилическими ссылки, перестают их обрабатывать и вы получаете ссылку вида: mysite.com/название-моей-записи/ на момент написания поста cyr3lat cyr-to-lat не обрабатывают ссылки новых записей.
2. Если у вас тема со встроенным блочным редактором и она не обновляется (ну например потому что вы не оплатили обновления) с вероятностью 90% при включении нового редактора с сайтом у вас будут проблемы в виде пустых страниц как минимум.
3. Возможно я сильно привык к классическому редактору, но в  новом Guttenberg нужно сделать слишком много телодвижений чтобы просто написать пост.

Возможно этот список будет обновляться по мере нахождения новых «невозможностей» нового редактора.

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

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

Название поста «Как отключить Guttenberg», а об этом еще не слова, исправляю ситуацию.

Код который необходимо добавить в functions.php вашей темы, для отключения редактора Guttenberg.

// Disable Gutenberg

if (version_compare($GLOBALS['wp_version'], '5.0-beta', '>')) {
	
	// WP > 5 beta
	add_filter('use_block_editor_for_post_type', '__return_false', 10);
	
} else {
	
	// WP < 5 beta
	add_filter('gutenberg_can_edit_post_type', '__return_false', 10);
	
}

После этого редактор будет переключен на классический.

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

Запись Как отключить Gutenberg впервые появилась Блог про блоги от Дмитрия Донченко.

Иногда приходится удалять сразу много пунктов меню в WordPress, причин может быть несколько, например вы установили тему, залили в нее демо контент и вместе с ним меню, оно красивое, вам нравится, но некоторые пункты (а их бывает много) лишние, чтобы не тратить кучу времени открывая каждый пункт чтобы нажать «Удалить», мы можете удалить их все сразу используя вот этот плагин: WP Edit Menu есть еще один похожий плагин в каталоге плагинов WordPress, но он давно не обновлялся и не отмечен как совместимый с актуальными версиями WordPress.

Работает плагин очень просто, установили, заходим в раздел «Внешний Вид» — «Меню«, на каждом пункте меню появится поле для отметки, на тех полях которые хотим удалить, ставим галочки, и в самом низу нажимаем на кнопку «Remove Items«.

Плагин настолько хорош, что заставил меня написать отдельный пост о нем и поставить ссылочку на страничку плагина. Буду рад если он вам пригодится.

Запись Массовое удаление пунктов меню в WordPress. впервые появилась Блог про блоги от Дмитрия Донченко.

Статей по переводу WordPress на HTTPS в сети огромное множество, поэтому не буду на этом останавливаться.

Намного интереснее задачи и проблемы которые могут возникнуть при переводе сайта на работу с SSL сертификатом.

Одна из них, это то, что Яндекс во время переезда хочет чтобы файл robots.txt был доступен ему и по протоколу http и по протоколу https.

В инструкциях для Apache пишут что можно сделать вот так:

RewriteEngine On
RewriteBase /
RewriteCond %{HTTP:X-HTTPS} !1
RewriteCond %{REQUEST_URI} !robots.txt
RewriteRule ^(.*)$ https://SiteName.ru/$1 [R=301,L]

А вот кусочек конфига который работает на Nginx. Возможно не самое изящное решение, но оно работает:

set $do_redirect  1;
if ($scheme ~* ^https$) {
    set $do_redirect 0;
}
if ($request_uri ~* ^/robots\.txt$) {
    set $do_redirect 0;
}
if ($do_redirect = 1) {
   return 301 https://$server_name$request_uri;
}

Некоторые вообще считают что это не критичная проблема и Яндекс сам разберется где ему искать новый robots.txt, но если клиент хочет, значит нужно сделать :-)

А как бы вы решили данную задачу?

Запись Частичный редирект для robots.txt для Nginx впервые появилась Блог про блоги от Дмитрия Донченко.

Это может пригодится в случаях если необходимо произвести срочную работу с сайтом, а заказчик не доступен либо по каким-то другим причинам не может предоставить вам доступ в админку. Также это может пригодится, если вы просто забыли пароль.

Для этого необходимо, создать  PHP  файл с содержанием:

Отредактируйте $newusername, $newpassword и $newemail на удобные для вас.

Загрузите файл по FTP в папку с сайтом и откройте в браузере, читайте сообщение скрипта.

Запись Как получить доступ к WordPress если есть только FTP впервые появилась Блог про блоги от Дмитрия Донченко.

Для создания страницы настроек, можно воспользоваться WordPress Setting API там есть много чего интересного почитать и много полезных ссылок по теме.

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

После этого нажимаем  «Next tab» и переходим на следующую вкладку где можно создать поля которые в дальнейшем будут определять различные параметры WordPress шаблона.

Когда вставили необходимое количество полей, жмем Let`s Go и переходим на финальную страничку:

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

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

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

Запись Как создать страницу настроек для темы WordPress впервые появилась Блог про блоги от Дмитрия Донченко.

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

Работает плагин просто и эффективно, в режиме редактирования одиночной записи можно выбрать какой тип записи ей присвоить:

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

Нажимаем обновить, любуемся результатом.

Пользуйтесь на здоровье. :)

Запись Полезный плагин Post Type Switcher впервые появилась Блог про блоги от Дмитрия Донченко.

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

Вариантов для DNS хостинга огромное множество, ваш регистратор домена предлагает свои сервера для этого, обычно это бесплатно для клиентов регистратора, ваш хостер также предлагает свои бесплатные DNS сервера для ваших доменов, но я решил что хостинг у меня будет отдельно, регистратор отдельно :-) а DNS настроен в еще одном месте, которым до вчерашнего дня был хостинг DigitalOcean.

Вчера у них случилась какая-то поломка, в результате которой сайты не работали более 3 часов, точнее могли бы не работать. Благодаря тому, что удалось вовремя определить в чем проблема и чем грозит долгое восстановление DNS хостинга, было принято решение прописать для своих и клиентских доменов альтернативные ДНС сервера.

CloudFlare довольно давно предоставляет бесплатный DNS хостинг, а кроме этого дополнительные плюшки, которые иногда могут быть полезными для вашего сайта, например защита от DDoS атак, кэширование сайта (в случае роста нагрузки) и функцию CDN, распределения содержимого сайта между серверами во всем мире для более быстрой доставки посетителю.

Дополнительными функциями я не стал пользоваться, а вот DNS хостинг у них достаточно удобен и стабилен, если верить их статистике они являются одним из самых больших ДНС хостингов и обслуживают более 35% процентов всех доменов.

Переносить домены сложности не составляет, для доменов с большим количеством суб-доменов, существует возможность импорта через файл.

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

Ах, да, и не забываем, что все это бесплатно :)

Запись DNS история или как я переехал на CloudFlare впервые появилась Блог про блоги от Дмитрия Донченко.

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

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

Кроме того, данный способ подбора паролей, практически не заметен для сервера, не вызывает большой нагрузки и позволяет подбирать пароли до 1000 штук в одном HTTP запросе.

Если вы используете функционал XML-RPC, рекомендуется отключить эту возможность, сделать можно несколькими способами:

1. Плагин Disable XML-RPC. Все просто, устанавливаете плагин, в настройках включаете запрет и все.

2. Настройки вашего хостинга, запретить доступ к файлу xmlrpc.php. Это немного сложнее и не описывается в этом посте, т.к. требует дополнительных знаний у пользователя.

Если функционал xml-rpc используется в вашем блоге, вам необходимо ограничить доступ к этому файлу по IP-адресу.

Запись Увеличилось количество атак на xmlrpc в WordPress впервые появилась Блог про блоги от Дмитрия Донченко.

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

Не вдаваясь в подробности могу сказать, что данная уязвимость позволяет получить управление вашим сервером и делать с ним все что угодно. Кроме серверов хостинга, bash используется во многих системах, даже на Macbook с которого я пишу этот пост, есть bash и да, он уязвим.

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

Как проверить уязвим сервер или нет?

Необходимо подключиться к нему через SSH, чтобы зайти в консоль управления и выполнить следующую команду:

env 'VAR=() { :;}; echo Bash is vulnerable!' 'FUNCTION()=() { :;}; echo Bash is vulnerable!' bash -c "echo Bash Test"

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

Bash is vulnerable!
Bash Test

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

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

sudo apt-get update && sudo apt-get install --only-upgrade bash

Если же ваш сервер управляется Red Hat / CentOS / Fedora Linux то команда будет такая:

sudo yum update bash

После этого пакет bash будет обновлен, и вы должны снова проверить вашу систему:

env 'VAR=() { :;}; echo Bash is vulnerable!' 'FUNCTION()=() { :;}; echo Bash is vulnerable!' bash -c "echo Bash Test"

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

Запись Критическая уязвимость выделенных серверов Bash Shellshock впервые появилась Блог про блоги от Дмитрия Донченко.