Папка wp-content

WordPress состоит из трёх папок: wp-includes, wp-admin, wp-content, а также нескольких файлов рядом с ними.

Все файлы и папки, кроме wp-content, — это и есть движок WordPress. То есть каталоги wp-includes и wp-admin относятся к ядру WordPress, а в wp-content хранятся пользовательские данные сайта.

В директории wp-content хранятся практически все пользовательские файлы WordPress, кроме файла конфигурации wp-config.php (это неотъемлемая часть ядра). Здесь находятся плагины, темы, загрузки и другие файлы содержимого сайта. Тут же принято хранить всё, что связано с расширением возможностей WordPress.

Изначально каталог wp-content содержит один файл index.php и три папки: plugins, themes, languages.

Файл wp-content/index.php

Всегда должен существовать и должен иметь такое содержимое:

<?php // Silence is golden.

Этот файл запрещает просматривать список файлов в папке. Если index.php не существует, а веб-сервер позволяет просматривать содержимое директорий, то по адресу http://example.com/wp-content можно увидеть все файлы и папки этого каталога. Этим могут воспользоваться злоумышленники, например, чтобы проверить наличие уязвимого плагина и затем атаковать сайт.

При обновлении WordPress вручную никогда не трогайте папку wp-content и её содержимое. Она не относится к обновляемым файлам ядра WordPress.

Список того, что может находиться в каталоге wp-content:

/mu-plugins — обязательные плагины

В WordPress есть «обязательные плагины», они находятся в директории wp-content/mu-plugins. О них я писал отдельно, обязательно ознакомьтесь!

Коротко об обязательных плагинах: обязательные к использованию плагины (Must-use plugins), также известные как mu-plugins, устанавливаются в специальную папку mu-plugins внутри каталога wp-content и активируются автоматически для сайта или всех сайтов сети. Эти плагины не видны среди обычных плагинов. В админ-панели они отображаются в отдельном разделе, и их невозможно отключить, не удалив файл плагина из каталога wp-content/mu-plugins.

/plugins — плагины

Плагины находятся в директории wp-content/plugins. Плагин может представлять собой один файл или несколько файлов внутри папки. Любые файлы в директории /plugins сканируются WordPress, чтобы определить, является ли файл файлом плагина. Если файл определяется как плагин, он появляется в админ-панели в разделе «Плагины» и готов к активации.

Для деактивации плагина можно удалить его из папки /plugins. Также можно переименовать папку плагина. В этом случае WordPress не сможет найти его файл и деактивирует плагин при попытке подключения. Но имейте в виду, что плагины лучше удалять из админ-панели через кнопку «Удалить», потому что при удалении могут сработать функции, очищающие данные плагина в базе данных или файлах.

/themes — темы

Темы хранятся в директории wp-content/themes. Каждая тема должна находиться в собственной папке и содержать правильно оформленный файл style.css, чтобы WordPress распознал ее как тему, пригодную для использования. В директории темы должны находиться как минимум 2 файла: index.php и style.css.

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

/uploads — медиафайлы и загрузки

WordPress хранит загруженные файлы в папке wp-content/uploads. Эта директория не существует в дистрибутиве WordPress по умолчанию. Она создается при первой загрузке файла в WordPress. Отдельное создание необходимо, потому что эта папка может быть перемещена в другое место (см. ниже)

По умолчанию WordPress хранит загрузки в папках по годам и месяцам:

/wp-content/uploads/2012/06/image.png

Перед тем как можно будет загружать какие-либо изображения или файлы в WordPress, на сервере необходимо разрешить создание папок в директории /wp-content. При загрузке первого изображения WordPress автоматически создает директорию /uploads и необходимые поддиректории в ней. После того как первый файл загружен, верните права для /wp-content обратно, обычно 755. Некоторые серверы сразу позволяют скрипту создавать папки и файлы.

Директория uploads должна иметь все права, чтобы в ней можно было свободно создавать и удалять файлы, обычно это права 777.

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

uploads в Multisite

В установке Multisite файлы основного сайта загружаются как обычно. Для каждого дополнительного сайта создаётся папка вида /wp-content/uploads/sites/2, где 2 - ID сайта сети.

Так для каждого сайта создаётся каталог с его ID внутри /wp-content/uploads/sites. Далее файлы также располагаются в папках по годам и месяцам.

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

До версии WP 3.5 файлы дополнительных сайтов располагались не в /wp-content/uploads/sites, а в /wp-content/blogs.dir.

Так например, директория для сайта с ID 3 выглядит так:

  • WP 3.5 и выше: /wp-content/uploads/sites/3
  • WP 3.4 и ниже: /wp-content/blogs.dir/3
Перемещение папки uploads

Чтобы переместить папку uploads, нужно определить константу UPLOADS в wp-config.php так:

define('UPLOADS', 'uploads'); // значит что папка uploads должна лежать в корне сайта

Или можно изменить опции: upload_path и upload_url_path в таблице опций (см. update_option()).

Перемещать папку uploads не рекомендуется, об этом я писал в статье: Баг с перемещением папки uploads.

/upgrade — автообновления

Директория wp-content/upgrade создается WordPress автоматически при обновлении WordPress. Эта папка используется для хранения новой версии WordPress, скачанной с WordPress.org. Перед обновлением, WordPress скачивает архив и извлекает его содержимое в эту папку. Чтобы процесс автоматического обновления протекал успешно, рекомендуется не трогать эту папку. Если данная директория удалена, WordPress создаст её при следующем обновлении.

/languages — переводы

Каталог wp-content/languages присутствует только в том случае, если установлена не английская версия WordPress. В нём содержатся файлы локализации, то есть переводы WordPress. Такие файлы имеют расширения:

  • .mo - скомпилированная версия соответствующего файла .po, используемая при переводе;
  • .po - исходный файл перевода. Его можно редактировать, после чего нужно скомпилировать в файл с расширением .mo.

Также в languages могут находиться специальные поддиректории:

  • /plugins — содержит переводы плагинов. Файл перевода должен иметь формат название-плагина-локаль.mo, например akismet-ru_RU.mo. Перед загрузкой собственного перевода плагин проверяет наличие файла в этой папке. Если он найден, используется этот файл, а не перевод из каталога самого плагина.

  • /themes — содержит переводы тем. Файл перевода должен иметь формат название-темы-локаль.mo, например twentyfifteen-ru_RU.mo. Как и в случае с плагинами, эти файлы имеют приоритет перед переводами из каталога темы.

Произвольные директории

В /wp-content можно создавать любые директории. Некоторые плагины, создают такие папки для хранения файлов. Обычно отдельная папка создается, когда нужно хранить много файлов или когда хранимые файлы как-то отличаются от остальных.

Например плагин WP Super Cache создает директорию /wp-content/cache для хранения кэшированных страниц сайта. Кэшированная страница — это сгенерированная страница сайта, сохраненная как статический файл HTML. При обращении к такой странице она не генерируется повторно, а отдается статический файл. Это и есть страничный кэш, который уменьшает нагрузку сервера в десятки раз, поскольку страницы не генерируются при каждом просмотре, а создаются только когда кэш перезаписывается.

Плагин WP Super Cache также добавляет два файла в директорию wp-content: advanced-cache.php (специальный) и wp-cache-config.php. Они нужны для работы WP Super Cache.

Другой пример, популярный плагин для галерей — NextGen Gallery — создает директорию /wp-content/gallery для хранения изображений, загруженных в галереи. Каждая созданная галерея представляет собой поддиректорию /gallery.

Еще пример, мой плагин Kama Thumbnail, который также создает папку /wp-content/cache/thumb и записывает в нее созданные файлы миниатюр.

Специальные drop-in файлы

Все возможные drop-in-файлы WordPress можно посмотреть в функции _get_dropins(). Вот они в виде таблицы:

File Description Loaded Type
advanced-cache.php Advanced caching plugin. If WP_CACHE is true Normal
db.php Custom database class. on load Normal
db-error.php Custom database error message. on error Normal
install.php Custom installation script. on install Normal
maintenance.php Custom maintenance message. on maintenance Normal
object-cache.php External object cache. on load Normal
php-error.php Custom PHP error message. on error Normal
fatal-error-handler.php Custom PHP fatal error handler. on error Normal
sunrise.php Executed before Multisite is loaded. If SUNRISE is true Multisite
blog-deleted.php Custom site deleted message. on deleted blog Multisite
blog-inactive.php Custom site inactive message. on inactive blog Multisite
blog-suspended.php Custom site suspended message. on archived or spammed blog Multisite

Заметки по drop-in:

  • Когда загружаются drop-in модули?
    Большинство подключаемых модулей запускается раньше, чем любой другой обычный или MU-плагин. В таблице выше в колонке Loaded показано когда используется каждый файл.

  • Где можно увидеть активные drop-in модули?
    Подключаемые модули можно увидеть в админке WordPress на странице плагинов в разделе Plugins > Drop-in.

  • Как активировать, деактивировать drop-in модули из админки?
    Вы не можете управлять подключаемыми модулями из админки WordPress, управление подключаемыми модулями может осуществляться только на вашем сервере.

advanced-cache.php

Вызывается на самом раннем этапе загрузки WordPress, в файле wp-settings.php, если константа WP_CACHE включена. Вот так выглядит вызов:

if ( WP_CACHE && apply_filters( 'enable_loading_advanced_cache_dropin', true ) && file_exists( WP_CONTENT_DIR . '/advanced-cache.php' ) ) {
	// Для использования плагинами кэширования. Использует статический файл для обрыва работы скрипта.
	include WP_CONTENT_DIR . '/advanced-cache.php';

	// Re-initialize any hooks added manually by advanced-cache.php.
	if ( $wp_filter ) {
		$wp_filter = WP_Hook::build_preinitialized_hooks( $wp_filter );
	}
}

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

object-cache.php

В отличие от advanced-cache.php, файл object-cache.php загружается всегда, если существует. Он нужен, чтобы переопределить работу базового кэширования объектов WordPress.

Вызывается из функции wp_start_object_cache(), которая в свою очередь вызывается из файла wp-settings.php чуть позднее advanced-cache.php.

На основе этого файла работают такие кэши объектов как: Memcache, Memcached, APC, XCache.

Вызов выглядит так:

// Запускает объектное кэширование WordPress или
// внешнее объектное кэширование, если существует специальный файл.
wp_start_object_cache();

С версии WP 5.8 появился хук enable_loading_object_cache_dropin, который позволяет отключить плагин объектного кэширования. Хук вызывается раньше чем загружаются плагины и нужен когда код запускается не с веба, например при тестах.

Читайте подробнее про Объектный кэш.

maintenance.php

wp-content/maintenance.php отвечает за вывод страницы-заглушки, которая показывается во время автоматического обновления WordPress. Такая страница предусмотрена по умолчанию, и за её вывод отвечает функция wp_maintenance(). Но если создать файл maintenance.php в каталоге wp-content, будет использовано содержимое этого файла.

В maintenance.php нужно описать страницу-заглушку по всем правилам HTML.

Подробнее читайте в описании функции wp_maintenance()

db-error.php

Позволяет показать произвольный шаблон страницы ошибки соединения с базой данных.

Если файл wp-content/db-error.php существует, вместо стандартного сообщения WordPress об ошибке соединения с базой данных будет загружен этот файл. В нём нужно создать HTML-код страницы ошибки.

Страница об ошибке подключения должна устанавливать статус ответа 500, чтобы поисковики не обрабатывали контент.

Файл db-error.php вызывается функцией dead_db(), а функция в свою очередь вызывается при ошибке подключения к БД.

Пример такой страницы смотрите здесь.

db.php

Позволяет переписать движок работы с БД. Если файл существует в папке wp-content, то он будет вызван до создания подключения к БД. Далее, если в этом файле определить переменную $wpdb, то именно она будет использоваться, как глобальная переменная для работы с БД.

Благодаря такой логике, можно, например, расширить базовый класс wpdb{} или полностью его заменить.

Пример расширения базового класса wpdb{}:

<?php

// это код для файла db.php, который лежит в папке wp-content

defined( 'ABSPATH' ) || die();

if ( defined( 'DOING_CRON' ) && DOING_CRON )
	return;

class MY_DB extends wpdb {

	public function __construct( $dbuser, $dbpassword, $dbname, $dbhost ) {

		// дополнительный код...

		parent::__construct( $dbuser, $dbpassword, $dbname, $dbhost );

	}

	// переопределяем метод wpdb::query()
	public function query( $query ) {

		// наш измененный код
	}

}

$wpdb = new QM_DB( DB_USER, DB_PASSWORD, DB_NAME, DB_HOST );

sunrise.php

Загружается только для мультисайтовой сборки, т.е. когда срабатывает условие is_multisite() и при этом определена константа 'SUNRISE' (её нужно определить в файле wp-config.php).

Файл wp-content/sunrise.php позволяет на раннем этапе изменить логику работы сайта в сети мультисайт. Например, тут можно установить глобальные переменные $current_site,
$current_blog определяющие текущий сайт сети. Или можно изменить префикс таблиц БД - переменная $table_prefix.

Также в файле sunrise.php можно изменить константы отвечающие за то, где находится каталоги MU плагинов или обычных плагинов. см. wp_plugin_directory_constants().

sunrise.php подключается еще до константы SHORTINIT.

sunrise.php подключается в файле wp-includes/ms-settings.php, который в свою очередь подключается в основном загрузочном файле wp-settings.php.

Система хуков уже работает в этом файле. За нее отвечает файл wp-includes/plugin.php, который подключается еще раньше.

blog-deleted.php, blog-inactive.php, blog-suspended.php

Срабатывают только для multisite сборки.

В конце загрузки WP, после хука init, но до хука wp_loaded происходит проверка: находится ли текущий блог сети в статусе deleted, archived или spam.

Если он находится в одном из указанных статусов:

  • и для текущего статуса блога есть соотвествующий файл, то именно он будет подключен и на этом работа сайта будет прервана через die(). Соотвествующие файлы (см. ms_site_check()):

    • wp-content/blog-deleted.php - для статуса deleted = 1.
    • wp-content/blog-inactive.php - для статуса deleted = 2.
    • wp-content/blog-suspended.php - для статуса archived или spam.
  • и для текущего статуса блога нет специального файла, то ВП также прервер работу php через wp_die() с дефолтным сообщением соотвествующем статусу сайта.

php-error.php

Отвечает за отображение (шаблон) фатальной ошибки. Срабатывает когда на сайте возникла фатальная ошибка и WP выводит её на экран.

Пример отображения фатальной ошибки на экране

Код этого файла полностью должен заменить метод: WP_Fatal_Error_Handler::display_default_error_template( $error, $handled ). В нем также как и в методе будут доступны переменные $error, $handled.

WP с версии 5.2 умеет обрабатывать фатальные ошибки: отправляет email администратору и выводит сообщение об ошибке на экран. Однако это происходит только в том случае, если константа WP_SANDBOX_SCRAPING не включена (не true). WP_SANDBOX_SCRAPING устанавливается в true при определенных условиях, например: активация плагина, редактирование php файлов в админке и т.д.

fatal-error-handler.php

Позволяет переопределить класс обработки фатальных ошибок. По умолчанию используется класс WP_Fatal_Error_Handler{}.

Код этого файла должен вернуть объект класса в котором будет метод handle().

Пример кода для этого файла:

<?php
/**
 * Замена классу: WP_Fatal_Error_Handler()
 */

class My_Fatal_Error_Handler {

	public function handle() {
		// your code here
	}
}

return new My_Fatal_Error_Handler();

В качестве основы для создания такого класса следует взять класс WP_Fatal_Error_Handler{}.

Переименование или перемещение папки wp-content

В некоторых случаях, например, для уникализации многих URL на всем сайте или для объединения структуры сайта с другим скриптом, или по каким-то еще причинам, нужно чтобы каталог wp-content назвался по-другому или чтобы он находился в другой директории.

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

  • WP_CONTENT_DIR — путь до каталога контента;
  • WP_CONTENT_URL — URL на каталог контента.
define( 'WP_CONTENT_DIR', __DIR__ .'/data' );
define( 'WP_CONTENT_URL', 'http://'. $_SERVER['HTTP_HOST'] .'/data' );

Этот код переименовывает каталог wp-content в data.

  • Качественную

    Как получить качественную техническую поддержку сайта.

    вэбас.рф

  • Голомяное пламя

    Голомяное пламя купить книгу на сайте "Читай-город"

    www.chitai-gorod.ru

23 комментария
Полезные - 2Вопросы - 1 Все