I'm working on a upload script and using move_uploaded_file() function. The problem is, that it only works for .txt, .jpg, .psd and some other file types I've tryed, but not for .mp3, .mov, .avi and maybe others.
There is nothing to the script, it's just the function. An interesting thing is, that it doesn't show any error msgs, it just doesn't upload the file.
Does anybody have some experience with this problem?
Thanks, Mike.
I don't think this is actually down to file type, more to file size.
Create a PHP script that runs a <? phpinfo(); ?> and look out for the upload_max_filesize setting. It could be that it is something like 8 MB, causing all larger file uploads to fail.
If that is the case, you can try changing the setting using ini_set("upload_max_filesize", "3200000000"); for example. In most cases, if on a shared hosting package, that will probably not work, though. You may have to contact your hosting provider then.
You should also make your script throw reliable error messages. The attempt to upload a file that is too big usually shows up as an error when uploading the file. Check the Error Messages Explained chapter in the manual for the respective error codes and their meanings.
Related
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
I wrote JS to upload really large videos in chunks and PHP script to assemble the pieces on the server. The file process works except that I can't play the file unless I "Restart All Services" from the PHP taskbar. After that the file plays fine. If I try to rename the file in Windows Explorer I get the follow error:
The action cannot be completed because the file is open in httpd.exe
I suspect it may have something to do with never calling move_uploaded_File(), but that calling that procedure won't work on the assembled file.
Found it myself. Nothing to do with move_uploaded_File not being called. There was a syntax error that stopped the script before the file was closed. Since the server had been set to not display errors it wasn't apparent that an error occurred before the file was closed.
The temporary files are closed(explicitly) after being appended to large file being assembled. It seems that this accomplishes part what move_uploaded_file does, that is, disposing of the temporary file after using it. The script ending probably does that too.
I've been trying to make a zip archive for some mp3s. The problem I have is that some of the mp3s just break the zipping process, in bizarre ways. If I don't include one of these files everything is fine; if I put one of them in then it goes pear-shaped.
Ultimately, I want to put the zip file on my server for people to download, and I would like to make it on the fly using php. If I don't include any of my problematic files in the archive, it works fine. If I do, then I get a '500 internal server error', but nothing in the server error log. By creating my own error log for every step of the process, it's at the point I try and do zip->close that it seems to be failing.
I tried taking a step back, and making the zip archive locally using 7zip. If I include a problem file I can do this, but if I upload this zip archive to the server and then download it, the download is corrupt. If I don't include a problem file, it's fine. The same happens with winzip.
In total I have about 100 mp3s, of which about 6 cause this behaviour. They all have the same permissions, they all exist, they're all in the same directory, they're all roughly th same size. I even tried making the mp3 again from the source .wav file - the same thing happened with the new version.
I'm completely stumped. I've searched all over, and can't find any clues whatsoever. Help!!
Several reasons are possible (and they can happen together): (a) buggy code in PHP zip creation - either in your code or in code that does actual compression , (b) text mode used in uploading or downloading the files.
As you see yourself, using 7zip solves the problem with PHP zip, so there must be some error in compression code. Now if you put created ZIPs and they are downloaded as broken, this can mean that the file is provided using text mode.
One of the non-obvious reasons is enabled mbcs functions overloads in PHP. With overloads enabled, strlen and similar functions, when binary data is passed to them, start to produce unexpected results (this is because they treat input as UTF8 strings).
I try to upload a file through PHP's ftp_put function, like so:
ftp_put($this->conn_id, $rempath, $locpath, $mode);
However I get the error "Cannot STOR." Nothing more. The FTP-connection is OK since I can download files using the same settings and ftp_get(). The script should be OK as well since it works fine on my local setup but not on my public server.
What can I try to make it work? I Googled but found nothing of worth.
You should first check to make sure that you are able to upload using a regular FTP client. I see you say "there's no problem withmy FTP-client" but in the initial request you said you are able to download files successfully and failed to mention a successful upload. I believe you will find that uploading with a client will fail too because that message is the output of FTP and not PHP. Whether or not it is a permissions issue remains to be seen, but it is unlikely a PHP issue. Do a little more research on FTP error 550.
Sounds like a permissions error. Are you sure you have permissions to upload the file to the location you are trying to put it at? If you try to do the upload manually via FileZilla or something does it work?
You should check to be sure you have write permissions on the directory into which you are trying to put the file(s).
Cannot STOR is a permission issue. Doublecheck the permissions for the FTP user.
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'.