Рубрика: WordPress

Как изменить тему WordPress через MySQL

Чтобы изменить тему WordPress через MySQL для начала посмотрим какая тема указана на данный момент, для этого выполним SQL запрос через phpMyAdmin или MySQL клиент:

SELECT * FROM wp_options
WHERE option_name = 'template'
OR option_name = 'stylesheet'
OR option_name = 'current_theme';

Далее посмотрим какие темы присутствуют в директории /wp-content/themes/.

Например для смены на стандартную тему Twenty Fifteen, выполним три SQL запроса:

UPDATE wp_options SET option_value = 'twentyfifteen' WHERE option_name = 'template';
UPDATE wp_options SET option_value = 'twentyfifteen' WHERE option_name = 'stylesheet';
UPDATE wp_options SET option_value = 'Twenty Fifteen' WHERE option_name = 'current_theme';

Как отключить плагин WordPress через MySQL

Чтобы отключить все плагины WordPress через MySQL необходимо:

1) Обязательно сделать резервную копию базы данных.

2) Открыть phpMyAdmin или MySQL клиент из терминала:

mysql -u USER -p

3) Выполнить SQL запрос (при необходимости указать правильный префикс wp_):

UPDATE wp_options SET option_value = '' WHERE option_name = 'active_plugins';

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

Можно также временно отключить плагин переименовав директорию с его файлами, плагины находятся в директории /wp-content/plugins/.

Устранение повторяющихся заголовков на страницах WordPress

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

После просмотра кода, заметил что их дописывает плагин Yoast SEO, отредактировал в его настройках Titles & Metas — Yoast SEO строки:

%%title%% %%page%% %%sep%% %%sitename%%

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

Исправил ошибку закомментировав в коде активного шаблона (файл layout-head.php) строку:

// bloginfo( 'name' );

После этого название страниц отображалось правильно.

P.S. Если отключать плагин Yoast SEO, то указанную выше строку нужно будет обратно раскомментировать.
Если тема не самописная, то вероятно после появления и установки её обновления файл layout-head.php вернется к оригинальному состоянию.

Смотрите также:
Как убрать в wordpress rss ленте повторяющийся title

Предотвращение атак на WordPress xmlrpc.php и wp-login.php

Заметил однажды на некоторых серверах с WordPress сайтами большое количество обращений к файлу xmlrpc.php и wp-login.php

Как оказалось кто-то пытался подобрать пароль и получить доступ к сайту, обычно такие вещи блокирует Jetpack, ограничивается доступ по IP в админку средствами веб-сервера, но на этих почему-то никакой защиты не было.

Посчитать количество обращений к файлу в логах можно командой:

grep 'xmlrpc.php' /var/log/apache2/access.log | wc -l

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

Посчитать количество по каждому IP и вывести список:

grep 'xmlrpc.php' /var/log/apache2/access.log | cut -d' ' -f1 | sort | uniq -c | sort -r

Посчитать количество по каждому IP и вывести список для файла wp-login.php:

grep 'wp-login.php' /var/log/apache2/access.log | cut -d' ' -f1 | sort | uniq -c | sort -r
grep 'wp-login.php' /var/log/apache2/access.log | awk '{print $1}' | sort -n | uniq -c | sort -nr | head -20

В конфигурации apache2 или через файл .htaccess можно ограничить доступ к директории /wp-admin/ по IP, например так:

<Directory /var/www/site/wp-admin/>
  Options -Indexes
  AllowOverride All
  Order allow,deny
  allow from 127.0.0.1 192.168.11.25
</Directory>

Полностью запретить доступ к файлам так:

<Files wp-login.php>
Order Deny,Allow
Deny from all
</Files>
<Files xmlrpc.php>
Order Deny,Allow
Deny from all
</Files>

Если используется например Jetpack, то к wp-login.php лучше не ограничивать, так как могут возникнуть ошибки при обновлении плагина и отразится на его работе.
В этом случае можно активировать защиту от подбора пароля в параметрах Jetpack.

Если Jetpack не используется можно установить другие плагины, например «WP Limit Login Attempts», который отображает капчу при авторизации, а также блокирует неверные попытки входа.
Например плагином «Disable XML-RPC Pingback» можно отключить функции XML-RPC если они не нужны.

Также в файле robots.txt можно запретить индексирование поисковиками этих файлов:

User-agent: *
Disallow: /xmlrpc.php
Disallow: /wp-login.php

Как удалить W3 Total Cache плагин из WordPress

Для удаления W3 Total Cache из WordPress нужно:

1) В меню плагина нажать кнопку очистки кеша.

2) Деактивировать плагин в меню плагинов и там же нажать «Удалить»

3) В корневой директории сайта, в начале файла wp-config.php, если остались, удалить строки:

/** Enable W3 Total Cache Edge Mode */
define('W3TC_EDGE_MODE', true); // Added by W3 Total Cache

/** Enable W3 Total Cache */
define('WP_CACHE', true); // Added by W3 Total Cache

4) Как я заметил после плагина остается много файлов, а на крупных сайтах могут остаться миллионы файлов с кешированными данными.
В директории wp-content удалим файлы, если они есть, advanced-cache.php, object-cache.php, директории w3tc-config и cache (здесь кешированные данные).

Все.

Как убрать надпись «Сайт работает на WordPress»

Чтобы убрать надпись «Сайт работает на WordPress», которая обычно отображается внизу каждой страницы, необходимо отредактировать файл footer.php активной темы (например если активна тема twentyfifteen, то /wp-content/themes/twentyfifteen/footer.php).

А именно очистить содержимое между следующими тегами:

<div class="site-info">
...очистить то что здесь...
</div><!-- .site-info -->

Также заметил что если используется Jetpack с бесконечной прокруткой, то он добавляет свой footer, для его удаления откроем файл /wp-content/plugins/jetpack/modules/infinite-scroll/infinity.php и удалим строку:

<?php echo $credits; ?>

Footer плагина AMP находится тут — /wp-content/plugins/amp/templates/footer.php.

После обновления темы, плагина или Jetpack процедуру придется повторить.

Готово.

Решение ошибки при открытии wp-admin после обновления

Заметил как-то при обновлении WordPress на версию 4.7 что после обновления не открывается wp-admin, вместо админки пустое окно и в адресной строке браузера следующий адрес:

wp-admin/upgrade.php?_wp_http_referer=%2Fwp-admin%2F

Отсюда вывод — автоматические обновления не всегда выполняются успешно.
Проблема в том что версия базы данных в файле /wp-includes/version.php и в базе WordPress, в таблице wp_options не одинаковы.
В моем случае версии в файле и в базе после обновления указаны были следующие:

$wp_db_version = 38590;
db_version 37965

По этому чтобы решить проблему в таблице wp_options, где db_version укажем такую же версию как в файле /wp-includes/version.php.

После этого wp-admin будет открываться.

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

Решение ошибки Jetpack «Verification secrets not found»

Заметил как-то ошибку при активации Jetpack:

The Jetpack server encountered the following client error: Verification secrets not found

Причину нашел в ограниченном доступе по IP через .htaccess к файлу wp-login.php, как оказалось доступ к этому файлу нельзя блокировать если используется Jetpack.

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

#        <files wp-login.php>
#                order allow,deny
#                allow from 127.0.0.1 192.168.2.50
#        </files>

Если строки были в .htaccess, то Jetpack уже можно активировать, если в файлах конфигурации web-сервера, то нужно еще выполнить его перезагрузку чтобы применить изменения.

Также ошибка может возникать из-за конфликтующих плагинов, можно попробовать отключить их по очереди.

Решение ошибки при обновлении WordPress «Сайт ненадолго закрыт на техническое обслуживание. Зайдите через минуту»

Был когда-то давно случай, при обновлении WordPress возникла ошибка и получилось что обновление не установилось да и сайт остался выключенным.
При его открытии отображалось: «Сайт ненадолго закрыт на техническое обслуживание. Зайдите через минуту.» или на английском — «Briefly unavailable for scheduled maintenance».

В этом случае нужно, в директории wp-admin удалить файл .maintenance, а также убедится что в файле wp-activate.php параметр WP_INSTALLING имеет значение false, а не true.

Все, после этого можно повторить попытку обновления.

Как настроить SSL и HTTPS для WordPress

Настраивал недавно на нескольких WordPress сайтах SSL сертификаты.

Сайты были размещены на выделенном сервере под управление Ubuntu, по этому первым делом я создал директорию для сертификатов и перешел в неё:

sudo mkdir /etc/apache2/ssl
cd /etc/apache2/ssl

Включим модуль SSL для Apache2 если он не включен:

sudo a2enmod ssl

Далее сгенерировал сертификат:

sudo openssl req -nodes -newkey rsa:2048 -keyout /etc/apache2/ssl/example.com.key -out /etc/apache2/ssl/example.com.csr

В процессе генерации пришлось ответить на несколько вопросов:
Country Name (2 letter code) [AU]: UA (код страны)
State or Province Name (full name) [Some-State]: Sumy (область)
Locality Name (eg, city) []: Romny (город)
Organization Name (eg, company) [Internet Widgits Pty Ltd]: Private person (частное лицо или имя организации)
Organizational Unit Name (eg, section) []: (пусто или имя отдела организации)
Common Name (e.g. server FQDN or YOUR name) []: example.com (имя домена, без http и https)
Email Address []: admin@example.com

Можно также подписать сгенерированный сертификат (это содержимое example.com.csr) у какого нибудь доменного регистратора.
Процедура стоит дешево и после неё при подключении не будет высвечиваться сообщение что сертификат не подписан.

Так как сайтов несколько, то в директории /etc/apache2/sites-enabled/ расположены конфигурационные файлы для каждого из них.
Выберу один из них и в самом конце после стандартной директивы:

<VirtualHost *:80> ...</VirtualHost>

добавим еще одну, но с 443 портом и укажем пути к сертификатам:

<VirtualHost *:443>
ServerAdmin admin@example.com
ServerName example.com
ServerAlias www.example.com
DocumentRoot /var/www/example.com/
        <Directory />
                Options -Indexes
                AllowOverride All
        </Directory>
        <Directory /var/www/example.com/>
                Options -Indexes
                AllowOverride All
                Order allow,deny
                allow from all
        </Directory>
SSLEngine on
SSLCertificateFile /etc/apache2/ssl/example_com.crt
SSLCertificateKeyFile /etc/apache2/ssl/example_com.key
SSLCertificateChainFile /etc/apache2/ssl/example_com.ca-bundle
ErrorLog /var/log/apache2/example_error-ssl.log
LogLevel warn
CustomLog /var/log/apache2/example_access-ssl.log combined
</VirtualHost>

После изменений проверим конфигурацию и перезапустим apache2:

sudo apachectl configtest 
sudo service apache2 restart

Чтобы можно было зайти в WordPress и админку только по HTTPS в wp-config.php раскомментируем следующие параметры:

define('FORCE_SSL_LOGIN', true);
define('FORCE_SSL_ADMIN', true);

Также можно в админке, в «Настройки» — «Общие» изменить адрес сайта с http:// на https://.
В robots.txt укажем адрес сайта с https, например:

Host: https://ixnfo.com

Также в sitemap.xml должны быть ссылки с https.
В поисковиках нужно подать заявку на переиндексацию карты сайта, в Яндекс.Вебмастер подать заявку в «Переезд сайта» поставив галочку «Добавить HTTPS».
В Google Search Console нужно добавить этот же сайт с https, он будет индексироваться отдельно от http.

Все, теперь сайт можно открывать по https.

Смотрите также мою статью — Перенаправление запросов на SSL