[wp-trac] [WordPress Trac] #41973: HTTP Error when uploading images on PHP 7.1.7

[WordPress Trac]

#41973: HTTP Error when uploading images on PHP 7.1.7
-------------------------------+------------------------------
 Reporter:  robhindle          |       Owner:  joemcgill
     Type:  defect (bug)       |      Status:  reopened
 Priority:  high               |   Milestone:  Awaiting Review
Component:  Media              |     Version:
 Severity:  normal             |  Resolution:
 Keywords:  reporter-feedback  |     Focuses:
-------------------------------+------------------------------

Comment (by cmb42):

 Replying to [comment:31 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.  ;-)

--
Ticket URL: <https://core.trac.wordpress.org/ticket/41973#comment:32>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform