Как решить проблему с Загруженный файл не удалось переместить в wp-content/uploads?
1. Менял права папки на 755 и даже 777 — не помогает.
2. Пробовал прописать в конфиг.пхп следующее, вместе и поотдельности:
define(‘UPLOADS’, ‘wp-content/uploads’);
define(‘UPLOADS’, ‘wp-content/uploads/2023/07’);
3. sudo chown -R www-data
Ничего из этого не помогло. Такое ощущение, что эта банальная проблема не пробиваема. Есть идеи как это пофиксить?
- Вопрос задан 12 июл. 2023
- 230 просмотров
Комментировать
Решения вопроса 0
Ответы на вопрос 1
на папке wp-content/uploads рекурсивно для неё
и всех внутренних папок задать права 755
типа
chmod -R 755 /var/www/saitsasait/wp-content/uploads
Вообще проверить права корневой папки и wp-content тоже, а также пользователей и группу папки
вряд ли дело в чем-то ещё
Баг с перемещением папки uploads
Похоже напоролся на баг в WordPress, который связан с каталогом загрузок wp-content/uploads . Хотя утверждать что это баг я не буду, но логика точно отсутствует. Разберемся по порядку, дело было так: есть у меня старый сайт, который работает еще с версии WP 2+. При его создании я переместил папку файлов uploads в корень сайта. Для этого определил константу в wp-config.php :
define( 'UPLOADS', 'uploads'); // значит что папка uploads должна лежать в корне сайта
Также, переименовал папку контента с wp-content на content . Для этого определил константы в том же wp-config.php :
define( 'WP_CONTENT_DIR', $_SERVER['DOCUMENT_ROOT'].'/content' ); define( 'WP_CONTENT_URL', 'http://'. $_SERVER['HTTP_HOST'] .'/content' );
Все работало до недавнего времени. Недавно я переместил ядро WordPress в отдельную папку wp — это удобно. Теперь, получилось: ядро лежит в папке wp , плагины и т.д. в content и файлы в uploads и все это в корне сайта.
Для тех кто не знает, в WordPress можно логически разделить файлы содержимого ( wp-contents ) и файлы движка ( wp-includes , wp-admin , . ). При этом в настройках устанавливаются 2 разных УРЛ: адрес сайта и адрес WordPress:
После перемещения ядра WordPress, в медиатеке у меня пропали картинки. Посмотрев на УРЛ картинок я увидел что УРЛ изменился с /uploads на /wp/uploads при этом я не менял ранее установленную константу UPLOADS . Заглянув в код _wp_upload_dir() (эта функцию лежит в основе получения всех ссылок на файлы) увидел, что ссылка (url) строиться из объединения UPLOADS с опцией siteurl , а путь (path) строиться так: ABSPATH . UPLOADS .
if ( defined( ‘UPLOADS’ ) && ! ( is_multisite() && get_site_option( ‘ms_files_rewriting’ ) ) )
Это значит что за основу берется не корень сайта, а папка где находится ядро WordPress, и если это вложенный каталог, то UPLOADS будет относится уже к этому каталогу. Это не логично, потому что едва ли можно отнести папку с файлами сайта к понятию движок. Это контент сайта! OK раз нельзя определить константу UPLOADS так, чтобы файлы «смотрели» на корень сайта, а не корень движка, то будем удалять». И удалил константу UPLOADS из wp-config.php , а затем переместил папку uploads в папку контента — content . В итоге общая структура получилась такая:
/wp/wp-admin /wp/wp-includes /content /content/uploads
Далее, чтобы проверить все ли работает как надо, я попробовал загрузить картинку в медиатеку, но картинка загрузилась не в ожидаемую папку: /content/uploads/. , а все в туже подпапку движка: /wp/uploads/. . Расследование показало, что в настройках WP установлена опция upload_path , которая с версий 3.0 не является обязательной и по умолчанию не устанавливается. А у меня там было значение uploads тоже самое что я установил когда-то в константе UPLOADS . Чтобы решить проблему, я просто удалил опцию upload_path . Заменил все старые ссылки в контенте на новые. Для этого я запустил такой SQL запрос:
UPDATE wp_posts SET post_content = REPLACE (post_content, 'http://example.com/uploads/', 'http://example.com/content/uploads/');
И на всякий случай переименовал все поля guid у вложений, для этого я сделал мини-плагин.
К чему это все?
К тому, что если вы вдруг будите на старом сайте перемещать базовые папки WordPress, то зайдите во все опции: http://ВАШСАЙТ/wp-admin/options.php и проверьте не установлены ли у вас опции upload_path и upload_url_path они в 99% случаев не нужны с версии WP 3.0+ и их можно просто удалить. К слову на этом блоге они тоже были и я их удалил. В тех случаях, когда они нужны, вы скорее все будите знать об этом и эта статья будет вам не интересна Также, не пытайтесь перенести папку uploads за пределы папки контента (по умолчанию wp-contents ). Это у вас не получится, если WP вынесен в отдельную папку. Или это вызовет проблемы, если в будущем вы заходите вынести файлы движка в отдельную папку.
Выше упомянул что опции нужны в 99%, но есть 1% когда опция upload_url_path нужна — это когда у нас включен мультисайт и мы переместили папку контента или ядро ВП. В обоих случаях нам придется установить константу WP_CONTENT_URL . Далее, при переключении в одном блоге сети на другой с помощью switch_to_blog() . Мы поймаем баг, потому что во многих функциях, например получение URL картинки (см. wp_get_attachment_url() и _wp_upload_dir()) ВП использует константу WP_CONTENT_URL , а она при переключении будет относится к текущему блогу, а не к тому на который переключились. Вот для таких случаев нужна опция upload_url_path , потому что сначала проверяется её значение и только потом используется константа, если в опции пусто. Обращу еще внимание на то, что Url на загруженные файлы даже при установленной константе WP_CONTENT_URL , все равно остается рабочим при переключении на другой блог. Только домен этого URL будет основной, а не текущего сайта на который переключились.
Загруженный файл не удалось переместить в wp-content/uploads
На хостинге может быть 3 причины, почему файл не перемещается в wp-content/uploads:
- Закончилось свободное место на хостинге. Как посмотреть, сколько осталось места на хостинге, описано в статье Как узнать, чем занято дисковое пространство и как его очистить. Если свободного места мало, удалите ненужные файлы. Если все файлы нужны, рекомендуем повысить тарифный план.
- Папки wp-content/uploads не существует. Проверьте, существует ли папка wp-content/uploads. Это можно проверить в панели управления хостингом. Перейдите в ISPmanager в раздел «Менеджер файлов». Посмотрите, есть ли папка wp-content/uploads. Если нет, создайте её.
- Нет прав на доступ к папке wp-content/uploads. Выставьте права доступа на папку wp-content/uploads. Укажите права 755. Как это сделать, описано в инструкции.
Проблема на VPS
Если у вас заказан сервер VPS, переведите режим работы PHP в FastCGI. Для этого:
- Откройте ISPmanager.
- Перейдите в раздел WWW-домены.
- Двойным щелчком кликните на необходимый домен:
4. В блоке «Дополнительные возможности» в поле «Режим работы PHP» в выпадающем списке выберите FastCGI (Apache).
5. Нажмите Ok:
Популярные статьи
- Как указать (изменить) DNS-серверы для домена
- Я зарегистрировал домен, что дальше
- Как добавить запись типа A, AAAA, CNAME, MX, TXT, SRV для своего домена
- Что такое редирект: виды и возможности настройки
- Как создать почту со своим доменом
Папка wp-content
WordPress состоит из 3 папок wp-includes , wp-admin , wp-content и из нескольких файлов рядом с этими папками. Все файлы и папки, кроме wp-content — это и есть WordPress, движок. Т.е. каталоги: wp-includes и wp-admin — это ядро WordPress, а wp-content — это все остальное — все пользовательские данные. В директории wp-content хранятся практически все пользовательские файлы, кроме файла конфигурации wp-config.php (это неотъемлемая часть ядра). Здесь находятся плагины, темы, файлы плагинов, тем и содержимого сайта. Тут же принято хранить все файлы связанные с расширением возможностей WordPress. Исходно в WordPress, wp-content содержит один файл index.php и 3 папки: plugins , themes , languages .
Файл wp-content/index.php
Всегда должен существовать и должен иметь такое содержимое:
Этот файл запрещает видеть список файлов в папке. Если index.php не существует, а ваш веб-сервер позволяет смотреть файлы в директориях, то пройдя по ссылке http://example.com/wp-content , можно увидеть все файлы и папки в этой директории. Это могут использовать хакеры, чтобы получить доступ к файлам ключей, что позволит взломать сайт. Например, если у вас установлен уязвимый плагин, то сайт можно будет легко проверить на наличие этого уязвимого плагина, а дальше атакующий без особого труда сможет сломать сайт.
При обновлении WordPress вручную, никогда не трогайте папку wp-content и ничего в ней. Она к обновлению WordPress никакого отношения не имеет.
Список того, что может находиться в каталоге wp-content :
- /mu-plugins — обязательные плагины
- /plugins — плагины
- /themes — темы
- /uploads — медиафайлы и загрузки
- /upgrade — автообновления
- /languages — переводы
- Произвольные директории
- Специальные drop-in файлы
- advanced-cache.php
- object-cache.php
- maintenance.php
- db-error.php
- db.php
- sunrise.php
- blog-deleted.php, blog-inactive.php, blog-suspended.php
- php-error.php
- fatal-error-handler.php
- Переименование или перемещение папки 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 хранит загрузки в папках по годам и месяцам:
Перед тем как можно будет загружать какие-либо изображения или файлы в 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 ); >>
Этот файл используется плагинами страничного кэширования. В нем обычно проверяется наличие подходящего файла кэша и если он есть, то он выводиться на экран и работа скрипта обрывается. Это позволяет не загружать 90% файлов 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 отвечает за вывод страницы-заглушки, которая показывается в момент автообновления WoordPress. Такая страница определена по умолчанию и за её вывод отвечает функция wp_maintenance(). Но если создать файл maintenance.php в wp-content , то за вывод страницы-заглушки будет отвечать содержимое этого файла.
В maintenance.php нужно описать страницу-заглушку по всем правилам HTML.
Подробнее читайте в описании функции wp_maintenance()
db-error.php
Позволяет показать произвольный шаблон страницы ошибки соединения с базой данных.
Если файл wp-content/db-error.php существует в папке wp-content , тогда вместо дефолтного сообщения WordPress об ошибки соединения с базой данных будет загружен этот файл. В файле нужно создать HTML код страницы об ошибке!
Страница об ошибке подключения должна устанавливать статус ответа 500, чтобы поисковики не обрабатывали контент.
Файл db-error.php вызывается функцией dead_db(), а функция в свою очередь вызывается при ошибке подключения к БД.
Пример такой страницы смотрите здесь.
db.php
Позволяет переписать движок работы с БД. Если файл существует в папке wp-content , то он будет вызван до создания подключения к БД. Далее, если в этом файле определить переменную $wpdb , то именно она будет использоваться, как глобальная переменная для работы с БД.
Благодаря такой логике, можно, например, расширить базовый класс wpdb<> или полностью его заменить.
Пример расширения базового класса wpdb<> :
// переопределяем метод 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.
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-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().
Пример кода для этого файла:
> 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 .