"An error occurred in the upload. Please try again later" in wordpress when uploading images to editor

Question

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.

Answer 1

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.

Answer 2

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

Answer 3

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.

Answer 4

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

Answer 5

Please see this link for more details - it helped me https://sebastian.expert/fix-wordpress-an-error-occurred-in-the-upload-please-try-again-later/

Basically what it says is to use Developer tools in Chrome or Firefox to see the response from async_upload.php file after uploading files (when error message appears). It returns error details in JSON format. Having details it will be easier and a lot faster to resolve the problem.

Answer 6

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.

Answer 7

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.

Answer 8

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.

Answer 9

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.