WordPress ошибка публикации извините вам не разрешено редактировать эту запись

Ошибки неизбежны

Время от времени, на сайтах появляются различные ошибки и конфликты, которые срочно требуют нашего внимания. Связано это с конфигурацией хостинга, конфигурацией сайта и т.д. Иногда, ошибки всплывают на сайтах, на которых не обновляют шаблоны и плагины, а иногда на сайтах, на которых наоборот все обновляют и следят за этим.

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

Извините, вам не разрешено редактировать эту запись

Кому не разрешено? Мне, админу сайта?! Что происходит?

Сегодня, я расскажу об ошибке, которая возникла сразу после попытки добавить запись (сохранить новую запись) на сайте WordPress.

Первое, что пришло на ум: для администратора изменились права. Возможно, проблема была в Базе данных, где прописаны все эти права. Кстати, каждый плагин после активации вносит свои данные в таблицу с правами пользователей.

Некоторые сайты рекомендуют заменить права пользователей прямо в БД определенным готовым своим набором данных. Для этого необходимо открыть БД в phpmyadmin, таблица wp_options, строка wp_user_roles.

Но, никогда не копируйте такие данные и не вставляйте в свою БД. Для каждого сайта эти данные уникальны.

Самым правильным шагом, будет проверить права пользователей.

Как проверить права пользователей?

Установите плагин User Role Editor.

Перейдите в настройки плагина: Настройки  – User Role Editor. Во вкладке Общие отметьте опцию: Отобразить роль Администратор в Редакторе ролей пользователей.

После этого перейдите в раздел: Пользователи – User Role Editor

Выберите нужного пользователя в выпадающем меню, например Администратора. Для удобства просмотра прав, можете отметить опцию “Показ возможностей в читабельной форме”.

В моем случае, причиной ошибки были не права пользователей. Все пункты для админа отмечены.

Как я определил причину ошибки на своем сайте?

Я отключал по очереди плагины и смотрел пропадала ли проблема. И я нашел слабое звено. Им оказался плагин WP Rocket (отвечает за кеширование).

На сайте возникал конфликт между плагином WP Rocket и WordPress.
Версия плагина устарела и вступала в конфликт с последней версией WordPress (5.0).

Так как, от кеширования нельзя было отказаться, я поставил другой плагин – WP Fastest Cache.

Выводы

1.Обновляйте WordPress, шаблоны и плагины до последних версий.

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

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

Дополнительно

Как сбросить права пользователей по умолчанию

Для этого используем тот же плагин User Role Editor. 
Заходим в раздел: Настройки  – User Role Editor. Вкладка Инструменты.

Перед сбросом нас предупредят, что различные плагины вносят свои данные в права доступа, которые прописаны в Базе данных.

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

Рекомендую прочитать:

When trying to create or edit posts in wordpress, the error message «You are not allowed to edit this post» appears. As mentioned, my user is an administrator. With a different administrator account I still have the same problem.

I first thought the problem might be caused by my wordpress template, so I tried to change it back to one of the default templates but the issues unfortunately still exists.

The second step was to download wordpress, unpack it and replace the wp-config.php with my own wp-config.php to give the new installation access to my old database. After that the problem still existed!

After that I came to the conclusion that the problem can only be inside the database, right?
This is a screenshot of SequelPro looking at the wp_usermeta table of my wordpress database. Maybe someone knows what could be wrong with this? Where else could there be some misconfigurations that causes this problem?

Thank you!

Yours Sincerely, Felix

У меня появилось странное сообщение об ошибке на одном из моих сайтов после перехода на новый хостинг

Извините, вам не разрешено редактировать этот элемент.

Что я нашел в качестве решений и не сработал для меня:

Я проверил все префиксы, так как мой перфикс не wp_ , поэтому все точно в users_meta , а также в wp_options .

Я даже пробовал вставить нового администратора с кодом php, у меня та же ошибка.

Я также попытался деактивировать все плагины и восстановить тему по умолчанию, но ничего не помогло.

Сервер, на который я перехожу, имеет ssl, поэтому его соединение https покрыто обновлениями всех URL-адресов внутри db.

Другая проблема — когда я вошел в систему wp-admin , отображается то же сообщение

Извините, вам не разрешено редактировать этот элемент.

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

2 ответа

Если вы пытаетесь редактировать Категории / Пользовательские таксономии и получаете эту ошибку, вам следует сделать следующее.

Проверьте таблицу wp_term_taxonomy на предмет идентификаторов терминов, связанных с более чем одним идентификатором таксономии. Эти записи являются основной причиной ошибки. Следующий запрос должен помочь вам найти это.

Проверьте столбец taxonomy в таблице wp_term_taxonomy , который вы хотите сохранить, и удалите другую запись taxonomy . Перед удалением обратитесь к №3.

Вы также должны удалить записи из таблицы wp_term_relationships для соответствующего term_taxonomy_id , который вы удаляете из таблицы wp_term_taxonomy .

Совет. Сделайте резервную копию своей базы данных перед выполнением любых запросов DELETE в вашей базе данных.

Источник

Ошибка WordPress — Извините, вам не разрешено просматривать эту страницу

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

Введение

Я выполнял перенос сайтов с обычного хостинга с внешним ip адресом. Сайты работали на https. Их нужно было перенести на другой хостинг, который организован немного не стандартно. Запросы сначала приходят на сервер с nginx, работающим в режиме proxy_pass. Дальше запросы по протоколу http уходят на другой сервер, где работают уже непосредственно сами сайты. На втором сервере (бэкенд) стояла связка nginx + php-fpm.

В целом, в такой связке нет ничего необычного. Я ее повсеместно применяю там, где это имеет смысл. Это повышает удобство управления большим количеством сайтов и серверов, плюс в целом безопаснее схема. Многие зловреды, даже если пролезают на сайты, не понимают, как правильно работать в таком окружении. В общем случае проблем не возникает при настройке.

Сайт выполнил переадресацию слишком много раз.

С WordPress получился нюанс. Если просто взять сайт и перенести его на такую схему — ничего не заработает. Первая ошибка, с которой столкнетесь, будет с бесконечным редиректом.

Сайт выполнил переадресацию слишком много раз.

Я немного удивился ошибке, но после того, как пораскинул мозгами, понял, в чем ее причина. Помог мне в этом один из заголовков главной страницы сайта во время редиректа — x-redirect-by: WordPress.

Запрос приходит на внешний сервер по https, дальше он его перенаправляет на бэкенд по http, где работает wordpress. У него в настройках указано, что он живет по адресу с https и он на него редиректит сам. Запрос опять возвращается на proxy и так по кругу.

Я решил эту проблему следующим образом. На прокси добавил еще один заголовок.

А в сам wordpress в файл wp-config.php, который лежит в корне сайта, добавил следующие строки.

После этого бесконечный редирект прекратился и сайт заработал. Я думал, что на этом все. Оказалось — нет. Возникла еще одна ошибка.

Извините, вам не разрешено просматривать эту страницу

При входе в админку получал вот такое сообщение.

Для того, чтобы исключить вероятность, что с сайтом что-то случилось, я перенес еще один сайт. У него увидел эту же ошибку. Тут я крепко призадумался и начал активно искать через поиск решение. Ошибка популярная и методов ее решения предлагают очень много. Мне не помогало ничего. Я перепробовал кучу всевозможных настроек, которые предлагали в различных статьях.

Начал искать в англоязычном интернете статьи на тему настройки такой же связки с внешним прокси на nginx и сайтом wordpress. В целом, там тоже люди сталкивались с различными ошибками и кто как их решал. Мне в итоге помогло вот что.

Указанные выше параметры из wp-config.php изначально я добавил в самый конец файла. После того, как я их перенес выше, сразу же после настроек подключения к базе, ошибка с подключением к админке: «Извините, вам не разрешено просматривать эту страницу» исчезла. Все заработало как и должно работать. Я их перенес вот сюда.

Надеюсь, кому-то помогут мои решения. Я как-то неожиданно долго провозился с этим вопросом, хотя обычно перенос сайта на wordpress это дело 10-15 минут:

1. Делаешь дамп базы, кладешь его сразу же в корень сайта.
2. На новом сервере по rsync через ssh забираешь все файлы сайта.
3. Разворачиваешь БД из дампа, не забываешь удалить его.

Дальше остается только конфиги подготовить:

Ну и на самой proxy:

Перечислил, чтобы самому потом не забыть 🙂

Заключение

И еще совет, если будете проксировать запросы в wordpress, поставьте таймауты ожидания ответа от бэкенда в nginx побольше, так как во время обновления плагинов или самого движка wordpress бэкенд может очень долго не отвечать. Я имею ввиду вот эти значения.

Если они будут слишком маленькие, то обновление будет слетать с ошибками, потому разбираться с последствиями придется.

Если у вас есть желание научиться строить и поддерживать высокодоступные и надежные системы, научиться непрерывной поставке ПО, мониторингу и логированию web приложений, рекомендую познакомиться с онлайн-курсом «DevOps практики и инструменты» в OTUS. Курс не для новичков, для поступления нужны базовые знания по сетям и установке Linux на виртуалку. Обучение длится 5 месяцев, после чего успешные выпускники курса смогут пройти собеседования у партнеров.

Проверьте себя на вступительном тесте и смотрите подробнее программу по ссылке.

Источник

WordPress — Извините, вы не можете редактировать этот элемент

Я получил странное сообщение об ошибке на одном из моих сайтов после перехода на новый хостинг

Извините, вы не можете редактировать этот элемент.

То, что я нашел как решения и не сработало для меня:

Я проверил все префиксы, так как мой wp_ так что все верно в users_meta , Также в wp_options ,

Я даже попытался вставить нового администратора с кодом PHP, я получил ту же ошибку.

Я также попытался деактивировать все плагины & возврат к теме по умолчанию, но ничего не получалось.

Сервер, на который я перешел, имеет ssl, поэтому его соединение https связано с обновлениями всех URL-адресов внутри БД.

Еще одна проблема, когда я вошел в систему wp-admin это показывает то же сообщение

Извините, вы не можете редактировать этот элемент.

В интерфейсе я вижу полнофункциональную wp-панель со всеми кнопками edit page / Create New post / page / etc. Но когда я нажимаю, отображается та же ошибка, что и выше.

Решение

Если вы пытаетесь редактировать категории / пользовательские таксономии и получаете эту ошибку, вы должны сделать следующее.

Проверить wp_term_taxonomy таблица идентификаторов терминов, связанных с несколькими идентификаторами таксономий. Эти записи являются основной причиной ошибки. Следующий запрос должен помочь вам найти это.

Проверьте на taxonomy столбец в wp_term_taxonomy таблицу, которую вы хотели бы сохранить и удалить другую taxonomy запись. Перед удалением см. № 3.

Вы также должны удалять записи из wp_term_relationships таблица для соответствующего term_taxonomy_id что вы удаляете из wp_term_taxonomy Таблица.

Совет:
Сделайте резервную копию вашей базы данных перед выполнением любых запросов DELETE к вашей базе данных.

Другие решения

Деактивируйте все свои плагины и активируйте их один за другим, это поможет найти виновника. если вы не можете войти в панель управления, используйте FTP и переименуйте каталог плагинов.

Источник

Ошибка: Извините, вам не разрешено редактировать эту запись

Ошибки неизбежны

Время от времени, на сайтах появляются различные ошибки и конфликты, которые срочно требуют нашего внимания. Связано это с конфигурацией хостинга, конфигурацией сайта и т.д. Иногда, ошибки всплывают на сайтах, на которых не обновляют шаблоны и плагины, а иногда на сайтах, на которых наоборот все обновляют и следят за этим.

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

Извините, вам не разрешено редактировать эту запись

Кому не разрешено? Мне, админу сайта?! Что происходит?

Сегодня, я расскажу об ошибке, которая возникла сразу после попытки добавить запись (сохранить новую запись) на сайте WordPress.

Извините, вам не разрешено редактировать эту запись

Первое, что пришло на ум: для администратора изменились права. Возможно, проблема была в Базе данных, где прописаны все эти права. Кстати, каждый плагин после активации вносит свои данные в таблицу с правами пользователей.

Некоторые сайты рекомендуют заменить права пользователей прямо в БД определенным готовым своим набором данных. Для этого необходимо открыть БД в phpmyadmin, таблица wp_options, строка wp_user_roles.

Но, никогда не копируйте такие данные и не вставляйте в свою БД. Для каждого сайта эти данные уникальны.

Самым правильным шагом, будет проверить права пользователей.

Как проверить права пользователей?

Установите плагин User Role Editor.

Перейдите в настройки плагина: Настройки — User Role Editor. Во вкладке Общие отметьте опцию: Отобразить роль Администратор в Редакторе ролей пользователей.

Настройки плагина User Role Editor

После этого перейдите в раздел: Пользователи — User Role Editor

Выберите нужного пользователя в выпадающем меню, например Администратора. Для удобства просмотра прав, можете отметить опцию «Показ возможностей в читабельной форме».

Просмотр прав пользователей — User Role Editor

В моем случае, причиной ошибки были не права пользователей. Все пункты для админа отмечены.

Как я определил причину ошибки на своем сайте?

Я отключал по очереди плагины и смотрел пропадала ли проблема. И я нашел слабое звено. Им оказался плагин WP Rocket (отвечает за кеширование).

На сайте возникал конфликт между плагином WP Rocket и WordPress.
Версия плагина устарела и вступала в конфликт с последней версией WordPress (5.0).

Так как, от кеширования нельзя было отказаться, я поставил другой плагин — WP Fastest Cache.

Выводы

1.Обновляйте WordPress, шаблоны и плагины до последних версий.

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

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

Дополнительно

Как сбросить права пользователей по умолчанию

Для этого используем тот же плагин User Role Editor.
Заходим в раздел: Настройки — User Role Editor. Вкладка Инструменты.

Сброс прав пользователей

Перед сбросом нас предупредят, что различные плагины вносят свои данные в права доступа, которые прописаны в Базе данных.

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

Рекомендую прочитать:

В 2011 году я впервые познакомился с CMS WordPress. Еще тогда я увидел в ней перспективу для себя. И не ошибся. Это знакомство изменило мою жизнь.
Сегодня я занимаюсь разработкой сайтов для малого и среднего бизнеса.
У меня есть свой Youtube-канал на котором я обучаю созданию сайтов.
Кроме того, я активно изучаю SEO, чтобы повысить качество своих услуг.

Источник

Как исправить ошибку «Извините, этот тип файла не разрешен по соображениям безопасности» в WordPress

Вы пытаетесь загрузить файл в свою медиатеку WordPress но получаете сообщение «Извините, этот тип файла запрещен по соображениям безопасности» и / или «не удалось загрузить [имя файла]»?

Как следует из сообщения, WordPress ограничивает типы файлов, которые вы можете загружать на свой сайт по соображениям безопасности. Однако, добавив небольшой фрагмент кода в файл wp-config.php вашего сайта или используя бесплатный плагин, вы можете вручную расширить список разрешенных типов файлов, чтобы вы могли загружать файлы любого типа.

Что вызывает сообщение «Извините, этот тип файла не разрешен из соображений безопасности»?

Сообщение «Извините, этот тип файла запрещен по соображениям безопасности»

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

Сообщение об ошибке «Извините, этот тип файла не разрешен по соображениям безопасности» в WordPress:

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

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

По умолчанию вы можете загружать следующие типы файлов:

Картинки:

Видео :

Документы :

Аудио :

Если вы пытаетесь загрузить тип файла, которого нет в приведенном выше списке, вы, скорее всего, столкнетесь с ошибкой «Извините, этот тип файла запрещен по соображениям безопасности». Или вы также увидите, что «[имя файла] не удалось загрузить».

Например, если вы пытаетесь использовать свои собственные пользовательские шрифты на своем сайте WordPress, вы можете попытаться загрузить файл пользовательского шрифта в WordPress в форматах .tff и / или .woff . Поскольку эти форматы не разрешены по умолчанию, WordPress покажет вам сообщение «Извините, этот тип файла не разрешен по соображениям безопасности» вместо того, чтобы позволить вам загрузить их.

Вот пример, где мы пытались загрузить файл .woff на наш тестовый сайт:

Загрузка файла .woff вызывает сообщение

Как исправить ошибку «Извините, этот тип файла не разрешен по соображениям безопасности» в WordPress

Ниже мы покажем вам несколько способов исправить ошибку в WordPress:

1. Добавьте новые разрешенные типы файлов, используя wp-config.php

WordPress включает опцию ALLOW_UNFILTERED_UPLOADS, которую вы можете включить в файле wp-config.php вашего сайта. После включения вы сможете загружать файлы любого типа в медиатеку WordPress.

Вот как это сделать, но сначала, поскольку вы будете редактировать файл wp-config.php, мы рекомендуем выполнить резервное копирование сайта, прежде чем продолжить.

Для начала подключитесь к своему сайту WordPress через FTP / SFTP. Файл wp-config.php вашего сайта находится в корневой папке, в той же папке, где находятся папки wp-admin и wp-include.

Щелкните правой кнопкой мыши, чтобы отредактировать файл или загрузить его на свой компьютер:

Как отредактировать файл wp-config.php

Затем, редактируя файл wp-config.php, добавьте следующий фрагмент кода строка:

define( ‘ALLOW_UNFILTERED_UPLOADS’ , true );

Где добавить код в ваш файл wp-config.php

Обязательно сохраните изменения и повторно загрузите файл, если это необходимо.

Чтобы завершить процесс, вам нужно перейти на панель управления WordPress и выйти из своей учетной записи WordPress. Затем вы можете сразу же войти в систему.

После того, как вы вышли из системы, вы сможете загрузить любой файл, не вызывая сообщения об ошибке:

Успешная загрузка файла .woff

Если вы предпочитаете не редактировать файл wp-config.php и / или хотите больше контролировать, какие именно типы файлов могут быть загружены на ваш сайт, вы можете использовать бесплатный плагин WP Extra File Types на WordPress.org.

После установки и активации плагина перейдите в « Настройки» → «Дополнительные типы файлов» на панели инструментов WordPress.

Там вы увидите длинный список типов файлов. Установите флажок рядом с типами файлов, которые вы хотите загружать, и нажмите «Сохранить изменения» внизу:

Как разрешить типы файлов в настройках плагина

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

Как добавить свой собственный тип файла

Альтернативные плагины

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

Резюме

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

Источник

Вы не имеете разрешения на доступ

У меня появляется странное сообщение об ошибке на одном из моих сайтов после перехода на новый хостинг

• Вы обновили свою базу данных SQL новым https URL?
• Да. Каждый URL-адрес в базе данных имеет https.
• Когда вы переместили сайт?
• Что именно ты пытаешься сделать? Вы пытаетесь отредактировать страницу / публикацию или получаете сообщение об ошибке еще до того, как видите панель инструментов WP? Похоже, ошибка и во внешнем интерфейсе, сам сайт работает или вы видите только ошибку?
• У меня был сайт с этой ошибкой. Оказалось, что почти у каждой таблицы был отключен флаг Auto-Increment, а во многих также отсутствовал флаг Primary Key. Я также обнаружил повторяющиеся данные в столбце «Первичный ключ». Я исправил таблицы вручную с помощью MyPHP Admin. Я видел SQL-запросы, которые должны работать более эффективно.

Если вы пытаетесь редактировать Категории / Пользовательские таксономии и получаете эту ошибку, вам следует сделать следующее.

1. Проверить wp_term_taxonomy таблица для идентификаторов терминов, связанных с более чем одним идентификатором таксономии. Эти записи являются основной причиной ошибки. Следующий запрос должен помочь вам найти это.

   SELECT term_id, COUNT(term_id) FROM wp_term_taxonomy GROUP BY term_id HAVING COUNT(term_id) > 1; 

2. Проверить на taxonomy столбец в wp_term_taxonomy таблицу, которую вы хотите сохранить, и удалите другую taxonomy запись. Перед удалением обратитесь к №3.

3. Вы также должны удалять записи из wp_term_relationships таблица для соответствующих term_taxonomy_id что вы удаляете из wp_term_taxonomy Таблица.

Наконечник: Сделайте резервную копию своей базы данных перед выполнением любых запросов DELETE в вашей базе данных.

• @Dragomir Ivanov, @Arsalan Mithani Добавление следующей строки — if (is_admin()) return true; потенциально может привести к утечке информации.
• 1 Это сэкономило мне серьезное время, Мария. Благодарность!

Деактивируйте все свои плагины и активируйте их один за другим, это поможет найти виновника. если вы не можете войти в панель управления, используйте FTP и переименуйте каталог плагинов.

Временное исправление — рекомендуется только для постановки

я нашел временное исправление, чтобы отредактировать wp-includes/capabilities.php

Замените этот код

function current_user_can( $capability ) { $current_user = wp_get_current_user(); if ( empty( $current_user ) ) return false; $args = array_slice( func_get_args(), 1 ); $args = array_merge( array( $capability ), $args ); return call_user_func_array( array( $current_user, 'has_cap' ), $args ); } 

С этим

function current_user_can( $capability ) { $current_user = wp_get_current_user(); if ( empty( $current_user ) ) return false; if (is_admin()) return true; $args = array_slice( func_get_args(), 1 ); $args = array_merge( array( $capability ), $args ); return call_user_func_array( array( $current_user, 'has_cap' ), $args ); } 

Это временное решение. Если это сработает, вам все равно придется найти подходящее решение, так как capabilities.php является файлом ядра, и любое обновление переопределит ваш код.

• Это очень плохое решение. Помимо редактирования ядра, он удаляет все проверки возможностей — и не будет никакой разницы между ролями пользователей.
• Спасибо, Матани, ты был единственным писателем в Интернете, который действительно объяснил, где проходит проверка безопасности. Это позволило мне временно приостановить проверку, чтобы исправить поврежденный профиль администратора. Я использовал return true; чтобы эффективно приостановить функцию и разрешить доступ к приборной панели, естественно, потом снова включил ее.
• НИКОГДА не редактируйте основные файлы, так как вы потеряете все изменения, сделанные при обновлении WordPress до более новой версии.
• @ mukto90 в конце уже ясно сказано то, что вы сказали в своем комментарии. Он только показывает, где происходит проверка. Разрешите выделить Это

1 ответ

Лучший ответ