HTTP Error when uploading images on PHP 7.1.7

[robhindle]

I experienced a problem with image upload, looks like a problem with image.php and/or upload.php

Reverting to a prior version of PHP resolved it for now.

For a more detailed explanation of the problem and my actions see ​https://wordpress.org/support/topic/http-error-115/#post-9524067

[joemcgill]

Hi @robhindle,

Can you check to see if you are using a compatible version of ImageMagick + the right Imagick PHP extension for that version, and/or a compatible version of GD?

[robhindle]

with PHP 7.0.23 imagick module version is V3.4.1
ImageMagick library vsn: ImageMagick 6.7.8-9 2016-06-16 Q16 ​http://www.imagemagick.org

with PHP 7.1.9 module version is V3.4.3 RC1
ImageMagick library vsn: 6.7.8-9 2016-06-16 Q16 ​http://www.imagemagick.org

[WraithKenny]

Might be related to a PHP 7.1 change: ​http://php.net/manual/en/migration71.incompatible.php#migration71.incompatible.empty-string-index-operator

"Applying the empty index operator to a string (e.g. $str[] = $x) throws a fatal error instead of converting silently to array."

In PHP < 7.1, you could have

$variable = ''; // say, from an empty return on `get_post_meta()`
$variable['key'] = 'anything';

This will turn into a fatal error on PHP >= 7.1

I believe there are probably a few places in core where this is happening, as well as countless plugins. I'll make a ticket for that.

[dd32]

Hey @robhindle

Would you be able to check your PHP errors for the exact error which PHP is encountering?
Were you able to attempt deactivating plugins to see if that helped?

I've just tested WordPress trunk & 4.8 on PHP 7.1.9 with (and without) ImageMagick 3.4.3 (lib 6.7.2-7) and I don't see any issues immediately.

as @WraithKenny says, this could quite possibly be due to a plugin with code incompatible with PHP 7.1, although I'm not aware of any locations in core which would be affected by the stated change.

[robhindle]

Errors from log file are:
[Sat Sep 23 16:04:32.736522 2017] [proxy_fcgi:error] [pid 27185:tid 140636833384192] (104)Connection reset by peer: [client 80.0.10.2:49601] AH01075: Error dispatching request to :, referer: ​https://pdmhs.co.uk/wp-admin/upload.php

[Sat Sep 23 16:14:56.993005 2017] [proxy_fcgi:error] [pid 27188:tid 140636883740416] [client 80.0.10.2:49723] AH01071: Got error ‘PHP message: PHP Warning: Illegal string offset ‘width’ in /var/www/vhosts/pdmhs.co.uk/httpdocs/wp-content/themes/twentyeleven/image.php on line 34\nPHP message: PHP Warning: Illegal string offset ‘height’ in /var/www/vhosts/pdmhs.co.uk/httpdocs/wp-content/themes/twentyeleven/image.php on line 35\n’, referer: ​https://pdmhs.co.uk/wp-admin/upload.php?item=2482

I was reluctant to deactivate plugins as without them the site's a mess but I summoned the courage, switched to PHP 7.1.9 then progressively re-enabled, testing image upload as I went along. Now I am confused, when I'd finished adding them all back image upload was still working. I rechecked imagemagick version in case of update at the server - no change.

[dd32]

@robhindle Thanks, but unfortunately neither of those are very useful. I was hopeful that there'd be something labeled a PHP Fatal Error available

The first is PHP-fpm's internal error, not the actual fatal error from the PHP worker, which doesn't reveal anything. It's simply saying PHP didn't return it any data, most likely due to it hitting a fatal error.

The second is from the theme (on another HTTP request, ~10 minutes later), which doesn't impact the upload screen, it's saying that for some reason the images metadata in the database is corrupt/incomplete, most likely due to the upload fatal error being hit.

[tr1988]

Exactly the same issue here too with WordPress 4.8.2. Switching PHP from v7.1.9 to v7.0.23 fixes the problem for me.

Also getting the same "Connection reset by peer" error in the PHP logs, but nothing else relevant.

[joemcgill]

Generally, when we see this error it's a misconfiguration with the Imagick PHP extension, so that's where I'd check first. On a broken environment, you can try switching to GD as the image handler to see if that, in fact, is the culprit.

This filter will reprioritize GD as the default image editor used by WordPress:

add_filter( 'wp_image_editors', 'change_graphic_lib' );
   
function change_graphic_lib() {
    return array( 'WP_Image_Editor_GD', 'WP_Image_Editor_Imagick' );
}

[kirasong]

I was not able to reproduce this on a PHP 7.1.9 install with the following configuration/versions of related libraries (retrieved via Debug Media plugin):

Active Editor	WP_Image_Editor_Imagick
Imagick Module Number	1655
ImageMagick Version	ImageMagick 6.7.7-10 2017-07-15 Q16 http://www.imagemagick.org
GD Version	bundled (2.1.0 compatible)
Ghostscript Version	9.05
Memory Limit	128M
Max Execution Time	30
Max Input Time	-1
Upload Max Filesize	64M
Post Max Size	65M

Imagick Resource Limits
Imagick area limit	2 GB
Imagick disk limit	-1
Imagick file limit	6000
Imagick map limit	2 GB
Imagick memory limit	1,000 MB
Imagick thread limit	Not Available

[joemcgill]

For the purposes of 4.9, I don't see this currently being a blocker, and is probably an ImageMagick/Imagick server level issue and not a core issue based on observations so far, but I want to keep this open through the release so it stays front of mind.

[SergeyBiryukov]

Looks like there are no actionable items for 4.9 here. 4.9-beta3 is in a few hours, so I'm punting.

[joemcgill]

Given the lack of further info or additional reports, I'm closing this as invalid. If someone is able to reproduce or add additional info, please feel free to reopen.

[dd32]

#42843 was marked as a duplicate.

[dd32]

Re-opening based on the further report in #42843

[mbeerli]

Hi,
I filled 42843 but with WP 4.9.1 and php 7.1 (see screenshot in 42843)
I am hosted on Godaddy with php 7.1.7.
I tried uploading about 15 times always the same error. "Http error"
Then I searched online for possible solutions and found imagick as a keyword and remembered it in the php settings on the godaddy control panel. I unchecked it, tried uploading and it worked first time.
Version 4.9.1 is not an option below in the dropdown list

[kirasong]

HI @mbeerli! Thanks much for the report!

Do all image uploads fail for you with Imagick enabled, or just this one?

Would it be possible for you to upload an example image that fails to the ticket so that we can try to reproduce?

Replying to mbeerli:

Hi,
I filled 42843 but with WP 4.9.1 and php 7.1 (see screenshot in 42843)
I am hosted on Godaddy with php 7.1.7.
I tried uploading about 15 times always the same error. "Http error"
Then I searched online for possible solutions and found imagick as a keyword and remembered it in the php settings on the godaddy control panel. I unchecked it, tried uploading and it worked first time.
Version 4.9.1 is not an option below in the dropdown list

[mbeerli]

Hello,
I uploaded OE_compare_eggs.jpg which failed about 15 times (never succeeded), usually trying it 5 to 6 times and it would work. Not that time. Hope it helps to narrow down the issue. Otherwise I could also do some tests for you on my site by enabling this php support for imagick again.

Other feedback:
My wife does many more uploads to her site and since the change of imagick she has no further problems. Before when she uploaded 10 pictures about 6 failed, or uploading 3 and 2 failed. Then uploading 5 and one was vertical versus horizontal that failed and pictures thereafter. So we tried all horizontal first, then all verticals, it was better but not good. Now it seems much better. I do not get the constant complain from her.

[mbeerli]

These are the files WP creates when uploading one large image. Maybe this helps as well.

[cmb42]

I have a very similar problem, except different env:
WP 4.1.9
PHP Version 5.6.28
Detailed explanation: ​https://wordpress.org/support/topic/upload-http-error-file-uploads-wp-breaks/

Summary:
JPG Files larger than error threshold of about 537 kb (+/- about 10 kb, actual threshold unknown) will not display or create thumbnails or other sized files in media library. These “large files” get loaded correctly on server, but display only default grey thumbnail of sheet of paper with folded corner. Also displays “HTTP error” message at time of upload.

Large photos can be deleted correctly from media lib. Metadata can be edited.

Large photos can be used to build pages and will display in editor when selected from media lib.

Page Editing: When resizing in the page editor, photo immediately returns to previous size in editor, but will display as resized in preview. Same behavior when resized using direct number input of pixel size.

Had another wp installation on this server previously (ver 3.x) without these problems.

Any help would be appreciated and welcome.

Cliff B.

[cmb42]

SOLUTION FOUND for my similar issue:

Create file called .user.ini in root firectory of wp installation (if it doesn’t already exist.)
Add the following lines. The FIRST cured my issue, the second may solve others(optional):

memory_limit = 128M
max_execution_time = 300

You can adjust the number as needed.
Place the file in the root dir for the website (same dir as wp_config.php).

Since this seems so closely tied to plugins, and, at least WordFence adds the .user.ini file to the env., maybe this is a big clue to the underlying cause? I added define( 'WP_MEMORY_LIMIT', '256M' ); to wp-config.php, but it did nothing for this problem. Adding/changing .user.ini did fix it.

Maybe this will help others.

[mbeerli]

Create file called .user.ini in root firectory of wp installation (if it doesn’t already exist.)
memory_limit = 128M
max_execution_time = 300

This does not solve the issue. The issue is resolved by unticking the option in php option of hosting provider called "imagick". see screenshot here https://core.trac.wordpress.org/ticket/42843
and what you are referencing is in php.ini
Which I already have:
max_execution_time = 600; Maximum execution time of each script, in seconds
max_input_time = 600; Maximum amount of time each script may spend parsing request
memory_limit = 128M; Maximum amount of memory a script may consume (8MB) default
upload_max_filesize = 64M; The maximum size of an uploaded file.
post_max_size = 64M;
mysql.connect_timeout = 120;

[cmb42]

Replying to mbeerli:

Create file called .user.ini in root firectory of wp installation (if it doesn’t already exist.)
memory_limit = 128M
max_execution_time = 300

This does not solve the issue. The issue is resolved by unticking the option in php option of hosting provider called "imagick". see screenshot here https://core.trac.wordpress.org/ticket/42843
and what you are referencing is in php.ini
Which I already have:
max_execution_time = 600; Maximum execution time of each script, in seconds
max_input_time = 600; Maximum amount of time each script may spend parsing request
memory_limit = 128M; Maximum amount of memory a script may consume (8MB) default
upload_max_filesize = 64M; The maximum size of an uploaded file.
post_max_size = 64M;
mysql.connect_timeout = 120;

I respectfully suggest that your reply is not "THE" solution, but, like mine, is one of many. Depending on environments, some work and others don't. The root workaround solution seems to be allocating enough memory. However, different environments are requiring different implementations. Some people are able to do this in wp-config.php. This didn't work for me, but doing it in .user.ini did work. Your solution was to implement it in php.ini. Depending on whether the user owns the server, or the service is provided by a service, the user may or may not be able to access or change the php.ini file. Still others have different workarounds and solutions. Replacing Imagick with GD is also a workaround for others. (Personally, I don't believe a replacement like this should be necessary. If the problem is really Imagick, then it should be replaced as a default of the install process, or something more consistent and permanent should be done.)

Having said all that, and as a systems programmer, my opinion is that there's still a root underlying cause, perhaps still unidentified, that needs to be universally fixed so that this problem doesn't continue to frustrate WP users everywhere. Also, there are enough workarounds now that a whitepaper could probably be created to provide an entire process for finding a workaround that works in a particular user's environment.

Just my opinions. ;-)

[antpb]

Going to close this ticket as it has not seen any recent activity and seems related to memory allocation, which is configurable. It's possible 7.1 required more resources than other versions which likely surfaced this issue initially. If this is still a problem please feel free to reopen this ticket!