Некоторые файлы не доступны для записи wordpress
Обновлено: 04.07.2024
Я просмотрел здесь, но не нашел подробностей о лучших разрешениях для файлов. Я также взглянул на некоторые вопросы формы WordPress по поводу и здесь, но всем, кто предлагает 777, явно нужен небольшой урок по безопасности.
Короче мой вопрос такой. Какие разрешения я должен иметь для следующего:
- корневая папка, в которой хранится весь контент WordPress
- сор-админ
- сор-контента
- WP-включает в себя
а потом все файлы в каждой из этих папок?
ОТВЕТЫ
Ответ 1
При настройке WP вам (веб-серверу) может потребоваться доступ на запись к файлам. Таким образом, права доступа могут быть потеряны.
После настройки вы должны ограничить права доступа, в соответствии с усилением WordPress все файлы, кроме wp-контента, должны быть доступны для записи только вашей учетной записи пользователя. wp-контент должен быть доступен для записи и для www-данных.
Возможно, вы захотите изменить содержимое wp-содержимого позже. В этом случае вы могли бы
- временно перевести пользователя на www-данные с помощью su ,
- дать доступ wp-content group для записи 775 и присоединиться к группе www-data или
- предоставьте пользователю права доступа к папке с помощью списков ACL.
Что бы вы ни делали, убедитесь, что файлы имеют права доступа rw для www-данных.
Ответ 2
Предоставление полного доступа ко всем файлам wp пользователю www-data (который в этом случае является пользователем веб-сервера) может быть опасным. Поэтому не делайте этого:
Это может быть полезно, однако, в тот момент, когда вы устанавливаете или обновляете WordPress и его плагины. Но когда вы закончили, уже не рекомендуется хранить файлы wp, принадлежащие веб-серверу.
В основном это позволяет веб-серверу помещать или перезаписывать любой файл на вашем веб-сайте. Это означает, что есть возможность взять ваш сайт, если кому-то удастся использовать веб-сервер (или отверстие безопасности в некотором .php script), чтобы поместить некоторые файлы на ваш сайт.
Чтобы защитить свой сайт от такой атаки, вы должны:
Все файлы должны принадлежать вашей учетной записи пользователя и должны быть доступны для записи тобой. Любой файл, который требует доступа на запись из WordPress, должен быть доступный для записи на веб-сервере, если это требует ваш хостинг, это может означать, что эти файлы должны принадлежать группе из используемой учетной записи пользователя с помощью процесса веб-сервера.
Корневой каталог WordPress: все файлы должны быть доступны для записи только вашей учетной записью пользователя, кроме .htaccess, если вы хотите, чтобы WordPress автоматически генерируйте правила перезаписи для вас.
/wp-admin/
Область администрирования WordPress: все файлы должны быть доступны для записи только вашей учетной записью пользователя.
/wp-includes/
Основная часть логики приложения WordPress: все файлы должны быть доступны для записи только вашей учетной записью пользователя.
/wp-content/
Содержимое, поставляемое пользователем: предназначено для записи в учетной записи пользователя и процесса веб-сервера.
Внутри /wp-content/ вы найдете:
/wp-content/themes/
Файлы тем. Если вы хотите использовать встроенный редактор тем, все файлы должны быть доступны для записи в процессе веб-сервера. Если ты не хотите использовать встроенный редактор тем, все файлы могут быть доступны только для записи по вашей учетной записи пользователя.
/wp-content/plugins/
Файлы плагинов: все файлы должны быть доступны для записи только вашей учетной записью пользователя.
Другие каталоги, которые могут присутствовать с /wp-content/ , должны быть задокументированный любым плагином или темой. Разрешения могут изменяются.
Ответ 3
Для тех, у кого есть корневая папка wordpress под их домашней папкой:
Вы хотите вызвать usermod для своего пользователя. Итак, это будет:
** Предполагая, что существует группа www-data
Проверьте, что ваш пользователь находится в группе www-data :
Вы должны получить что-то вроде:
** youUserGroupName обычно похож на ваше имя пользователя
Рекурсивно изменить групповое владение папкой wp-content, сохраняя право пользователя на
chown yourUserName:www-data -R youWebSiteFolder/wp-content/*
Измените каталог на youWebSiteFolder/wp-content/
Рекурсивно изменить групповые разрешения папок и подпапок, чтобы разрешить права на запись:
find . -type d -exec chmod -R 775 <> \;
** режим `/home/yourUserName/youWebSiteFolder/wp-content/'изменен с 0755 (rwxr-xr-x) на 0775 (rwxrwxr-x)
Рекурсивно изменить групповые разрешения файлов и подфайлов, чтобы разрешить права на запись:
find . -type f -exec chmod -R 664 <> \;
Результат должен выглядеть примерно так:
chmod -R ug + rw имя папки
Разрешения будут похожи на 664 для файлов или 775 для каталогов.
Ответ 4
Ответ 5
Я установил права на:
В моем случае я создал отдельного пользователя для WordPress, который отличается от пользователя по умолчанию apache, который запрещает доступ из Интернета к файлам, принадлежащим этому пользователю.
Затем он дает разрешение пользователю apache на обработку папки загрузки и, наконец, устанавливает достаточно безопасные разрешения для файлов и папок.
РЕДАКТИРОВАНИЕ
Если вы используете W3C Total Cache, вам следует сделать следующее:
Тогда это сработает!
РЕДАКТИРОВАНИЕ
Через некоторое время при разработке сайтов на WordPress я бы порекомендовал разные разрешения для файлов для каждой среды:
В производственном процессе я бы не давал пользователям доступ к изменению файловой системы, я позволял бы им только загружать ресурсы и предоставлять доступ к некоторым плагинам для определенных папок для создания резервных копий и т.д. Но управление проектами в Git и использование ключей развертывания в сервер, это не хорошие плагины обновления для постановки, ни производства. Я оставляю здесь настройки файла производства:
www-data: www-data = пользователь и группа apache или nginx
Постановка будет иметь те же производственные разрешения, которые должны быть ее клоном.
Наконец, среда разработки получит доступ к плагинам обновлений, переводам и тому подобному.
www-data: www-data = apache или nginx пользователь и группа your-user: root-group = ваш текущий пользователь и корневая группа
Эти разрешения предоставят вам доступ к разработке в папках themes и your-plugin , не спрашивая разрешения. Остальная часть контента будет принадлежать пользователю Apache или Nginx, что позволит WP управлять файловой системой.
Перед созданием git-репо сначала выполните следующие команды:
Ответ 6
Правильные разрешения для файла - 644 Правильные разрешения для этой папки - 755
Чтобы изменить разрешения, используйте терминальные и следующие команды.
755 для папок и 644 для файлов.
Ответ 7
Фактически это зависит от плагинов, которые вы планируете использовать, поскольку некоторые плагины меняют корневой документ Wordpress. но обычно я рекомендую что-то подобное для каталога wordpress.
Это назначит "root" (или любой другой пользователь, который вы используете) как пользователь в каждом отдельном файле/папке, R означает рекурсивный, поэтому он просто не останавливается в папке "html". если вы не использовали R, то он применим только к каталогу "html".
Это установит владельца/группу "wp-content" в "www-data" и, таким образом, позволит веб-серверу устанавливать плагины через панель администратора.
Это установит разрешение каждого отдельного файла в папке "html" (включая файлы в подкаталогах) на 644, поэтому внешние пользователи не могут выполнить какой-либо файл, изменить любой файл, группа не сможет выполнить какой-либо файл, изменить любой файл, и только пользователю разрешено изменять/читать файлы, но даже пользователь не может выполнить какой-либо файл. Это важно, потому что это предотвращает любое выполнение в папке "html", так как владелец html-папки и всех других папок, кроме папки wp-content, является "root" (или вашим пользователем), www-data может " t изменять любой файл вне папки wp-content, поэтому, даже если на веб-сервере есть какая-либо уязвимость, и если кто-то обратился к сайту неавторизованно, они не могут удалить основной сайт, кроме плагинов.
Это ограничит разрешение доступа к "wp-config.php" для пользователя/группы с помощью rw-r ----- этих разрешений.
И если плагин или обновление жаловались, что он не может обновить, затем получить доступ к SSH и использовать эту команду и предоставить временное разрешение на "www-data" (веб-сервер) для обновления/установки через панель администратора, а затем вернитесь к "root" или вашему пользователю после его завершения.
И в Nginx (такая же процедура для apache), чтобы защитить папку wp-admin от несанкционированного доступа и зондирования. apache2-utils требуется для шифрования пароля, даже если у вас установлен nginx, опустите c, если вы планируете добавить больше пользователей в один и тот же файл.
Теперь зайдите в это место
Используйте эти коды для защиты папки "wp-admin" с паролем, теперь он попросит пароль/имя пользователя, если вы попытаетесь получить доступ к "wp-admin". Обратите внимание: здесь вы используете файл .htpasswd, который содержит зашифрованный пароль.
Теперь перезапустите nginx.
Ответ 8
Я думаю, что приведенные ниже правила рекомендуются для сайта Wordpress по умолчанию:
Для папок внутри wp-контента установите разрешения 0755:
chmod -R 0755 плагины
chmod -R 0755 загружает
Обновление chmod -R 0755
Пусть пользователь apache является владельцем указанных выше каталогов wp-контента:
chown apache uploads
обновление chown apache
chown apache plugins
Ответ 9
Где ftp-пользователь - это то, что вы используете для загрузки файлов
Ответ 10
Чтобы убедиться, что ваш сайт защищен, и вы используете правильные разрешения для своих папок, используйте плагин безопасности, подобный этим:
Эти плагины сканируют вашу установку Wordpress и уведомляют вас о любых возможных проблемах. Они также предупреждают вас о каких-либо небезопасных разрешениях на папку. В дополнение к этому, эти плагины будут рекомендовать вам, какие разрешения должны быть назначены папкам.
Ответ 11
Ответ 12
Я не могу сказать, правильно ли это или нет, но я использую образ Bitnami над Google Compute App Engine. У меня возникли проблемы с плагинами и миграцией, и после того, как я снова начал разбираться с разрешениями chmod'ing, я нашел эти три строки, которые решили все мои проблемы. Не уверен, правильно ли он работал, но работал на меня.
Ответ 13
Для OS X используйте эту команду:
Ответ 14
Определите в файле wp_config.
chown - изменяет право собственности на файлы/директории. То есть. владелец файла /dir изменяется на указанный, но он не изменяет разрешения.
Ответ 15
Основываясь на прочтении и мучениях на моих сайтах, и после того, как меня взломали, я пришел к приведенному выше списку, который включает разрешения для плагина безопасности для Wordpress под названием Wordfence. (Не связан с этим)
Откройте права доступа, чтобы www-данные могли записывать в корень документа следующим образом:
Теперь с панели инструментов на вашем сайте, как администратор, вы можете выполнять обновления.
Безопасный сайт после завершения обновлений, выполнив следующие действия:
Приведенная выше команда изменяет права доступа ко всему в установке WordPress для пользователя WordPress FTP.
Приведенная выше команда гарантирует, что плагин безопасности Wordfence имеет доступ к своим журналам. Каталог загрузки также доступен для записи по www-данным.
Приведенная выше команда также гарантирует, что для плагина безопасности необходим доступ на чтение и запись для правильной работы.
Разрешения для каталогов и файлов
Установите разрешения для wp-config.php равными 640, чтобы только wp-пользователь мог читать этот файл, и никто другой. Разрешения 440 не помогли мне с вышеуказанным владельцем файла.
Автоматические обновления Wordpress с использованием SSH работали нормально с PHP5, но не работали с PHP7.0 из-за проблем с php7.0-ssh2 bundeld с Ubuntu 16.04, и я не мог найти, как установить правильную версию и заставить ее работать. К счастью, очень надежный плагин под названием ssh-sftp-updater-support (бесплатный) делает возможным автоматическое обновление с использованием SFTP без необходимости в libssh2. Таким образом, приведенные выше разрешения не нужно ослаблять, за исключением редких случаев, когда это необходимо.
Я только что перенес свои данные Wordpress на новый сервер. После этого я не могу загрузить ни один медиафайл.
- Готов поспорить, что безопасный режим включен на сервере, на который вы только что перешли.
Вам необходимо обновить разрешения для каталога загрузки.
если у вас есть доступ по ssh, что-то вроде chmod a+w wp-content/uploads или если вы используете какой-либо FTP-клиент, попробуйте щелкнуть правой кнопкой мыши по папке и установить group или all разрешение на запись.
Если вы не знаете, где находится ваша папка с загрузками, вы можете проверить wp-config.php для этой линии define( 'UPLOADS', YOUR UPLOAD FOLDER HERE);
- Я столько раз обновлял разное количество. Подскажите точное количество и папку. Я попытался внести изменения в папку ЗАГРУЗКИ, 2014/09 и index.php
- Вероятно, у вас по умолчанию wp-content/uploads/ , но вы можете проверить, отметившись wp-config.php для чего-то вроде define( 'UPLOADS', YOUR UPLOAD FOLDER HERE); .
Зависит от вашего окружения. Узнайте, какой пользователь использует wordpress, и запустите следующее:
если вы не заботитесь о безопасности, вы можете просто запустить
У меня возникла эта проблема после переноса сайта на новый сервер.
Пути файловой системы на новом сервере отличаются от путей на старом сервере, поэтому ваш путь загрузки кажется недоступным для записи, потому что его нет на новом сервере.
Проблема в том, что иногда WordPress заполнит опцию под названием upload_path в wp_options Таблица. Очень похоже на комментарий выше с PHP Define: 'UPLOADS' это может быть установлено в вашем wp-config.php это не идеально, так как жестко кодирует ваши пути.
Как это сделать? Внутри WordPress есть удобный способ сделать это: (осторожно: будьте осторожны, чтобы не изменять никакие другие поля на следующих шагах, кроме того, которое вы ищете).
- Войдите в свой WP Admin
- Перейдите по этому URL-адресу на своем сайте: /wp-admin/options.php . Это предоставит вам полный список параметров WP в вашем wp_options таблица базы данных.
- Найдите (Ctrl + F) следующее название опции: upload_path
- Если у него есть значение, просто удалите то, что находится в этом поле.
- Больше ничего не меняйте и нажмите Save Changes внизу
Затем WordPress начнет использовать путь по умолчанию ( /wp-content/uploads/ ) в папку загрузок
Папка загрузки была недоступна для записи. Путь загрузки нужно было удалить в базе данных> таблица wp_options.
Внутренняя ошибка сервера (Internal Server Error), она же Ошибка 500
Вот причины, приводящие к «Ошибке 500»:
- Сбой в работе плагина
- Сбой в работе темы
- Сбой в работе файла .htaccess
- Исчерпан лимит PHP-память
Эта ошибка запросто может заставить новичка паниковать, но не стоит волноваться, ее можно решить.
Отредактировать файл .htaccess.
Так как к этой ошибке главным образом приводит сбой в работе файла htaccess, авторизуйтесь в корневой директории WordPress с помощью файлового менеджера (или FTP) и переименуйте файл .htaccess в .htaccess.old и обновите браузер, чтоб посмотреть решена ли проблема. Если ошибка пропала, идем в Параметры->Постоянные ссылки и кликаем кнопку «Сохранить изменения», чтоб перезапустить ваш .htacess и переписать правила. Если это не сработало, то нужно проверить ваши плагины
Деактивировать все плагины.
Если вы только что установили какой-либо плагин, и он стал причиной проблемы, это хорошо, так как вы знаете, что нужно деактивировать или удалить. Но в другой раз причиной такой ошибки может стать один из старых плагинов (или несколько плагинов, которые не совместимы друг с другом). Пока вы не деактивируете все плагины, вы не узнаете, стали ли они причиной возникшей проблемы.
Сменить тему.
Если плагины ни в чем не повинны, то возможно шалит ваша тема. Переключитесь на шаблон Twenty Twelve и перезагрузите ваш сайт. Если вы все еще видите ошибку, вероятно, вам нужно заняться WordPress-директориями
Восстановить директории the wp-admin и wp-includes.
Если ошибка никуда не пропала, попробуйте заменить папки wp-admin и wp-includes новыми папками из свежей инсталляции WordPress
Увеличить лимит PHP-памяти.
Сохраняем и загружаем файл в папку /wp-admin/. Если после расширения PHP-памяти ваша проблема ушла, спросите у вашего хостера, что приводит к ее истощению. Причина может быть любой, начиная от неправильной работы темы до криво написанных плагинов. Хостер должен снабдить вас информацией из журнала операций.
Неудачное авто обновление
Сейчас WordPress можно безопасно обновлять в автоматическом режиме, так как количество багов и других подобных вещей сведено к минимуму. Автообновление – это действительно гениальная функция, но иногда она дает сбой. Если автообновление не предусматривает какого-либо человеческого вмешательства, как узнать, что обновление прошло неудачно? Вы увидите что-то из этого:
Причины неудачного автообновления:
- Возникла проблема с доступом в интернет во время обновления.
- Сбой связи с главными WordPress-файлами
- Выставлены некорректные права на управления файлами
Решение проблемы с неудачным автообновлением:
Обновляйте WordPress вручную. Если вы не знаете с чего начать, почитайте гайд по мануальному обновлению WordPress в Кодексе.
Ошибка синтаксиса кода WordPress
Проведенный мною анализ показал, что не редко встречаются ошибки, допущенные людьми, которые используют сниппеты кода на своих WordPress-сайтах. Когда вы сталкиваетесь с этой ошибкой, то видите что-то вроде этого:
Не стоит впадать в уныние из-за этого, так как сразу понятно, где искать проблему.
Причина появления ошибок синтаксиса:
Как правило, ошибка синтаксиса появляется там, где потерялся или наоборот появился неожиданный символ. В большинстве случаев такое возникает, когда неопытный пользователь пытается редактировать код темы или плагина, но также подобная ошибка появляется, если вы установили новую тему или плагин, содержащий ошибку.
Error Establishing A Database Connection (Ошибка соединения с базой данных)
Из всех распространенных ошибок WordPress эта сама объясняет причину своего появления: где-то нарушена связь с базой данных WordPress.
Причины возникновения ошибки соединения с базой данных:
- Ошибка файла wp-config.php
- Проблемы с вашим хостинг-провайдером.
- Вас хакнули!
Что делать, если возникла ошибка соединения с базой данных:
a. Отредактировать ваш wp-config.php file
Получите доступ к файлу wp-config.php с помощью файлового менеджера или FTP и удостоверьтесь в том, что имя базы данных, хост, имя пользователя и пароль указаны правильно.
b. Решить проблемы с вашим веб-хостингом
Если wp-config.php выглядит нормально, а ошибка никуда не ушла, вам нужно поговорить с вашим хостинг-провайдером. Вам скажут, в чем проблема: упал ли сервер или хостер просто решил расширить лимит оперативной памяти вашей базы данных. Если вам скажут, что с их стороны все в порядке, то пришло время озаботиться вопросом WordPress-безопасности на вашем сайте.
c. Просканируйте ваш сайт на наличие угроз
Хакеры не дремлют. Да, не дремлют. В любое время вы можете пасть жертвой хакерской атаки, особенно если вы не знаете, как обезопасить ваш WordPress-сайт. Чтоб удостовериться в том, что ваш сайт не был хакнут, просканируйте его с помощью инструмента типа Sucuri Sitecheck.
Ошибка «Briefly Unavailable For Scheduled Maintenance»
1,2,3…все отдохнули, давайте попытаемся понять, почему мы сталкиваемся с этой не с такой уж мимолетной ошибкой. И, кстати говоря, вам совершенно не стоит волноваться на ее счет, так как эту ошибку очень просто решить. Но сначала, давайте глянем на причины ее возникновения.
Причины возникновения ошибки «планового техобслуживания»:
- Неудачное обновление WordPress привело к тому, что некоторые вещи вышли из-под вашего контроля.
- По каким-то причинам после обновления не был удален файл .maintenance
Как избавится от этой ошибки:
Идем в корневую директорию WordPress с помощью FTP или файлового менеджера и удаляем файл .maintenance Чувствуете в себе силы устранить любую ошибку, если/когда такая возникает? Если так, то давайте двигаться к ошибке № 6.
Не работает восстановление пароля по электронной почте.
Главная причина возникновения данной проблемы заключается в людской забывчивости. Может быть, попробуете поделать упражнения для укрепления памяти? Шучу, мы все что-то забываем, даже такие важные вещи, как пароли, имена пользователей, и email-адреса. В этом случае вы вынуждены воспользоваться страницей восстановления пароля. Но проблема заключается в том, что вы так и не дождетесь ссылки для сброса пароли на свой почтовый ящик. Вы проверяете почту опять, роетесь в папке со спамом, но опять нет ссылки.
Причина возникновения проблемы:
Почему-то ваша WordPress инсталляция не высылает вам ссылку для сброса пароля, и почему так происходит никому неизвестно. Но главная загвоздка заключается не в том, что вы не получили ваш пароль, а в том, что вы вообще не можете его сбросить. Хорошо, есть парочка решений.
Как решить проблему со сбросом пароля:
Отредактировать файл functions.php
И вот он, менее технический способ. Файл functions.php ответственен за многие вещи, происходящие на вашем WordPress-сайте. Если с восстановлением пароля по email полный мрак, то нужно:
Перейти по “../wp-content/themes/ваша активная тема /” используя FTP или файловый менеджер, скачайте functions.php file.
Откройте его в редакторе кода и добавьте следующий код:
Причина Ошибки 403:
Проблема с индексным файлом, если ваш блог «живет» на сервере Windows.
Решение проблемы, при возникновении Ошибки 403:
Положить в корневую директорию файл index.php. Чтобы сделать это идем в Control Panel -> Web Options -> Directory Indexes и кидаем туда index.php.
Сайдбар переместился под контент
Эта ошибка меня крайне озадачила, когда я впервые с ней столкнулся. Я был убежден, что моя тема совершенно никуда не годится, и собирался изменить ее целиком. Так что я позвал поисковых роботов Google и понял, что получил одну из самых распространенных WordPress ошибок. Осознав это, я успокоился. Пара кликов плюс пара прокруток страниц, и я нашел причины.
Причины перемещения сайдбара под контент:
- Ошибки HTML – иногда вы можете забыть закрыть парочку элементов div.
- Ошибки CSS – в другой раз вы можете задать непропорциональную ширину, что приведет к искажению всего вашего шаблона.
Как решить проблему:
Админка WordPress отражается некорректно
Зашли в админ панель и обнаружили, что с консолью все совсем не в порядке? Я имею в виду, что ссылки отражаются неправильно, не на своих местах, в виде списков ссылок, так как консоль отображается без подключения CSS.
Причины некорректного отображения админ-панели:
- Прокси и файерволы блокируют CSS-файлы
- Поврежденные плагины админ-меню
Как решить проблему неправильного отображения админ-панели:
- Убедитесь в том, что вы не находитесь под защитой прокси или файервола (возможно вы зашли на сайт с рабочего компьютера), попытайтесь попасть на сайт с какого-либо другого компьютера без файервола и прокси. Вы также можете попробовать почистить файервол и кэш прокси, и посмотреть сработало ли это.
- Обновите/деактивируйте плагины админ-меню. Если ошибка выскочила после установки плагинов типа Lighter Menus и Admin Drop Down Menu, попытайтесь их обновить или переустановить. Если ошибка не ушла, деактивируйте плагин.
Если ваш сайт «живет» на перегруженном множеством сайтов сервере, то вы будете встречаться с этой проблемой сравнительно часто.
К этой ошибке ведут следующие проблемы:
- Тяжелые плагины
- Ошибки функционирования темы
- Нехватка PHP-памяти
Пути решения проблемы:
- Деактивировать недавно установленные плагины или перезапустить папку с расширениями.
- Увеличить лимит PHP-памяти.
- Переключиться на тему Twenty Twelve, чтоб узнать, не стала ли ваша тема причиной сбоя.
Ошибка «Warning: Cannot Modify Header Information – Headers Already Sent By»
Еще одна распространенная ошибка WordPress, которая беспокоит многих WordPress-пользователей, особенно начинающих. Если вы уже сталкивались сней, то вероятно видели что-то вроде этого:
Последняя часть (Output started at /blog/wp-config.php:34) говорит нам, откуда взялась ошибка
Причина возникновения ошибки:
Присутствие пробелов в затронутом файле (в случае выше это wp-config.php)
Плагин, который невозможно удалить
У некоторых плагинов есть скрытые файлы, которые могут стать настоящей головной болью, если вам захочется удалить одно из таких расширений. В связи с этим хорошая идея скачивать плагины (и если уж на то пошло и темы) только с тех сайтов, которым вы доверяете. Проблема в том, что вы не можете удалить плагин из админ-панели, и даже после удаления папки с плагином с помощью файлового менеджера (или FTP) он все равно никуда не девается. Магия? Не совсем…
Почему иногда так сложно удалить плагин:
Имеются скрытые или вложенные файлы.
Вы открываете отдельные записи, и каждый раз получаете ошибку 404, и это не очень хорошо, так как в записях как раз заключается вся «соль» WordPress-блога.
Причины возникновения ошибки 404:
Проблема с настройками постоянных ссылок
Как устранить ошибку 404:
a. Сохранить постоянные ссылки
Сохраните и загрузите файл .htaccess на прежнее место.
Ошибка «WordPress Memory Exhausted» (Нехватка оперативной памяти WordPress)
Причины нехватки оперативной памяти:
Какой-либо плагин или скрипт съедает всю вашу память.
Проще всего увеличить вашу оперативную память. Чтоб это сделать, откройте файл wp-config.php (его можно найти в корневой директории) и добавьте туда этот код:
Замечание: вам не придется скачивать этот файл (или любой другой), если вы используете файловый менеджер. Вы можете отредактировать файл прямо там. Поговорите с вашим хостером, если не можете понять, как редактировать файлы в файловом менеджере.
Ошибка «Fatal Error Undefined Function is_network_admin»
Я решил закончить этот пост описанием очень простой, но и очень распространенной ошибки.
Недавно мне потребовалось сделать перенос WordPress сайта с одного домена на другой. Копия сайта нужна была для последующей её переработки на новом домене. Перенос сайта с домена на домен дело не пыльное, задача решена, можно приступать к работе. Обычно так всегда и было, но не в этот раз…
А в этот раз у меня возникли трудности с загрузкой изображений в библиотеку медиафайлов через админку WordPress – появилось следующее уведомление об ошибке:
Файл «****.jpg» загрузить не удалось. Не могу создать директорию wp-content/uploads/2021/06. Проверьте, доступна ли родительская директория для записи.
За более чем пятилетнюю практику работы с WordPress, подобного рода ошибка мне встретилась впервые. Но, как говорится, в любой незнакомой ситуации "Google в помощь". Проанализировав поисковую выдачу я выделил две возможные причины возникновения данной ошибки:
- Отсутствие необходимых прав доступа CHMOD (иногда их еще называют атрибутами) к папке wp-content (CHMOD должно быть равным 700, 755 или 777).
- В настройках сайта прописан не правильный абсолютный путь к файлам Вордпресс, который можно изменить через параметр upload_path на странице глобальных настроек WordPress.
Пошаговое исправление ошибки “Не могу создать директорию wp-content/uploads.”
Первым делом я проверил какое значение установлено в правах доступа к папке wp-content и вложенным в нее папкам и файлам. Оказалось, что там все хорошо и установлено значение 700 - разрешены запись, чтение и выполнение файлов внутри папки. Впрочем, чаще всего с правами доступа всегда все в порядке, в редких случаях могут быть выставлены какие-то ограничения.
Как изменить права доступа к папке wp-content?
Для не очень опытных пользователей поясню, что проверить права доступа к папке wp-content, и в случае необходимости изменить их, можно через файловый менеджер вашего хостинга. Открыв корневую папку своего WordPress сайта вы увидите среди прочих папку wp-content. Кликните по ней правой кнопкой мыши и посредством выпавшего контекстного меню перейдите в раздел свойств вашей папки.
Здесь стоит заметить, что в зависимости от того хостинга, на котором работает ваш сайт, раздел с правами доступа к папке может называться по разному. Так, на моем хостинге Beget , этот раздел называется Изменить атрибуты, а сами настройки атрибутов выглядят вот так:
Убедившись, что ошибка не связана с правами доступа, приступаем к проверке параметра upload_path глобальных настроек WordPress. Для того, чтобы попасть на страницу глобальных настроек вашего вордпресс сайта нужно авторизоваться под учетной записью администратора сайта, а затем в адресной строке браузера прописать следующий адрес:
На открывшейся странице содержится внушительная масса различных параметров и полей, поэтому, чтобы долго не искать нужный нам параметр upload_path, воспользуйтесь поиском встроенным в браузер (сочетание клавиш CTRL + F).
В моем случае в поле этого параметра был прописан абсолютный путь к файлам вордпресс, который принадлежал другому хостингу. Как вы можете помнить, я сделал перенос сайта на другой домен и хостинг.
Далее, для устранения ошибки действуем следующим образом:
- Очищаем поле параметра upload_path и сохраняем настройки. После этого необходимо проверить, заработала ли загрузка изображений в библиотеку медиафайлов или нет. Если не заработала, значит переходим к пункту 2. Обратите внимание: если у вас поле upload_path было изначально пустое и загрузка файлов в библиотеку медиафайлов вашего WordPress сайта все равно не работала, значит вам тоже следует проделать действия, описанные в пункте 2.
- Если действия из пункта 1 вам не помогли, то прописываем в поле параметра upload_path правильный абсолютный путь к файлам Вордпресс (о том, как узнать абсолютный путь к папке с uploads написано ниже).
Как узнать абсолютный путь к папке с uploads
Уточнить абсолютный путь можно в поддержке вашего хостинга, а можно узнать самостоятельно, создав php файл со специальным кодом:
Сохраните файл с любым названием, например patch.php и загрузите в корневую папку сайта. Для того, чтобы выполнить сценарий данного кода, нам необходимо открыть наш файл, сделать это можно набрав в строке браузера следующий адрес:
Результатом выполнения скрипта будет веб-страница со следующим содержимым:
Путь к корневой папке: /home/XXXXX/YYYYY
Добавим к получившемуся результату /wp-content/uploads и получим в итоге такой путь:
Путь к корневой папке: /home/XXXXX/YYYYY/wp-content/uploads
Это и есть нужный нам абсолютный путь к папке uploads. Вставляем его в поле параметра upload_path сохраняем настройки и снова пробуем загрузить изображение. Теперь должно все заработать.
Вот таким не хитрым способом можно решить ошибку Не могу создать директорию wp-content/uploads/», которая могла возникнуть на вашем WordPress сайте при работе с Библиотекой медиафайлов.
Читайте также: