Wp ошибка http при закачке изображения. Избавляемся от ошибки «http» при загрузке изображений в WordPress. Библиотека GD Library по умолчанию

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

Что вызывает ошибку HTTP во время загрузки в WordPress?

Есть ряд вещей, которые могут привести к ошибке HTTP при попытке загрузить файлы с помощью медиа-загрузчика WordPress. В принципе, WordPress не может понять причину, и поэтому он отображает общее сообщение об ошибке «HTTP error».

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

При этом мы рассмотрим, как устранить и устранить ошибку HTTP во время загрузки мультимедиа в WordPress.

1. Убедитесь, что HTTP-ошибка не временная

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

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

Если все эти шаги приводят к ошибке HTTP, это означает, что ошибка не вызвана временным сбоем и определенно требует вашего непосредственного внимания.

2. Увеличьте предел памяти WordPress

Наиболее распространенной причиной этой ошибки является нехватка памяти для использования WordPress. Чтобы исправить это, вам нужно увеличить объем памяти, который PHP может использовать на вашем сервере.

Вы можете сделать это, добавив следующий код в ваш файл wp-config.php.

define("WP_MEMORY_LIMIT", "256M");

Этот код увеличивает предел памяти WordPress до 256 МБ, чего достаточно для устранения проблем с ограничениями памяти.

3. Измените библиотеку редактора изображений, используемую WordPress.

WordPress работает на PHP, который использует два модуля для обработки изображений. Эти модули называются GD Library и Imagick. WordPress может использовать любой из них, в зависимости от того, какой из них доступен.

Тем не менее, Imagick, как известно, часто сталкивается с проблемами памяти, вызывающими ошибку HTTP во время загрузки изображений. Чтобы исправить это, вы можете сделать библиотеку GD своим редактором изображений по умолчанию.

Вы можете сделать это, просто добавив этот код в файл functions.php вашей темы или плагин для конкретного сайта.

function wpb_image_editor_default_to_gd($editors) { $gd_editor = "WP_Image_Editor_GD"; $editors = array_diff($editors, array($gd_editor)); array_unshift($editors, $gd_editor); return $editors; } add_filter("wp_image_editors", "wpb_image_editor_default_to_gd");

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

Возникновение ошибки «HTTP error» при работе в WordPress может быть вызвано целым рядом причин. Перечислю лишь те, с которыми сталкивался сам, и те эффективные решения, которые были опробованы мной. Я не буду разжевывать все в виде подробного мануала для совсем начинающих веб-мастеров. Рассчитываю на более подготовленного читателя и самого себя, для которого публикую эту серию постов по администрированию WordPress в качестве блокнота на случай внезапно посетившего меня склероза.) В сети полно специализированных ресурсов, где вам все подробно разжуют и распишут в деталях. Я такой задачи себе не ставил. Итак…

Я в своей практике я привык пользовать linux в виде Centos в качестве системной платформы своего web-сервера, поэтому указанные пути и директории расположение конфигурационных файлов применительны именно к этой системе. Не брезгую я менять настройки и через активно пользуемую мной панель управления сервером ISP manager.

В первую очередь, при возникновении такой ошибки наиболее разумно будет посмотреть log ошибок web-сервера. Ищем свежие строчки, в которых упоминаются PUT, GET и POST запросы и читаем их внимательно. Как правило это дает направление, в котором нужно искать решение.

Наиболее частые причины ошибки HTTP (возможна и их комбинация)…

Разрешение загружаемого фото больше допустимого

На собственном опыте заметил, что ошибка может возникать, если ширина загружаемого фото превышает величину, указанную в качестве ширины для формата изображения «Крупный размер» («Large size») в «Настройки — Медиафайлы». Меняем на меньший и пробуем. Я лично для себя выбрал максимальный достаточный размер для публикуемых фото — 1280х720px. Если вы используете свой WordPress для создания фотопортфолио, то тут уже надо исходить из собственных требований к качеству публикуемого фотоматериала.

Следует помнить, что создание копий изображений в разных разрешениях происходит на этапе загрузки файла. Поэтому при изменении предустановленных размеров, пользуйтесь плагинами для regenerate thumbnails (пересоздания миниатюр).

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

Объем загружаемого файла больше допустимого в настройках PHP

Стандартная история. Тут вариантов решения много…

Если хостинг позволяет вносить правки в php.ini, то ищем в нем две директивы и меняем их значение на подходящее, например 32Мб:

Upload_max_filesize = 32M post_max_size = 32M

Второй параметр определяет максимальный размер POST-запросов, который должен быть равен или быть больше максимального размера файлов.

Не забываем перегрузить web-сервер Apache через панель или SSH командой:

Если доступа к php.ini нет, пробуем то же самое прописать через.htaccess в корне вашего WordPress:

Php_value upload_max_filesize 32M php_value post_max_size 32M

Если вы пользуете в качестве web-сервера на Apache, а Nginx, то насколько я помню nginx не понимает.htaccess, но поменять настройки PHP можно через конфигурационный файл nginx.conf. Если PHP настроен как FastCGI клиент, то это делается через директиву fastcgi_param:

Fastcgi_param PHP_VALUE upload_max_filesize=32M; fastcgi_param PHP_VALUE post_max_size=32M;

Также не лишним будет проверить значение nginx-директивы client_max_body_size, отвечающей за максимальный размер данных передаваемых в HTTP запросах. Она тоже влияет на максимальный размер загружаемых файлов.Оно должно быть не меньше вышеуказанных параметров.

Не забываем после внесения изменений в конфигурационные файлы nginx или Apache перезагрузить службу через панель управления или через SSH командами типа:

Ну и последний вариант — попробовать расширить возможности PHP непосредственно из конфигурационного файла вашего WordPress с помощью функции ini_set():

Ini_set("upload_max_size", "32M"); ini_set("post_max_size", "32M");

В WordPress есть специальный фильтр upload_size_limit используемый в функции wp_max_upload_size().

Этот фильтр отвечает за максимальный размер загружаемых файлов. Значение по умолчанию - наименьшее из upload_max_filesize и post_max_size из файла php.ini, и использовать данный фильтр, можно только в пределах этого значения.

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

Уменьшить максимальный размер загружаемых файлов можно через фильтр в functions.php вашей темы:

Add_filter("upload_size_limit", "16M");

Ошибка client intended to send too large body

Если в логах nginx (/var/log/nginx/error.log) мы видим ошибку типа:

XXXX#0: *XXXXXXXXXX client intended to send too large body: XXXXXXX bytes, client: XX.XXX.XXX.XX, server: XXXXX, request: «POST /engine/ajax/upload.php HTTP/1.1», host: «XXX.com»

то это верный признак того, что надо увеличить значение директивы client_max_body_size в конфигурационном файле nginx.conf в блоке http {}.

Делаем это через панель управления или через SSH и редактор VI например:

# vi /etc/nginx/nginx.conf client_max_body_size 100M; # service nginx reload

Выход из редактора VI осуществляется командами:wq с сохранением содержимого или:q (:q!) без сохранения.

Директива client_max_body_size задаёт максимально допустимый размер тела запроса клиента, указываемый в поле “Content-Length” заголовка запроса. Если размер больше заданного, то клиенту возвращается ошибка 413 (Request Entity Too Large). Следует иметь в виду, что браузеры не умеют корректно показывать эту ошибку. Установка параметра размер в 0 отключает проверку размера тела запроса клиента.

Еще варианты борьбы с http error через.htaccess

Вставляем в конец.htaccess файла следующий код:

SecFilterEngine Off SecFilterScanPOST Off

Мне сложно объяснить сакральный смысл данного кода, но иногда помогает.

Также лично на своем опыте убедился в действенности еще одной волшебной директивы, которую надо вставить в самое начало.htaccess:

SetEnv MAGICK_THREAD_LIMIT 1

В моей практике это однажды решило проблему, когда ошибка http вылетала при попытке загрузить файл более 1Мб, несмотря на все прописанные гораздо большие максимально допустимые объемы загружаемого файлов и команды способами описанными

Конфликт плагинов

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

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

Я запускаю WP 3.0.1 на общем хосте, используя PHP5. У меня возникают проблемы с загрузкой файлов, которые немного больше через загрузчик мультимедиа в разделе администрирования WP.

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

Это происходит только в файлах, которые немного больше, то есть в файле размером 20 МБ. Кажется, что файл размером 5 Мб работает нормально. Странно, что в прошлом мы загрузили 40-мегабайтные файлы без проблем.

Вот шаги, которые я предпринял до сих пор, чтобы попытаться исправить ситуацию:

• Двойной проверенный php.ini, чтобы увеличить загрузку, публикацию и объем памяти были достаточно высокими.
• Обновлен.htaccess, чтобы включить фильтр, который был найден мной в другом месте.
• Двойной проверял все права доступа к файлам через ftp, чтобы убедиться, что они были 755.
• Вызов хоста - "Они не поддерживают сторонние скрипты" (я ненавижу IPower)
• Пробовал с различными аудиофайлами аналогичного размера.
• Отключить все плагины

У вас, ребята, есть еще идеи относительно того, что может вызвать неопределенную "HTTP-ошибку". проблема?

Спасибо заранее.

10 ответов

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

Поскольку "они не поддерживают сторонние скрипты", я предполагаю, что вы находитесь в среде совместного размещения, поэтому на вашем сервере что-то может измениться, если вы ничего не делаете. Возможные решения:

У меня была аналогичная проблема с Nginx и PHP5-FPM (и WordPress 4.1).

Симптомы: файл (< 5MB, так относительно небольшой) частично передается через передачу, как указано индикатором выполнения, когда вы получаете сообщение об ошибке HTTP.

Даже если вы установили upload_max_filesize в свой php.ini, вы также должны проверить post_max_size как минимум. Не забудьте перезапустить php5-fpm.

Если он все еще не работает, отредактируйте файл nginx.conf (в Debian/Ubuntu it/etc/nginx/nginx.conf) и добавьте его в блок http :

Client_max_body_size 100m;

Затем перезапустите Nginx.

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

Наконец, мы выяснили, что wordpress "Ошибка HTTP" при загрузке изображений происходило из-за изменения на стороне сервера. Хостинг-компания решила добавить ускорение APC на сервер, чтобы повысить стабильность и скорость сервера. Ускорение APC должно работать только с FastCGI, а не с su, поэтому они устанавливают PHP как FastCGI.

При использовании PHP в качестве FastCGI, если вы пытаетесь загрузить файл размером более 128 КБ, возникает ошибка "mod_fcgid: длина запроса HTTP 131388 (до сих пор) превышает MaxRequestLen (131072)" и вызывает ошибку внутреннего сервера 550. Это происходит потому, что значение директивы MaxRequestLen по умолчанию установлено на 131072 байта (128 КБ). Один из способов исправить это (если сервер использует Plesk), - отредактировать /etc/httpd/conf.d/fcgid.conf и установить MaxRequestLen на более высокое значение, например 15MB (MaxRequestLen 15728640). Если сервер использует cPanel, это изменение может быть выполнено через WHM сервера.

Итак, если вы можете загружать изображения до 128 КБ, это решение вашей проблемы.

Для будущих читателей просто удалось найти решение для этого после трудного дня поиска.

Есть параметр в файле fcgid.conf(для меня в /etc/apache 2/mods-enabled): FcgidMaxRequestLen . См. https://httpd.apache.org/mod_fcgid/mod/mod_fcgid.html#fcgidmaxrequestlen

Я установил в байтах соответствующую длину и все работает. Кажется, что apache изменили свое мышление на значение по умолчанию (которое теперь составляет 131072 байта):

До версии 2.3.6 это значение по умолчанию равняется 1 ГБ. Большинство пользователей более ранних версий должны использовать эту директиву для установления более разумного предела.

У меня была такая же проблема, когда я пытался загружать носители, за исключением того, что получил "HTTP-ошибку" в файлах размером более 124 КБ! WP 3.3.1, PHP 5.2.

Я позвонил своему хосту, и они увеличили память до 64M (также изменили это в wp-config) и upload_limit до 8 МБ (по умолчанию было 2 МБ). Это не сработало, поэтому я прибегал почти ко всем остальным, от вмешательства в.htaccess, чтобы переустановить WP для установки нового WP на другом сервере, но все указывало на проблему с сервером. Я снова позвонил хозяину и поговорил с другим специалистом, который увеличил допустимую настройку длины запроса HTTP.

Я пробовал все часто предлагаемые изменения php.ini, а также изменения wp-config без везения. Наконец-то выяснилось, что кто-то предлагает просмотреть информацию о async-upload.php XHR в моем браузере и выяснил, что по какой-то причине наш брандмауэр помечает загрузку в качестве трояна (MalAgent.H_9218). Поэтому не забудьте проверить там, он также может идентифицировать другие возможные проблемы с загрузкой.

Сегодня рассмотрю несколько ситуаций, когда у вас может появиться ошибка HTTP при загрузке фото в WordPress, и заодно расскажу что в этом случае делать. Данная проблема возникает сразу после клика по кнопке «Добавить медиафайл» на странице редактирования поста либо в разделе «Медиафайлов», — как только вы выбираете файл на компьютере, который хотите использовать. При этом в окне загрузчика отобразится фраза «HTTP Error».

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

Общие методы для HTTP ошибки в WordPress

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

1. Проблема с хостингом

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

Если глюк никуда не делся, надо выбрать какой-то другой файл для добавления: с более простым именем (без спец.символов и русских букв) или вообще не того формата (например, PNG вместо JPG).

Иногда хостеры устанавливают ограничение по весу импортируемых на сайт объектов — 2Мб, 4Мб, 8Мб и т.п. Используйте для повторного теста изображение полегче.

При загрузке картинки в WordPress ошибка HTTP может возникать, когда у определенной директории хостинга нет разрешения на запись. Заходите на FTP в каталог wp-content/uploads/ и дальше смотрите права доступа у нужной вам папки.

Если у вас в WP-проекте графика размещаются по годам и месяцам, то следует проверять соответствующий адрес, например, wp-content/uploads/2018/10 . Добавление файлов на сервер допускается при значении «775» / «777», тогда как «666» или «664» данную процедуру запрещают. В последних двух ситуациях просто меняете права доступа для соответствующей папки.

2. Программная проблема

Бывает, что в определенном конкретном браузере по каким-то мифическим причинам не хотят выполняться те или иные скрипты. То ли в силу старых их версий, то ли из-за установленных дополнений, но так иногда случается. Просто попробуйте другой браузер. Еще одна фишка, связанная с этим же программным обеспечением — очистка локального кэша (желательно тоже проверить).

Второй важный нюанс в этом «подразделе» — старая версия PHP на сервере. Вордпресс, начиная с ветки 3.2 требует минимально PHP 5.2.4. Проверьте/обновите это ПО самостоятельно или обратитесь к своему хостеру за помощью.

3. Классические Вордпресс техники

Данные «махинации» следует выполнять практически в любых проблемах с системой. Когда в WordPress во время загрузки произошла ошибка, то первым делом отключаете все сторонние плагины.

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

4. Увеличиваем memory_limit

Пункт выделил в отдельный, так как он частенько встречается — наша CMS весьма прожорлива к ресурсам.

В общем случае вам нужно подправить файл wp-config.php, находящийся в корневом каталоге хостинга. Прописываете в нем строку:

define("WP_MEMORY_LIMIT", "256M");

define("WP_MEMORY_LIMIT", "256M");

5. Библиотека GD Library по умолчанию

Комплект WP CMS содержит 2 графических библиотеки для обработки — Imagick и GD Library. За первой из них разработчики время от времени замечали HTTP ошибки при загрузке WordPress изображений, поэтому рекомендуется указывать инструментом по умолчанию именно вторую.

Для реализации метода в functions.php пишем:

function wp_default_image_editor( $editors ) { $gd_editor = "WP_Image_Editor_GD" ; $editors = array_diff ( $editors , array ( $gd_editor ) ) ; array_unshift ( $editors , $gd_editor ) ; return $editors ; } add_filter( "wp_image_editors" , "wp_default_image_editor" ) ;

function wp_default_image_editor($editors) { $gd_editor = "WP_Image_Editor_GD"; $editors = array_diff($editors, array($gd_editor)); array_unshift($editors, $gd_editor); return $editors; } add_filter("wp_image_editors", "wp_default_image_editor");

6. Правка.htaccess

Дополнив немного.htaccess, у вас получится контролировать использование библиотекой Imagick ресурсов сервера. Находите файл в корневом каталоге и через FTP редактируете его, добавляя строку:

SecFilterEngine Off SecFilterScanPOST Off

Либо вариант:

# Exclude the file upload and WP CRON scripts from authentication Satisfy Any Order allow,deny Allow from all Deny from none

На этом, в принципе, все. Начинайте с самых простых подходов, приведенных в начале, а дальше уже придется переходить на более сложные. Конечно, неприятно получать ошибку HTTP при загрузке WordPress фото или картинок, но, как видите, это не критично. Кто знает еще какие-то методы? — делитесь ими ниже.

Привет, читатели!

Свободного времени у меня теперь совсем мало, работаю четыре полных дня в неделю, на пятый езжу в универ, по вечерам в бассейн. Работа мне очень нравится, развиваюсь в области SEO, общаюсь с интересными людьми и успеваю находить время на свои проекты и, конечно, блог.

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

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

Ошибка HTTP WordPress (загрузка картинок)

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

1. У вас на хостинге закончилось дисковое пространство. В этом случае нужно удалить лишние файлы, либо выяснить у техподдержки, откуда они берутся (возможно, какие-то бэкапы хранятся вместе с файлами сайта). Или же перейти на новый тариф, где выделено больше дискового пространства.
2. Вы переехали на хостинг, который имеет другую версию php, не совместимую с вашим сайтом. Решить за вас эту проблему просто обязана техподдержка хостинга.
3. Файл, который вы пытаетесь загрузить, слишком большого размера. В настройках php указан максимальный размер загружаемых файлов, и эти настройки можно изменить, если хотите.
   Если у вас есть доступ к файлу php.ini, найдите в нем строку upload_max_filesize и измените значение этого параметра на большее.
   Другой способ: отредактируйте файл.htaccess, находящийся в корне вашего сайта. Добавьте в его конец строки:

   SecFilterEngine Off SecFilterScanPOST Off

Ошибка 500 на блоге WordPress

Это внутренняя ошибка сервера (Internal Server Error). Причин может быть масса. В первую очередь вспоминайте, что вы делали с блогом: возможно, установили какой-то плагин, тогда нужно попробовать его удалить. Если не знаете, в каком именно плагине дело, пробуйте деактивировать все плагины и методом тыка определить виновника.

Попробуйте также деактивировать тему блога, замените ее на другую.

Можно включить режим отладки для получения большей информации. Для этого отредактируйте файл wp-config.php. В нем нужно найти строчку DEFINE (‘WP_DEBUG’, False); и заменить в ней False на True. После этого сообщения об ошибках будут появляться прямо на страницах сайта и в админке. После устранения проблемы выключите режим отладки.

Проблема может быть в файле.htaccess. Попробуйте заменить его на более раннюю версию из бэкапа (читайте о ). Либо же вовсе удалить его и посмотреть, что будет.

Если ничего не приносит результата, скачайте свежий установочник WordPress и заново залейте на хостинг папки wp-includes и wp-admin.

Ошибка 403 - Forbidden в WordPress

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

1. В файле.htaccess прописан код, запрещающий доступ к сайту:

   1 2	order deny, allow deny from all

   order deny,allow deny from all

   Такой код рассматривается в статье про , когда спамер добавляется в черный список.

2. Выставлены неправильные блога. Изучите этот вопрос в соответствующей статье.
3. Есть какие-то проблемы с хостингом. Не советую тратить свое время на выяснение, потому что для этого существует техподдержка.

Проблема с хостингом

Если ваш сайт нормально работал, а потом вдруг перестал грузиться, а браузер выдает подобные сообщения:

Скорей всего проблема в хостинге. Нужно срочно на писать в техподдержку, а не ждать, пока проблема сама решиться. Во-первых, это поможет скорее решить проблему, а во-вторых, вы обратите внимание хостинга на то, что их косяк замечен и вы, как клиент, недовольны.

Бывает и такое, что не только ваш блог не работает, но сайт хостинг-провайдера не подает признаков жизни. Не самая приятная ситуация, т.е. сделать вы ничего не можете. Остается только ждать, скорее всего, у хостера ведутся какие-то технические работы или на них обрушились DDOS-атаки или еще какой-то сбой.

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

WordPress ошибка базы данных

Бывает, что WordPress не может получить доступ к базе данных, тогда он выдает ошибку соединения с MySQL. Чаще всего причина кроется в том, что при вы неправильно прописали доступы к БД. Делается это в файле wp-config.php, проверьте правильность введенных данных. Если вы не находите ошибку, обратитесь в техподдержку хостинг-провайдера.

WordPress проблемы с кодировкой

Движок WordPress работает в кодировке UTF-8. Может произойти какой-то сбой с кодировкой страниц вашего блога, и вместо текста вы увидите кракозябры. Попробуйте опять-таки отредактировать файл.htaccess, лежащий в корневой директории сайта. Нужно дописать в конец файла строки:

AddDefaultCharset UTF-8

Другой вариант:

1 2 3

CharsetDisable On CharsetDefault UTF- 8 CharsetSourceEnc UTF- 8

CharsetDisable On CharsetDefault UTF-8 CharsetSourceEnc UTF-8

В другом случае проблема может крыться в базе данных. Зайдите в PhpMyAdmin и кодировку таблиц БД, она должна быть в utf8_general_ci. Как пользоваться PhpMyAdmin подробно разбиралось .

Синтаксическая ошибка

В режиме отладки, о котором говорилось выше (WP_DEBUG) может выйти синтаксическая ошибка, например такая:

Это распространённая проблема среди новичков, сами по себе такие ошибки не появляются. Скорей всего, вы редактировали код или накосячили. Не стоит бояться подобных сообщений, ведь они созданы, чтобы нам помогать. Обычно в сообщении написано, из-за чего возникла ошибка. В моем примере ошибка появилась потому, что не поставлена точку с запятой (;) в файле «functions.php», в строке 4. Заходим в файл functions.php, ищем строку 4 и исправляем.

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

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

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