Содержание
В основе каждой установки WordPress лежит файл wp-config.php, файл настолько священный и покрытый тайной, что каждый пользователь WordPress знает, что должен никогда не трогай.
Или это должно?
На самом деле, существует множество менее известных полезных хаков, которые могут быть без какого-либо ущерба для WordPress, и пришло время поднять свои навыки WordPress на ступеньку выше. Продолжайте читать 5 моих любимых трюков с wp-config.
Эта статья предназначена исключительно для сайтов WordPress.org, а не для сайтов WordPress.com (в чем разница?
).
Прежде чем начать, знайте, что вы потенциально можете остановить загрузку WordPress, если вы испортите синтаксис этого файла, даже с чем-то таким же глупым, как забыть точку с запятой. Тем не менее, также невероятно легко скопировать его перед началом редактирования, чтобы у вас была резервная копия. Если вы что-то сломаете, просто удалите измененный файл и переименуйте резервную копию — все будет хорошо с миром снова. На самом деле очень трудно навсегда повредить установку WordPress, если не считать удаления всей базы данных. Прежде чем пытаться что-либо из этого, вы также можете проверить наше окончательное руководство по исправлению 500 внутренних ошибок сервера
,
Файл wp-config.php находится в корне вашей установки WordPress, и для его редактирования требуется войти в систему через FTP или SFTP. Если вы не знаете, как это сделать, содержание этой статьи может не соответствовать вашему уровню квалификации — но вот несколько полезных рецептов IFTTT для использования с WordPress.
(это не связано с редактированием файлов).
Записать ошибки в файл
Иногда выводить кучу неприятных ошибок в публичный интерфейс вашего сайта на самом деле нежелательно. Вместо этого записывайте ошибки в файл! Определите следующее, затем подождите некоторое время, и вы увидите новый журнал ошибок в WP-содержание / Каталог медленно заполняется. Рекомендуется отключить это, как только вы получите достаточно хороший образец ошибок, поскольку нет встроенной ротации журналов или ограничений — вы можете заполнить весь сервер гигабайтами журналов!
[NOEDIT]
define('WP_DEBUG', true); // change back to false to disable
if (WP_DEBUG) {
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
@ini_set('display_errors',0);
}[/NOEDIT]
Ищите строки с PHP_ERROR скорее, чем УВЕДОМЛЕНИЕ или же ПРЕДУПРЕЖДЕНИЕ — последнее не сломает ваш сайт, но первое может.
Отключить публикацию ревизий
Однажды я нашел сообщение с более чем 100 ревизиями: это 100 дополнительных строк в таблице сообщений, которые не нужны. Полностью отключите публикацию изменений, используя следующую простую строку:
[NOEDIT]
define('WP_POST_REVISIONS', false );[/NOEDIT]
или же
[NOEDIT]
define('WP_POST_REVISIONS', 3);[/NOEDIT]
вместо этого ограничить их разумным числом. Конечно, некоторым людям нравится иметь пост-ревизии, особенно в среде, где редакторы вносят изменения в вашу работу — но если это только вы пишете, и у вас есть тенденция работать над постами за раз, это просто не стоит. Обратите внимание, что этот трюк не удалит существующие ревизии поста, он просто остановит создание новых.
Таблица общих пользователей
Иногда ты хочешь больше одного Установка WordPress — мы делаем это здесь, на MakeUseOf.com. Но предоставление пользователям отдельного логина для каждого сайта просто смешно, и использование «многосайтовой» сети блогов тоже не помогает (поверьте, мы пытались) — на самом деле, это чрезмерно усложняет ситуацию, когда несколько строк в вашем wp -config.php — это действительно все, что нужно. То, что вы хотите, — это то, что называется таблицей общих пользователей, то есть, хотя каждый блог остается своей собственной сущностью с отдельными плагинами и постами и т. Д., Только общая база данных пользователей является общей.
Во-первых, определитесь с вашим главным блогом — именно там будет осуществляться управление пользователями. Давайте назовем его блогом A. Блог B и C будут «суб-блогами» и будут опираться на основную пользовательскую таблицу блога A, и я предполагаю, что они будут установлены в отдельных папках. В файлах wp-config для B и C добавьте следующие строки. В этом примере основной блог использует префикс базы данных «blogA».
[NOEDIT]
define('CUSTOM_USER_TABLE', 'blogA_users');
define('CUSTOM_USER_META_TABLE', 'blogA_usermeta');
[/NOEDIT]
Префикс базы данных — это конкретный термин, выбранный при настройке вашего первого блога (тот, который используется для управления всем). По умолчанию wp_ но новые установки побудят вас изменить это. Если вы не уверены, это слово стоит в начале всех имен таблиц вашей базы данных.
Вы также должны убедиться, что домены cookie одинаковы — без этого шага пользователи должны будут входить на каждый сайт отдельно (хотя и с тем же паролем и возможностями, которые теперь используются совместно).
[NOEDIT]
define('ADMIN_COOKIE_PATH', '/');
define('COOKIEPATH', '/');
define('SITECOOKIEPATH', '/');
define('COOKIEHASH', md5('CHANGETHIS'));
[/NOEDIT]
Обязательно замените CHANGETHIS своей собственной случайно сгенерированной строкой символов, чтобы обезопасить ваши куки. Наконец, вы должны увидеть ряд строк, похожих на скриншот ниже, с произвольными значениями «соль» и «ключ». Убедитесь, что это то же самое в каждом файле конфигурации; если у вас его еще нет, используйте эту страницу для их создания.
К счастью, ни одно из изменений, которые вы вносите в wp-config.php, не будет потеряно при каждом обновлении, однако есть еще одно небольшое изменение, которое вам может потребоваться повторить, если обновление перезаписывает его: WP-включает / capabilities.php.
_init_caps () Функция — это то место, где выбираются возможности для текущего пользователя — если мы не изменим это, пользователь сможет войти в систему, но на самом деле ничего не будет делать. Найдите следующий код:
[NOEDIT]
function _init_caps( $cap_key = '' ) {
global $wpdb;
if ( empty($cap_key) )
$this->cap_key = $wpdb->get_blog_prefix() . 'capabilities';
else
$this->cap_key = $cap_key;
$this->caps = get_user_meta( $this->ID, $this->cap_key, true );
if ( ! is_array( $this->caps ) )
$this->caps = array();
$this->get_role_caps();
}[/NOEDIT]
и изменить
[NOEDIT]
$this->cap_key = $wpdb->get_blog_prefix() . 'capabilities';[/NOEDIT]
так что он жестко запрограммирован на любой ваш основной префикс блога
[NOEDIT]
$this->cap_key = 'blogA_capabilities';[/NOEDIT]
Каждое обновление, просто убедитесь, что у вас все еще есть полный доступ к каждому блогу; если нет, повторите это исправление.
Исправить URL сайта
Если вы испортили настройки URL-адреса, иногда вы можете заблокировать себя из области администрирования в неприятном сценарии «курица с яйцом». Вы можете исправить это с помощью доступа к настройкам, но вы не можете получить доступ к настройкам, потому что настройки неверны; (
К счастью, вы можете переопределить любые параметры базы данных, где хранится URL-адрес, — jet добавьте следующие строки в ваш файл конфигурации:
[NOEDIT]
define( 'WP_SITEURL', 'http://example.com/' );[/NOEDIT][NOEDIT]
define( 'WP_HOME', 'http://example.com/' );[/NOEDIT]
Не нарушайте URL при миграции
Перенос сайта WordPress на новый домен
это можно сделать несколькими способами, но если вы решили использовать жесткую базу данных командной строки и дамп файла, это наиболее распространенный способ сделать сайт недоступным. Вместо того, чтобы исправить это после факта, добавьте следующую строку, чтобы перевести WordPress в режим перемещения.
[NOEDIT]
define('RELOCATE',true);[/NOEDIT]
Теперь, когда вы перенесли все, посетите /login.php и настройки URL будут обновлены для вас. Проверьте, что это работает, затем удалите эту строку из конфига.
Освоение вашего wp-config.php — это один из этапов на пути к овладению WordPress. Я также рекомендую вам изучить непосредственное взаимодействие с базой данных с помощью этих удобных SQL-запросов.
,
У вас есть другие хаки wp-config, которыми вы хотели бы поделиться?
