• If you are still using CentOS 7.9, it's time to convert to Alma 8 with the free centos2alma tool by Plesk or Plesk Migrator. Please let us know your experiences or concerns in this thread:
    CentOS2Alma discussion

Resolved Failed to upload files midsize forward to any cms or script

Iván Jaimes

New Pleskian
When I try to upload files as medium size 80M, 20M, etc. The server uploads the files correctly. when I try to upload files 200M or above the server tries to upload the file but is frozen at a rate at any time, for example I'll do the test with a file 1 having a size of 219.9M and the server no matter what happens it hangs by 2% and there does not pass as shown in the following screenshot:

Download-File


This does not happen when I try a second file with which 82,1M if I have to upload and success is not left hanging the progress bar. Show captures so they can see.

Captura%202.jpg


Note that I Centos 7.2, Plesk upgraded to the latest version available, I tested changed versions of PHP for the domain, handlers PHP (FastCGI, CGI, PHP FPM serverd by nginx, PHP FPM serverd by Apache), the Apache handlers (Event and Prefork) and have the following custom configurations PHP as I show in screenshots below. I've also tried doing clean installations of Plesk but none of this has worked. As a last resort facilities made alternative Cpanel (cpanel, ISPConfig, Kloxo-MR) and everything works properly only by modifying post_max_size, upload_max_filesize, max_input_time, max_execution_time like hize with plesk.

Captura%203.jpg

Captura%204.jpg

Captura%205.jpg


Please appreciate a prompt solution to this problem, which is giving me headaches.

Good day !!
 
Have you tried to increase parameters like

upload_max_filesize = 2000M
post_max_size = 2000M

in the Plesk system php.ini?
For Debian: /opt/psa/admin/conf/php.ini
For CentOS: /usr/local/psa/admin/conf/php.ini

Do not forget to restart sw-engine after that:

# service sw-engine restart
 
Have you tried to increase parameters like

upload_max_filesize = 2000M
post_max_size = 2000M

in the Plesk system php.ini?
For Debian: /opt/psa/admin/conf/php.ini
For CentOS: /usr/local/psa/admin/conf/php.ini

Do not forget to restart sw-engine after that:

# service sw-engine restart
I already have modified the parameters for the domain, I do not think you read what I wrote because I also mentioned the operating system. However, I modify the parameters for the system Plesk as you mentioned and still not working.
 
I already have modified the parameters for the domain, I do not think you read what I wrote because I also mentioned the operating system. However, I modify the parameters for the system Plesk as you mentioned and still not working.
These parameters should be changed not for domains, but for Plesk interface php.ini. There are two php in Plesk - one for customer's sites and one for Plesk itself operation. Your problem related to Plesk operation, but not to particular domain. Therefore I suggested changes in Plesk php.in and restarting Plesk service after that. Have you tried my recommendation?
 
As I mentioned before, I also tried changing the parameters for the Plesk system as you mentioned and still not working.
 
@Iván Jaimes

In essence, there are some issues in your approach, that have to be analyzed, in order to come to the factual root cause of the problem.

I will address some of them, in the hope that one of them might help. Note that I will use a specific order of discussion, test in that order (otherwise, problems will occur, biasing the test).

a) try to increase the memory_limit value to a respectable 512M (note that your server should have enough memory, so memory_limits on other domains will not be a problem).

Note that it is recommended to log in with SSH and check the memory usage, with the command free -hm

I am pretty sure that you will see your memory getting used to a (very) high degree, indepent of the memory_limit settings.

If true, this indicates that your server is hicking up on other processes, involved with the upload to a WordPress Media library.

b) you are aiming to upload a huge file to WordPress Media library and that is problematic in three dimensions:

1 - one can use the "Drag&Drop" option or the classical "Navigator" and both are a "sort of" HTTP based upload, with many (WP related) issues and problems: FTP is better,
2 - one uploads to WP and the media library within WP, with associated hooks, actions, filters and so on: a lot of "action" surrounding the actual uploads and this can be problematic,
3 - one has to configure WordPress properly: editing the per-domain php.ini and server-wide php.ini is not always the appropriate action or the only action that has to be taken.

I am pretty sure that points 1 and 2 are not the root cause of the problem, even though point 2 is a partial (!) explanation for the progress bar getting stuck.

Nevertheless, point 3 is the very likely culprit when we have to think about the actual root cause of the problem.

It is recommended, irregardless whether point a) did resolve your issue, to edit wp-config.php to contain the following:

/* Custom memory settings. */
define( 'WP_MEMORY_LIMIT', '256M' ); // note: keep this value lower than the value in the next line
define( 'WP_MAX_MEMORY_LIMIT', '512M' ); // note: adjust accordingly to the value chosen for the memory_limit settings

and put those two lines just after the line starting with "$table_prefix=".

I am pretty sure that this solution will work, since it actually implies that WordPress will use memory to the maximum specified in the memory_limit setting.

And this memory is required in order to get the huge upload into the WordPress environment.

c) in the case that point b) did not work, retry again with

- memory_limit: 768M (via Plesk Panel)
- WP_MEMORY_LIMIT: 512M
- WP_MAX_MEMORY_LIMIT: 768M

but be aware of the fact that WordPress can show unpredictable behaviour if these values are too high, when compared relative to the available resources on your server.

In essence, WordPress is memory hungry and rather sloppy when it comes to memory, so be careful.

d) in the case that point c) did not work, try to have a look at the following:

- the Nginx error log for the specific domain, this in order to verify that the request passes the proxy (and that issues are hence related to Apache or WordPress settings)
- the mysql log, this in order to verify that you did not have any issues with the database requests (associated with an upload to a WP Media Library)


As a general and finalizing remark, I must admit that I do not understand why you would want to upload a huge file to WP with the "Drag&Drop" or the "classic" options.

In every sense, it is more easy and faster to use the option of FTP upload.

Anyway, hope the above helps and explains a little bit.

Regards....

PS Given all previous attempts, it would be recommended that you have a look at still running processes. Your issue can also arise from previous failed attempts to upload a file, with the upload still being stuck in the queue and/or consuming a lot of resources, effectively disabling the possibility to retry a new upload. That is one of the problems with WP HTTP uploads.
 
Greetings, having had this problem migrated to CPanel and despite the excellent support about a month ago decided to return to plesk for economy and support Nginx native who owns. Then I again had this serious problem, but further researched on the web and found this forum third party is the same problem and apparently now everything works perfect:

https://groups.google.com/forum/#!topic/seafile/__dwmZQyKA8

To resolve the issue edit /etc/nginx/nginx.conf and set client_max_body_size by adding the highlighted line:
Code:
server_tokens off;
    client_max_body_size 10240m;
    include /etc/nginx/conf.d/*.conf;
}

Also you must change the value of client_max_body_size line parameter file 16 /etc/nginx/plesk.conf.d/vhosts/mydomain.com.conf
Code:
client_max_body_size 10240m;

In my case I put of 10240M corresponding to 10G :D

I add this message as a form of feedback forum as within the community no one managed to find the problem and it may be that someone later or even now is dealing with this problem and are wracking their brains thinking of how to fix it.

Thank you all for your cooperation, although it did not work none of the solutions I thank you for your time and effort in trying to help.

Ivan Jaimes ;)
 
Back
Top