Make WordPress Core

Opened 7 years ago

Closed 2 years ago

#41973 closed defect (bug) (invalid)

HTTP Error when uploading images on PHP 7.1.7

Reported by: robhindle's profile robhindle Owned by: joemcgill's profile joemcgill
Milestone: Priority: high
Severity: normal Version:
Component: Media Keywords: reporter-feedback
Focuses: Cc:

Description

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

Attachments (2)

OE_compare_eggs.jpg (8.5 MB) - added by mbeerli 7 years ago.
OE_files_created.jpeg (60.4 KB) - added by mbeerli 7 years ago.

Change History (37)

#1 @SergeyBiryukov
7 years ago

  • Summary changed from php 7.1.9 to HTTP Error when uploading images on PHP 7.1.9

#2 @joemcgill
7 years ago

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?

#3 @robhindle
7 years ago

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

#4 @WraithKenny
7 years ago

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. (#41496 possibly related).

Last edited 7 years ago by WraithKenny (previous) (diff)

#5 @dd32
7 years ago

  • Keywords reporter-feedback added

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.

#6 @robhindle
7 years ago

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.

#7 @dd32
7 years ago

@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.

Last edited 7 years ago by dd32 (previous) (diff)

#8 @tr1988
7 years ago

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.

This ticket was mentioned in Slack in #core by sergey. View the logs.


7 years ago

#10 @joemcgill
7 years ago

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' );
}

#11 @joemcgill
7 years ago

  • Owner set to joemcgill
  • Priority changed from normal to high
  • Status changed from new to assigned

#12 @joemcgill
7 years ago

  • Milestone changed from Awaiting Review to 4.9

This ticket was mentioned in Slack in #core-media by joemcgill. View the logs.


7 years ago

This ticket was mentioned in Slack in #core-media by joemcgill. View the logs.


7 years ago

#15 @kirasong
7 years ago

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

This ticket was mentioned in Slack in #core-media by blobfolio. View the logs.


7 years ago

#17 @joemcgill
7 years ago

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.

#18 @SergeyBiryukov
7 years ago

  • Milestone changed from 4.9 to 4.9.1

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

This ticket was mentioned in Slack in #core-media by mike. View the logs.


7 years ago

#20 @johnbillion
7 years ago

  • Milestone changed from 4.9.1 to 5.0

This ticket was mentioned in Slack in #core-media by desrosj. View the logs.


7 years ago

#22 @joemcgill
7 years ago

  • Milestone 5.0 deleted
  • Resolution set to invalid
  • Status changed from assigned to closed

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.

#23 @dd32
7 years ago

#42843 was marked as a duplicate.

#24 @dd32
7 years ago

  • Milestone set to Awaiting Review
  • Resolution invalid deleted
  • Status changed from closed to reopened

Re-opening based on the further report in #42843

#25 follow-up: @mbeerli
7 years ago

  • Summary changed from HTTP Error when uploading images on PHP 7.1.9 to HTTP Error when uploading images on PHP 7.1.7
  • Version 4.8.2 deleted

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

Last edited 7 years ago by mbeerli (previous) (diff)

#26 in reply to: ↑ 25 @kirasong
7 years ago

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

#27 @mbeerli
7 years ago

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.

#28 @mbeerli
7 years ago

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

#29 @cmb42
7 years ago

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.

#30 follow-up: @cmb42
7 years ago

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.

Last edited 7 years ago by cmb42 (previous) (diff)

#31 in reply to: ↑ 30 ; follow-up: @mbeerli
7 years ago

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;

#32 in reply to: ↑ 31 @cmb42
7 years ago

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. ;-)

This ticket was mentioned in Slack in #core-media by lukecarbis. View the logs.


6 years ago

This ticket was mentioned in Slack in #core-media by antpb. View the logs.


2 years ago

#35 @antpb
2 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to invalid
  • Status changed from reopened to closed

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!

Note: See TracTickets for help on using tickets.