WordPress ошибка при загрузке во время загрузки произошла ошибка

Во время загрузки произошла ошибка. Пожалуйста, повторите попытку позже.

Работая над очередным сайтом на WordPress столкнулся с такой ошибкой — Во время загрузки произошла ошибка. Пожалуйста, повторите попытку позже. Возникала она при загрузке файлов через медиаменеджер WordPress. Тут стоить уточнить — верстия Worpdress была последняя на данный момент — 3.5.1, но все написанное верно и для более ранней 3.5. При этом на другом хостинге с этим же сайтом такой проблемы не было. Подождав какое-то время и увидев снова Во время загрузки произошла ошибка. Пожалуйста, повторите попытку позже решил что-то предпринимать. Права на папку uploads стояли правильные, русские буквы из имен файлов удалял. Советы, найденные в интернете проблему не решили. И тогда принял решение делать откат WordPress на версию 3.4.2. После этого все заработало как надо.

Во время загрузки произошла ошибка. Пожалуйста, повторите попытку позже.

Меток нет.
Похожие записи

Запись опубликована в рубрике WordPress. Добавьте в закладки постоянную ссылку.

Источник

Для Вас есть бесплатная группа ожидания – ХОЧУ В БЛОГЕРЫ (КЕЙСЫ, ФИШКИ, чего нет в свободном доступе…) делюсь практическими советами и присылаю ценную информацию по развитию блогов на поиске.
А когда будет набор в Школу Блогеров, сообщу Вам заранее. Жду Вас здес…

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

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

Белый фон в библиотеки файлов
При загрузке изображения выдается ошибка — Во время загрузки произошла ошибка. Пожалуйста, повторите попытку позже.
При этом само изображение появляется в библиотеке, на сервере. Но в библиотеки при добавлении из статьи, мы его не видим, и приходится копировать url картинки, чтобы вставить в статью
В админке присутствует пустая белая строка, сразу под главной навигационной панелью.
При установке дефолтного (стандартного) шаблона, проблема может решиться (но не факт!)
Возможна проблема с одобрением комментариев, словно комментарии не добавляются, но на самом деле они уже на сайте… (как будто проблема с ajax или query)

Видео ошибки и решение проблемы (посмотрите до конца, у видео 2 части):

Что нужно чтобы решить проблему с библиотекой файлов, чтобы не возникало проблем с загрузкой изображений?

Вспомнить какой файл в движке или в шаблоне вы редактировали последний раз, и проверить кодировку (должна стоять UTF-8 без BOT)
Для смены кодировки необходим редактор notepad++ (найти можно в гугле, в видео показан сайт…)
Возможно проблема кроется в плагинах, которые пробуем отключать поочередно (но все же, мало вероятно в них)

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

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

А оказалось — что, старый добрый блокнот от виндовс, нужно выкинуть раз и навсегда, и ни в коем случае не редактировать файлы на сервере, через блокнот.

Кто бы мог подумать, но я по-чесноку, не знал, о том, что есть 2 вида кодировки файлов — UTF-8 и UTF-8 (Без BOM) . И все файлы, особенно на движке вордпресс, желательно содержать именно во второй кодировке.

Если сильно не вдаваться в литературу, то суть в том, что когда файл сохранен в стандартной UTF-8 кодировке, у него в самом начале присутствует информация в 3 байта

А если немного углубиться, то когда была разработана ещё кодировка UTF 16 (до UTF , то её разработчики внедрили в неё такую штуку, чтобы была возможность записи символов как прямой, так и в обратной последовательности (нашел инфу на одном умном сайте…). И для того, чтобы программы могли понять в какой последовательности производить чтение символов в кодировке утф 16, была придумана специальная сигнатура под названием BOM (Byte Order Mark), которая и добавляла три дополнительных байта в самом начале документа.

А в кодировке UTF 8, сигнатуры BOM предусмотрено не было, и некоторым программам это мешало читать кодировку Юникод. И выбирая кодировку без BOM, может избавить как от отображения кракозябр (которые кстати могут возникнуть и при смене других кодировок. Сервер работает в одной, а файл даем в другой. В результате чего и получаем каракули на экране…), так и от различных глюков, таких как появился с библиотекой файлов у меня, на движке wordpress.

Просто некоторые программы в Windows не умеют сохранять текст в кодировке в UTF 8 без BOM. Как пример — блокнот. Открывая через блокнот файлы на нашем сервере, и сохраняя их, блокнот сохраняет документ в UTF 8 и добавляет в его начало три дополнительных байта. Вроде мелочь, но как долго она напрягала меня.

Кстати! Если обратите внимание — то под каждой кодировкой, UTF 8 и UTF 8 без BOM — файл будет иметь разный размер.

Тут уже не сложно догадаться от чего возникает проблема с библиотекой файлов и выдается ошибка — Во время загрузки произошла ошибка. Пожалуйста, повторите попытку позже.
Иногда, мы можем покапаться в файлах движка, или в файлах шаблона. А многие могут заметить, как проблема с библиотекой файлов решается, когда ставится дефолтный шаблон wordpress (это просто знак свыше — значит какой то файл шаблона сохранен не в той кодировке. Просто окрываем каждый файл через notepad++ и пробиваем кодировку на нужную. В данном случае делаем всем файлам кодировку UTF 8 без BOM)

Не пугайтесь, что придется менять кучу файлов. По всей видимости проблема кроется в одном, двух файлах…. в который вы не так давно внесли изменения. Может форму подписки добавляли, может ещё что корректировали. Туда, сюда… сохранили пошли к следующему файлу, затем отвлеклись, телек посмотрели — проблема сразу не показалась Вам. Но всё же проблема возникла. А через день, или идем на блог, чтобы написать статейку, и Опа… а картинки не хотят грузиться через библиотеку. Вот и пойми сразу, что к чему. Толи плагин сбой дал, а может что-нибудь на стороне сервера.

И в общем при попытки решить проблему, уходит не мало времени. А добавлять статью можно, и картинки подгружать… Но ко всему прочему, добавляется лишнее движение, которое нам просто не нужно.

Кстати! Не факт, что у вас тоже проблемы с кодировкой… Но судя по всем найденным вопросам в сети, у большинству бы помогла именно эта статья. А так и встречал тех, кто решил проблему с помощью:

Полной переустановкой движка wordpress

Поочередным отключением установленным плагинам (присматриваются особенно к кешируемым плагинам)

…так что же ещё встречал? Мм…ммм…

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

И так месяца три жил с этой бедой. Пока не сел однажды, не выделил пару часиков, чтобы самостоятельно вникнуть в суть этой ошибки на wordpress.

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

А у меня пожалуй всё!

Пишите обязательно — помогло или нет:

Автор публикации

1-2 раза в год, веду до результата в блогинге, при наличии мест.
Для связи: ok.ru/denis.povaga

Комментарии: 2964Публикации: 801Регистрация: 12-03-2013

Источник

Исправляем ошибки при загрузке картинок в WordPress (HTTP Error и др.)

1-2 раза в год, веду до результата в блогинге, при наличии мест.
Для связи: ok.ru/denis.povaga

Комментарии: 2964Публикации: 801Регистрация: 12-03-2013

Источник

Исправляем ошибки при загрузке картинок в WordPress (HTTP Error и др.)

Сегодня рассмотрю несколько ситуаций, когда у вас может появиться ошибка 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' );

Думаю, значения 128M для параметра WP_MEMORY_LIMIT также будет достаточно, особенно при использовании базовых модулей/тем. Иногда данный код не срабатывает, — смотрите как еще можно увеличить PHP Memory Limit в WordPress.

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

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

Для реализации этого подхода в 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' );

6. Настройка ImageMagick через htaccess

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

SetEnv MAGICK_THREAD_LIMIT 1

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

Если код выше не помог, попробуйте другой:

<IfModule mod_security.c>
SecFilterEngine Off
SecFilterScanPOST Off
</IfModule>

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

# Exclude the file upload and WP CRON scripts from authentication
<FilesMatch "(async-upload.php|wp-cron.php|xmlrpc.php)$">
Satisfy Any
Order allow,deny
Allow from all
Deny from none
</FilesMatch>

7. Параметр FcgidMaxRequestLen и ошибка «Обработка изображения не удалась…»

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

При этом, как видите, максимальный размер файла для загрузки позволяет добавлять любые изображения. Более того, “подопытный сайт” находился на сервере с memory_limit под 2 Гб. То есть проблемы с ресурсами хостинга исключены.

Спустя некоторое время поиска причины ошибки я наткнулся на интересную информацию с официального форума wordpress.org:

Во вкладке админки “Здоровье сайта” я увидел, что на сервере действительно было установлено расширение mod_fcgid для Apache. Поэтому решил найти и отредактировать эту проблемную настройку – FcgidMaxRequestLen.

Сложность задачи заключалась еще в том, что работал я не с «классическим хостингом», где всегда можно попросить помощи в тех.поддержке (которая бы сделала всю работу). В моем случае пришлось разбираться самостоятельно, используя панельку ISPmanager.

1. Первым делом надо было отыскать файл конфига, т.к. по указанному в скриншоте выше адресу /etc/apache2/mods-available/fcgid.conf ничего не было. Переходим в ISPmanager в раздел System – пункт File Manager. Там воспользуемся функцией поиска:

Тут два варианта – либо искать по ключу «fcgid» или попытаться найти переменную по содержимому файлов (гораздо медленнее). Предварительно важно выйти в корневую директорию сервера (пункт 2 на картинке выше) чтобы искать по всем файлам.

2. Как только вы обнаружили нужный конфиг (у меня он находился в директории etc/httpd/conf.d/fcgid.conf дважды кликаете по нему и переходите к редактированию. Далее просто указываете значение переменной FcgidMaxRequestLen в байтах.

По умолчанию значение равно 131072, поэтому картинки выше 100 Кб и не грузились. Сделал размер чуть выше 4 Мб. Затем сохраняетесь и важно(!) перезагружаете сервер. Только после этого можно вернуться в админку и проверить все ли ок.

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

Источник

I finally found the solution to this problem which as turns out plagues many wordpress installations. Right after uploading an image through the «add media» button in an editor, the upload would fail with a «an error occurred in the upload error». However after refreshing the image would appear in the media browser window but when inserted into the editor it would show up with width and height both set to 1px.

After searching a lot without any success I solved the problem. Many people reported solving it by disabling all plugins one by one to find which was causing the problem. In my case it was a fresh wordpress installation without anything else, not even custom themes.
So I decided to post it here in case anyone else is search and stumbles upon this post.

asked Feb 12, 2014 at 11:26

I found a simple solution. If you save the post you are working on as a draft, then attempt the upload again, it works. This appears to happen if you have been drafting a document for a long time, without manually saving. Once you manually save, it resets the upload ability somehow, and the problem goes away.

answered Mar 31, 2014 at 14:39

Sometimes this problem comes with uploading/restoring the db-backup from file via phpmyadmin. The import can skip adding auto_increment to wp_posts and wp_postmeta tables at 0 key.

This leads to crash in the further work of the site and eventually you wan’t be able to add new posts/pages («you are currently editing the page that shows your latest posts» instead of the text editor), upload new images (you’ll see the empty window where once was all your image gallery).

The issue can be easily fixed by deselecting the checkbox near the «Do not use AUTO_INCREMENT for zero values» when importing DB through import section of phpmyadmin. However, it still can be imported with errors and you’ll need to add auto_increment to wp_posts and wp_postmeta tables manually after the import complete.

ascripter

5,55512 gold badges45 silver badges67 bronze badges

answered May 3, 2018 at 18:33

Andrei G.Andrei G.

1513 silver badges4 bronze badges

As Indicated by Andrei G, the issue is indeed linked to an auto_increment issue on the database.

Here’s what fixed it for me:

DELETE FROM wp_termmeta  WHERE meta_id=0;
DELETE FROM wp_terms  WHERE term_id=0;
DELETE FROM wp_term_taxonomy  WHERE term_taxonomy_id=0;
DELETE FROM wp_commentmeta  WHERE meta_id=0;
DELETE FROM wp_comments  WHERE comment_ID=0;
DELETE FROM wp_links  WHERE link_id=0;
DELETE FROM wp_options  WHERE option_id=0;
DELETE FROM wp_postmeta  WHERE meta_id=0;
DELETE FROM wp_users  WHERE ID=0;
DELETE FROM wp_posts  WHERE ID=0;
DELETE FROM wp_usermeta  WHERE umeta_id=0;

ALTER TABLE  wp_termmeta ADD PRIMARY KEY(meta_id);
ALTER TABLE  wp_terms ADD PRIMARY KEY(term_id);
ALTER TABLE  wp_term_taxonomy ADD PRIMARY KEY(term_taxonomy_id);
ALTER TABLE  wp_commentmeta ADD PRIMARY KEY(meta_id);
ALTER TABLE  wp_comments ADD PRIMARY KEY(comment_ID);
ALTER TABLE  wp_links ADD PRIMARY KEY(link_id);
ALTER TABLE  wp_options ADD PRIMARY KEY(option_id);
ALTER TABLE  wp_postmeta ADD PRIMARY KEY(meta_id);
ALTER TABLE  wp_users ADD PRIMARY KEY(ID);
ALTER TABLE  wp_posts ADD PRIMARY KEY(ID);
ALTER TABLE  wp_usermeta ADD PRIMARY KEY(umeta_id);

ALTER TABLE wp_termmeta CHANGE meta_id meta_id  BIGINT(20) UNSIGNED NOT NULL AUTO_INCREMENT;
ALTER TABLE wp_terms CHANGE term_id term_id  BIGINT(20) UNSIGNED NOT NULL AUTO_INCREMENT;
ALTER TABLE wp_term_taxonomy CHANGE term_taxonomy_id term_taxonomy_id  BIGINT(20) UNSIGNED NOT NULL AUTO_INCREMENT;
ALTER TABLE wp_commentmeta CHANGE meta_id meta_id  BIGINT(20) UNSIGNED NOT NULL AUTO_INCREMENT;
ALTER TABLE wp_comments CHANGE comment_ID comment_ID  BIGINT(20) UNSIGNED NOT NULL AUTO_INCREMENT;
ALTER TABLE wp_links CHANGE link_id link_id  BIGINT(20) UNSIGNED NOT NULL AUTO_INCREMENT;
ALTER TABLE wp_options CHANGE option_id option_id  BIGINT(20) UNSIGNED NOT NULL AUTO_INCREMENT;
ALTER TABLE wp_postmeta CHANGE meta_id meta_id  BIGINT(20) UNSIGNED NOT NULL AUTO_INCREMENT;
ALTER TABLE wp_users CHANGE ID ID  BIGINT(20) UNSIGNED NOT NULL AUTO_INCREMENT;
ALTER TABLE wp_posts CHANGE ID ID  BIGINT(20) UNSIGNED NOT NULL AUTO_INCREMENT;
ALTER TABLE wp_usermeta CHANGE umeta_id umeta_id  BIGINT(20) UNSIGNED NOT NULL AUTO_INCREMENT;

As taken from here

answered Aug 5, 2020 at 18:28

trolologuytrolologuy

1,8704 gold badges21 silver badges31 bronze badges

Turns out the culprit was imagemagick. I disabled it in php.ini and everything started working again. If your host supports it you can use a custom php.ini file.

answered Feb 12, 2014 at 11:26

JohnJohn

8982 gold badges9 silver badges25 bronze badges

In my case, I had moved moved wordpress to a new server and was getting this error. It turned out that I hadn’t installed imagemagick on the new server.

sudo apt-get install imagemagick

and then a restart of the web server solved the problem.

answered Feb 13, 2014 at 16:09

SteveSongSteveSong

3113 silver badges15 bronze badges

I too had this issue with a plugin I wrote. Root cause seems to be a WordPress interference with the javascript call window.requestAnimFrame . Info provided here for anybody else searching on the error message.

The plugin I wrote was a simple little thing to post a fixed box on the top of the screen that showed browser window size. The plugin would update four times / second using window.requestAnimFrame calls. I’m guessing something in the routine that updated the media upload progress bar interferes with the call. And I was all set to publish that plugin too, sigh.

Not sure of the exact details on why this makes WordPress media uploads fail, but its yet another root cause. Note: the media files did actually upload, but the feedback system just errors out on the admin end. Note: not sure I was supposed to, but I submitted a bug report to core WordPress.

answered Apr 3, 2014 at 2:48

zipzitzipzit

3,6984 gold badges33 silver badges62 bronze badges

My problem was with the functions.php file. The thread here helped me solve the problem.

answered Aug 21, 2017 at 4:15

My problem was an invalid wp-config.php file with an invalid character in it that was breaking the JSON sent back to the browser to confirm the upload. The uploads were actually working, but the browser confirmation wasn’t working.

answered Oct 6, 2020 at 6:19