Почему Contact Form 7 не работает на iOS

Недавно на WordPress сайте заметил проблему отправки сообщений через Contact Form 7 из устройств с операционной системой iOS.
Если использовалась Google reCAPTCHA, то при нажатии кнопки Отправить, страница очень долго обновлялась и reCAPTCHA сообщала ошибку ожидания, если отключить reCAPTCHA, то сообщение отправлялось спустя 1-2 минуты.

Как оказалось, iOS почему-то начал блокировать AJAX, который использовался по умолчанию при обновлении страницы.

По этому чтобы решить проблему, я открыл файл конфигурации wp-config.php и примерно перед строкой:

define('WP_DEBUG', false);

Добавил строку:

define ('WPCF7_LOAD_JS', false);

Эта строка запрещает Contact Form 7 использовать Javascript.
Если указать эту переменную в конце файла, то она не будет работать.

После этого сообщения на iOS начали отправляться сразу.

Установка Magento в Ubuntu

На тесте установлю Magento в Ubuntu Server 16.04 & PHP 7.

Сначала обновим систему и установим необходимые компоненты:

sudo apt-get update
sudo apt-get upgrade
sudo apt-get install apache2 php mysql-server mysql-client openssl libcurl3 php-curl php-gd php-mcrypt php-xml php-intl php-zip php-mbstring php-soap php-mysql php-cli php-json libapache2-mod-php php-xsl composer

Откроем файл конфигурации PHP в текстовом редакторе:

sudo nano /etc/php/7.0/apache2/php.ini

И установим или убедимся что memory_limit не меньше 512M:

memory_limit = 512M

Активируем необходимые модули:

sudo a2enmod rewrite
sudo phpenmod mcrypt

В конфигурации apache2 добавим сайт или отредактируем стандартный:

sudo nano /etc/apache2/sites-enabled/000-default.conf

Добавим внутри тегов VirtualHost параметры:

<Directory /var/www/html/magento_test>
Options Indexes FollowSymLinks MultiViews
AllowOverride All
</Directory>

Перезапустим apache2 чтобы применить изменения:

sudo service apache2 restart

Подключимся к MySQL серверу, создадим базу и пользователя:

mysql -u root -p
CREATE DATABASE magento;
CREATE USER magento@localhost IDENTIFIED BY 'password';
GRANT ALL PRIVILEGES ON magento.* TO magento@localhost IDENTIFIED BY 'password';
FLUSH PRIVILEGES;
exit

Скачаем архив с последней версией Magento и распакуем его:

cd /tmp/
wget https://github.com/magento/magento2/archive/2.2.3.tar.gz
tar xzvf 2.2.3.tar.gz

Переместим файлы в директорию веб-сервера:

sudo mv magento2-2.2.3 /var/www/html/magento_test

Выполним команду:

cd /var/www/html/magento_test
sudo composer install

Установим на файлы права, владельца и группу под которым работает веб-сервер:

cd /var/www/html/magento_test
sudo find var vendor pub/static pub/media app/etc -type f -exec chmod u+w {} \;
sudo find var vendor pub/static pub/media app/etc -type d -exec chmod u+w {} \;
sudo chmod u+x bin/magento
sudo chown -R www-data:www-data /var/www/html/magento_test/

Откроем в браузере http://SERVER/magento_test и продолжим процесс установки следуя инструкциям, запомним логин/пароль и «Magento Admin Address» так как по нему будет открываться админ панель.

После установки посмотрим где находится php чтобы правильно указать путь в cron заданиях (обычно он в /usr/bin/php):

which php

Откроем crontab:

sudo crontab -u www-data -e

И добавим задания:

* * * * * /usr/bin/php /var/www/html/magento_test/bin/magento cron:run | grep -v "Ran jobs by schedule" >> /var/www/html/magento_test/var/log/magento.cron.log
* * * * * /usr/bin/php /var/www/html/magento_test/update/cron.php >> /var/www/html/magento_test/var/log/update.cron.log
* * * * * /usr/bin/php /var/www/html/magento_test/bin/magento setup:cron:run >> /var/www/html/magento_test/var/log/setup.cron.log

На этом установка Magento завершена.

Смотрите также:
Решение ошибки «Autoload error» при установке Magento
Использование и настройка CRON

Решение ошибки «Autoload error» при установке Magento

Однажды устанавливал Magento в Ubuntu и заметил в браузере следующую ошибку:

Autoload error

Также присутствовали куски кода, в зависимости от открытой страницы.

В моем случае ошибка возникала из-за неустановленного libapache2-mod-php, установил его командой:

sudo apt-get install libapache2-mod-php

После это ошибка не появлялась и я продолжил установку Magento.

Обновление phpBB 3.1.x до phpBB 3.2.x

На тесте обновлю форум phpBB 3.1.9 до версии phpBB 3.2.2.

Системные требования phpBB 3.2 при необходимости можно посмотреть тут https://www.phpbb.com/support/docs/en/3.2/ug/

Обязательно делаем резервную копию базы и файлов форума.

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

Приступим к обновлению, скачиваем архив с новой версией phpBB 3.2.x и распаковываем его:

wget https://www.phpbb.com/files/release/phpBB-3.2.2.zip
unzip phpBB-3.2.2.zip

В распакованных данных форума удалим файл config.php и директории files/, images/, store/.

В данных phpBB что находятся на веб сервере удалим всё кроме директорий ext/, files/, images/, store/ и файла config.php.

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

Если изменятся права на файлы и владелец, то например можно указать их так:

sudo chown -R www-data:www-data /var/www/forum/

Если база данных форума большая, то можно выполнить команду в корневой директории форума:

php ./bin/phpbbcli.php db:migrate --safe-mode

Откроем в браузере адрес форума добавив в конце /install/app.php/update или /install/database_update.php, выберем вкладку «Update», выберем «Update database only», запустим процесс обновления и дождемся завершения.

После успешного обновления удалим директорию install:

rm install

Смотрите также мои статьи:
Решение ошибки «A module already exists» и «The installer detected a timeout» при обновлении phpBB
Импорт и экспорт MySQL баз данных
Обновление phpBB 3.1.8 до phpBB 3.1.9
Обновление phpBB 3.0.x на phpBB 3.1.x
Прочее о phpBB

Решение ошибки «A module already exists» и «The installer detected a timeout» при обновлении phpBB

Обновлял однажды phpBB 3.1.9 до версии phpBB 3.2.2 и заметил следующую ошибку:

The installer detected a timeout
The installer has detected a timeout, you may try to refresh the page, which may lead to data corruption. We suggest that you either increase your timeout settings or try to use the CLI.

Очистил таблицу «phpbb_migrations» в базе форума:

TRUNCATE TABLE phpbb_migrations;

И снова запустил обновление, но получил уже другую ошибку:

A module already exists: UCP_AUTH_LINK_MANAGE

Стандартный модуль Profile естественно был установлен, его можно было отключить, но не удалить.
Поэтому, я нашел его в таблице «phpbb_modules» и удалил, тем самым заставив скрипт обновления думать что он не установлен:

SELECT * FROM `phpbb_modules` WHERE `module_langname` LIKE 'UCP_AUTH_LINK_MANAGE';

После продолжения обновления заметил еще ошибку:

A module already exists: ACP_CONTACT_SETTINGS

Модуль Contact даже не был установлен, после этого я также нашел его в таблице и удалил, а также нашел и удалил еще раз UCP_AUTH_LINK_MANAGE, так как скрипт обновления его восстановил:

SELECT * FROM `phpbb_modules` WHERE `module_langname` LIKE 'ACP_CONTACT_SETTINGS';
SELECT * FROM `phpbb_modules` WHERE `module_langname` LIKE 'UCP_AUTH_LINK_MANAGE';

После удаления модулей из таблицы «phpbb_modules» я очистил таблицу «phpbb_migrations»:

TRUNCATE TABLE phpbb_migrations;

Запустил обновление phpBB и оно завершилось успешно.

Смотрите также:
Обновление phpBB 3.0.x на phpBB 3.1.x

Как изменить тему 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 (здесь кешированные данные).

Все.