This is not a quick failure, I have spent a totally of 5 completely full days trying to figure this out. Initially I was limited by file size and then file type; in which I removed the Wordpress restrictions and am now "capable" of uploading my 177MB .glb file to Wordpress.
However when doing so, I receive the following error:
retriever.glb
Unexpected response from the server. The file may have been uploaded successfully. Check in the Media Library or reload the page.
I was on the phone with GoDaddy Specialists for 2.5 hours yesterday ensuring that this was not a Server issue or restriction on their side.. they confirmed that it was not. We pretty much ended the conversation that it is something I must figure out with me, myself, and I.
I went ahead and uploaded my .glb to the server through panel, everything worked fine. In fact I have a location for it here: https://www.tattiniboots.com/wp-content/uploads/2020/07/retriever.glb
However, this does not make the file discoverable to the 3D viewer plugins I have installed on the site through the media location.
I truly don't know where to go from here
I changed the name of the file to .png and attempted an upload and received the following error:
Post-processing of the image failed likely because the server is busy or does not have enough resources. Uploading a smaller image may help. Suggested maximum size is 2500 pixels.
I just tried to update a normal .mov file that is 150MB and received the following error; really making me think this is something to do with file size:
Unexpected response from the server. The file may have been uploaded successfully. Check in the Media Library or reload the page.
Yes, normal images are uploading just fine (2MB-ish)
I just attempted to deactivate all plugins with consideration that maybe "Smush" or another was imposing issues: I then received the issue that the file type is not supported (even with the allow all file types code in my wp-config)
Is this just the case that glb is not allowed at all?
This must be a server thing. probably a run time error
Whoever supported you just doesn't know it. GoGoDaddy. ;)
Nevertheless... you can Use a plugin that's called
media sync. Check it out and best of luck
Related
I am uploading more than 12 images files for a single requests but the online server refuses to upload those images. In my local machine it works fine, i can upload more than 20 images at once. I have configured the PHP settings for max_file_uploads = 60, upload_max_filesize=100M, post_max_size = 125M in php.ini, both on my local machine server and online server. While sending the page loads unfinishing, and at the end after a long time it responds with a Network Protocol Error, which says that:
"An error occurred during a connection to www.mydomain.com. The page you are trying to view cannot be shown because an error in the network protocol was detected."
See the screen shots of other different error responses i've also got after many trials, and it still takes a long time of loading to get those responses after sending.
The images that i am uploading are being saved on server but not all. When i upload 20 images for a single request, it can get only 8 or 10 and sometimes the last image is cut short(interrupted) before it is fully uploaded, see its picture below.
I need to get all the images i am uploading like in my local machine, and with a quick response. What else i can do for configuration in PHP or elsewhere? What's wrong on shared hosting server? Please, if you have any answer to this, you can tell me what i can do, to get all uploaded images files with a quick response.
It's clearly because of a timeout error. It's not acceptable to send multiple files with one request. Even if you get it to work right now, it will fail from time to time depending on the user connection speed and file size. Also you mentioned a quick response. So you definitely need to use ajax upload to upload files simultaneously. There are multiple upload libraries such as dropzone.
When uploading a 50MB file in WordPress through any of the methods it provides, I experienced an error message saying
HTTP error.
with no further hint what has happened. I tried uploading other types of similar size and different file types of smaller size. Only files above a certain size failed no matter what type and all types of smaller size succeeded.
I raised maximum file and post size in php.ini (upload_max_filesize, post_max_size) and the network settings of WP up to four times the size of the file but to no avail.
I found out that the error was 404 even though the file which 404ed was physically there. Upon further inspection of the answer I found out that IIS answered with a more detailed error code of "404.13" which further hints to the request filtering module and the solution (below)
This problem is related to the file's size but has nothing to do with WordPress or PHP or the filesystem but with settings in IIS.
In IIS there is a feature called "Request Filtering" where you can set filtering rules for requests based on various things like HTTP verbs, file extensions, and so on. Unfortunately the UI of IIS often is not very clear and hides important links in the side bar on the right side which puts things out of attention on wide monitors.
Solution
Open "Request Filtering"
Click on "Edit Feature Settings..." in the sidebar
change the value of "Maximum allowed content length (Bytes)"
I'm offering users the ability to upload files using an online form, but I keep on getting 500 internal server errors whenever the file upload is processed. This is what I know:
The problem isn't related to php.ini. I've checked the max file upload size, and it's set at 2 megabytes. I get the same 500 internal server error uploading 3kb large files, as well as 100kb large files.
The problem isn't related to file permissions. The php file I'm using to upload, upload.php, has permissions set to 664, and the upload folder, called upload_pic, has folder permissions of 755.
This is not an issue with the code. The exact same code was working on my previous server. I recently bought a new server and am migrating the sites over, and this is where I'm getting my problem.
I've looked online for the past two days, but I just can't find what's causing the problem. I've seen many issues similar to mine, but most of these were resolved by changing file/directory permissions, or making edits to php.ini.
Does anyone have any other proposed solutions?
Thanks!
I have an administration page on a website, from which the admin AND THE ADMIN ONLY can manage users and upload files from local hard drive for these users to download. The admin uses this page to upload files for his customers or to store files he needs when he has no memory device available. The files size may vary from a few Kb to a lot of hundreds megabytes.
The ideal solution:
An HTML form through which the admin can choose a file and upload it, to download it back later. This can be done in PHP.
The problems:
I cannot set the "max_file_size" variable in php.ini because the hosting doesn't let me
I tried FTP upload (PHP function ftp_put()) but it requires me to upload the file with a POST anyway
Even though it's completely wrong, I used a input="text" instead of input="file" to write the whole file path and upload it, but I get the following error:
Warning: ftp_put(insert_local_file_path_here)[function.ftp-put]:
failed to open stream: No such file or directory in path_to_php_script.php on line 70
The insane thing is... on Monday this was working, and now it's not. No changes were done and the file is the same.
My only conclusion:
With my little knowledge, all I could think of is a Java applet which does the required tasks that opens on the administration page. But if someone disables javascript/has no Java installed, the thing will not work, so it's not 100% bulletproof.
Have you got any ideas how to overcome such an issue?
If you need to upload big files you must use ftp protocol to make it. You can't upload big files if you don't have acces to php.ini. Sad but true
I have a site that is receiving 30-40k photo uploads a day and I've been seeing an issue pop up with more frequency now. This issue is this:
Our upload script receives (via $_FILES['name']['tmp_name']) a file (photo) that was NOT uploaded by the user & the majority of the time the file received is a "partial" upload.
Of course at first I thought it was my PHP code making a simple mistake and I've spent days looking over it to make sure, but after placing checks in the code I've found that the file received via a HTTP POST upload to PHP is actually the wrong file. So the issue is happening before it reaches my code. The tmp file (phpxxxx) received by the script is sometimes incorrect, as if it was somehow being overwritten by another process and its usually overwritten by a file that was partially uploaded.
Has anyone every seen an issue like this? Any help is greatly appreciated. I'm turning to this as a last resort after days of searching/asking other PHP devs
So to recap:
User uploads a photo
PHP script receives a file that was not uploaded by the user (pre code, via $_FILES in /var/tmp)
Usually the incorrect file received is a partial upload or a broken upload
It seems to happen randomly and not all the time
First off, check you PHP version.
Second, check your file upload limits and POST_MAX_SIZE in php.ini
It might just be that someone tries to upload a file that's too large :-)
Can you try different names for the temp file to avoid its being overwritten? Can you identify the origin of the new, incorrect and incomplete file?
Is this a development environment? Is it possible that more than one user is uploading files at the same time?
Try your program with very small images to check if SchizoDuckie is correct about filesize problems.
Try with different navigators to eliminate the admittedly remote possibility that it is a local problem.
Check permissions on the directory where the temp file is stored.
PHP's built-in file handling does not support partial uploads.
Turn off KeepAlives and/or send a 'Connection: close' header after each upload.
Configure your webserver to send the header 'Allow-Ranges: none'.