Во время загрузки произошла ошибка. Пожалуйста, повторите попытку позже.
Работая над очередным сайтом на WordPress столкнулся с такой ошибкой — Во время загрузки произошла ошибка. Пожалуйста, повторите попытку позже. Возникала она при загрузке файлов через медиаменеджер WordPress. Тут стоить уточнить — верстия Worpdress была последняя на данный момент — 3.5.1, но все написанное верно и для более ранней 3.5. При этом на другом хостинге с этим же сайтом такой проблемы не было. Подождав какое-то время и увидев снова Во время загрузки произошла ошибка. Пожалуйста, повторите попытку позже решил что-то предпринимать. Права на папку uploads стояли правильные, русские буквы из имен файлов удалял. Советы, найденные в интернете проблему не решили. И тогда принял решение делать откат WordPress на версию 3.4.2. После этого все заработало как надо.
Во время загрузки произошла ошибка. Пожалуйста, повторите попытку позже.
Меток нет.
Похожие записи
Запись опубликована в рубрике WordPress. Добавьте в закладки постоянную ссылку.
Решений проблемы есть несколько. Судя по своему опыту Вам скорей всего подойдет такое решение:
добавить в wp-config.php данный код (например после строки — /* Это всё, дальше не редактируем. Успехов! */)
define('CONCATENATE_SCRIPTS', false);
Если не поможет — необходимо найти в файле functions.php(находится в папке wp-includes в каталоге вашего сайта) строку
function wp_ext2type( $ext )
и добавить в данную функцию строку
'image' => array( 'jpg', 'jpeg', 'gif', 'tiff', 'png'),
так чтобы функция стала выглядеть как
function wp_ext2type( $ext ) {
$ext2type = apply_filters( 'ext2type', array(
'image' => array( 'jpg', 'jpeg', 'gif', 'tiff', 'png'),
'audio' => array( 'aac', 'ac3', 'aif', 'aiff', 'm3a', 'm4a', 'm4b', 'mka', 'mp1', 'mp2', 'mp3', 'ogg', 'oga', 'ram', 'wav', 'wma' ),
'video' => array( 'asf', 'avi', 'divx', 'dv', 'flv', 'm4v', 'mkv', 'mov', 'mp4', 'mpeg', 'mpg', 'mpv', 'ogm', 'ogv', 'qt', 'rm', 'vob', 'wmv' ),
'document' => array( 'doc', 'docx', 'docm', 'dotm', 'odt', 'pages', 'pdf', 'rtf', 'wp', 'wpd' ),
'spreadsheet' => array( 'numbers', 'ods', 'xls', 'xlsx', 'xlsm', 'xlsb' ),
'interactive' => array( 'swf', 'key', 'ppt', 'pptx', 'pptm', 'pps', 'ppsx', 'ppsm', 'sldx', 'sldm', 'odp' ),
'text' => array( 'asc', 'csv', 'tsv', 'txt' ),
'archive' => array( 'bz2', 'cab', 'dmg', 'gz', 'rar', 'sea', 'sit', 'sqx', 'tar', 'tgz', 'zip', '7z' ),
'code' => array( 'css', 'htm', 'html', 'php', 'js' ),
));
foreach ( $ext2type as $type => $exts )
if ( in_array( $ext, $exts ) )
return $type;
}
После этого загрузка должна заработать корректно.
Если и после этого не работает, проверьте права на папку «uploads» — должны быть 755 или 777.
1
Если при попытке загрузить файл в админке WordPress появляется сообщение об ошибке
Не могу создать директорию /home/…/public_html/…/wp-content/uploads/… Проверьте, доступна ли родительская директория для записи (Права доступа должны быть 755, 775 либо 777 в зависимости от настроек вашего сервера).
Это значит, что у вас не выставлены права доступа на запись в папку для загрузки файлов или задан неверный путь к этой папке
Права доступа
Для того чтобы изменить права доступа к папке uploads, можно, например, зайти на CPanel в Диспетчер файлов и выбрать команду Изменить разрешения или в Total Commander в меню Файлы команду Изменить артибуты.
Путь к папке
После переноса блога WordPress на новое место в нем может сохраняться старый путь к папке uploads. В этом случае из сообщения об ошибке понятно, что WordPress пытается создать директорию не там, где нужно. Для того чтобы задать правильный путь, зайдите в админке в Настройки, Разное.
Интересно, что в админке WordPress (подсказал Igor@Netovich) нет ссылки на страницу со всеми опциями, на которой также можно все изменять, в том числе и upload_path. Это страница вида
http://mysite.ru/wp-admin/options.php
Если в этих настройках у вас все правильно, обращайтесь к администратору хостинга.
P.S. Если имена файлов с русскими символами, попробуйте заменить их латинскими.
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
1
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
5
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,69512 gold badges45 silver badges68 bronze badges
answered May 3, 2018 at 18:33
Andrei G.Andrei G.
1513 silver badges5 bronze badges
1
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,9104 gold badges21 silver badges32 bronze badges
2
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,7864 gold badges35 silver badges63 bronze badges
1
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
Matthew LockMatthew Lock
13.2k12 gold badges92 silver badges130 bronze badges
![error[1]](https://leadinlife.info/wp-content/uploads/2014/06/error1.jpg)
Приветствую! Есть вещи которые не столь страшные, но в тоже время могут выбить нас из колеи комфорта. Сегодня у меня техническая статья, связанная с блогом на вордпресс. Долгое время у меня был реальный глюк с библиотекой файлов, и при попытки опубликовать очередную статью на блоге с картинкой, приходилось делать лишние телодвижения, которые со временем всё больше напрягали.
В общем библиотека, не подгружала напрямую изображения и выдавала ошибку — Во время загрузки произошла ошибка. Пожалуйста, повторите попытку позже. Возможно многие сталкиваются с подобной проблемой, когда Библиотека WordPress висит на белом фоне, картинки добавляются на сервер, но в самой библиотеки не хотят отображаться…
- Белый фон в библиотеки файлов
- При загрузке изображения выдается ошибка — Во время загрузки произошла ошибка. Пожалуйста, повторите попытку позже.
- При этом само изображение появляется в библиотеке, на сервере. Но в библиотеки при добавлении из статьи, мы его не видим, и приходится копировать url картинки, чтобы вставить в статью
- В админке присутствует пустая белая строка, сразу под главной навигационной панелью.
- При установке дефолтного (стандартного) шаблона, проблема может решиться (но не факт!)
- Возможна проблема с одобрением комментариев, словно комментарии не добавляются, но на самом деле они уже на сайте… (как будто проблема с ajax или query)
Видео ошибки и решение проблемы (посмотрите до конца, у видео 2 части):
Что нужно чтобы решить проблему с библиотекой файлов, чтобы не возникало проблем с загрузкой изображений?
- Вспомнить какой файл в движке или в шаблоне вы редактировали последний раз, и проверить кодировку (должна стоять UTF-8 без BOT)
- Для смены кодировки необходим редактор notepad++ (найти можно в гугле, в видео показан сайт…)
- Возможно проблема кроется в плагинах, которые пробуем отключать поочередно (но все же, мало вероятно в них)
![reshenie-voprosy[1]](https://leadinlife.info/wp-content/uploads/2014/06/reshenie-voprosy1.jpg)
И вроде всё это ерунда с одной стороны… Ну зайди лишний раз в библиотеку, скопируй ссылку на изображение, а потов воткни фото в статью, подгрузив урл картинки. Но эти лишние движения со временем так надоедают, что не хочется порой писать даже статью на блог. И вот сегодня было решено от этого глюка избавиться во чтобы то не стало. Тем более в интернете на эту тему реально тишина… Все либо ставят ворпресс с нуля, переустанавливая, либо как то случайно натыкаются, проблему решают, но однажды она может возникнуть вновь, а решения не известно.
В общем, во многом, методом тыка добрался я до этой проблемы. И не знаю на 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 — файл будет иметь разный размер.
, то её разработчики внедрили в неё такую штуку, чтобы была возможность записи символов как прямой, так и в обратной последовательности (нашел инфу на одном умном сайте…). И для того, чтобы программы могли понять в какой последовательности производить чтение символов в кодировке утф 16, была придумана специальная сигнатура под названием BOM (Byte Order Mark), которая и добавляла три дополнительных байта в самом начале документа.Тут уже не сложно догадаться от чего возникает проблема с библиотекой файлов и выдается ошибка — Во время загрузки произошла ошибка. Пожалуйста, повторите попытку позже.
Иногда, мы можем покапаться в файлах движка, или в файлах шаблона. А многие могут заметить, как проблема с библиотекой файлов решается, когда ставится дефолтный шаблон wordpress (это просто знак свыше — значит какой то файл шаблона сохранен не в той кодировке. Просто окрываем каждый файл через notepad++ и пробиваем кодировку на нужную. В данном случае делаем всем файлам кодировку UTF 8 без BOM)
Не пугайтесь, что придется менять кучу файлов. По всей видимости проблема кроется в одном, двух файлах…. в который вы не так давно внесли изменения. Может форму подписки добавляли, может ещё что корректировали. Туда, сюда… сохранили пошли к следующему файлу, затем отвлеклись, телек посмотрели — проблема сразу не показалась Вам. Но всё же проблема возникла. А через день, или идем на блог, чтобы написать статейку, и Опа… а картинки не хотят грузиться через библиотеку. Вот и пойми сразу, что к чему. Толи плагин сбой дал, а может что-нибудь на стороне сервера.
И в общем при попытки решить проблему, уходит не мало времени. А добавлять статью можно, и картинки подгружать… Но ко всему прочему, добавляется лишнее движение, которое нам просто не нужно.
Кстати! Не факт, что у вас тоже проблемы с кодировкой… Но судя по всем найденным вопросам в сети, у большинству бы помогла именно эта статья. А так и встречал тех, кто решил проблему с помощью:
Полной переустановкой движка wordpress
Поочередным отключением установленным плагинам (присматриваются особенно к кешируемым плагинам)
…так что же ещё встречал? Мм…ммм…
В общем, кто что не советовал многим, говорили и проблемы со стороны хостинга могут быть… и проблемы в каком-нибудь плагине, не известно каком. В общем ребята разбирайтесь сами, всем говорили. Так и я раз в месяц смотрел быстрое решение этой проблемы, и не находил…
И так месяца три жил с этой бедой. Пока не сел однажды, не выделил пару часиков, чтобы самостоятельно вникнуть в суть этой ошибки на wordpress.
В общем, сильно не грузите меня если это вам не поможет. Потому как 100% должно помочь именно это (смена кодировки файлов)! В любом случае пишите в комментариях, чем смог помочь помог. Если вам не помогло, то думаю найдутся желающие развить эту тему до полного решения возможной проблемы.
А у меня пожалуй всё!
Пишите обязательно — помогло или нет: