forum.coppermine-gallery.net
Support => cpg1.4.x Support => Older/other versions => cpg1.4 upload => Topic started by: artoonie on February 29, 2008, 05:49:36 am
-
I've searched a lot and could not find any solutions to this:
I cannot upload from a URL, and under the normal error message column, there is no text.
I have allow_url_fopen enabled, and I'm using php5.
Local file uploads do work.
The only thing I'm not sure about is upload_tmp_dir and open_basedir, which are mentioned in the documentation, but I don't understand if they need a value. They're currently set to no value.
-
Sorry, I knew I forgot something.
Gallery: http://74.86.153.136/%7epriceypi/pics/
Username: test
Password: test
-
1) Upgrade. You're using cpg1.4.10, while the most recent stable release currently is cpg1.4.16
2) Use a URL that makes sense: don't use special chars in folder names. %7epriceypi doesn't fall into the category "valid folder name"
3) Make sure you have set the coppermine URL properly in the corresponding config option - the links in your navigation point to http://74.86.153.136/pics/ instead of http://74.86.153.136/%7epriceypi/pics/
-
1) I've done all the manual updates up to cpg1.4.14, but I have made a lot of changes around the gallery that would be near impossible to redo/find and place in the new versions. Is it absolutely necessary that I do this?
2&3) I was upgrading my servers at the time, that was the temporary url. I have the same problem at http://www.priceypixel.com/pics
-
upload_tmp_dir is not relevant to URI uploads.
Updating is almost certainly less work than restoring your entire site after getting hacked.
If it's a dedicated server, do you have a firewall in place that blocks outbound connections?
-
It's not a dedicated, but I'll certainly ask my host and get back to you.
-
My host looked through everything and could not find what was wrong.
I also did a fresh install to make sure my code was okay, and that didn't work either.
Should i post the logs, would that help at all?
-
1) I've done all the manual updates up to cpg1.4.14, but I have made a lot of changes around the gallery that would be near impossible to redo/find and place in the new versions. Is it absolutely necessary that I do this?
2&3) I was upgrading my servers at the time, that was the temporary url. I have the same problem at http://www.priceypixel.com/pics
No, you have not. That gallery is still running cpg1.4.10. Upgrade as I suggested - I'm not willing to look into issues that may be caused by you running an outdated version. Manually applying the hotfixes is not an option - it just takes care of the security-related issues, but it won't iron out bugs that existed in older versions. There is a load of changes that went into cpg1.4.16
-
I'll be sure to update to 1.4.16 as soon as I have time, but I'll have to go through each file individually and copy all my changes over, which will take time.
For now, here is the fresh install which does have the latest version of coppermine, but yields the same error:
http://priceypixel.com/temp_delete/index.php
Username: test
Password: pass
Thanks :)
-
If it helps, I can tell that the error occurs before the upload process even starts, or really soon after, because it seems to load the error message immediately.
-
You haven't done as suggested: when going to http://priceypixel.com/temp_delete/index.php and logging in, the number of upload fields isn't set as suggested in the upload troubleshooting section of the docs.
-
Sorry about that =/ I try to follow the rules as closely as possible. I know it gets annoying for you to have to repeat "RTFM" over and over.
Anyhow, fixed.
-
Sorry, I just realized:
The file uploads work, it's the URL/URI that doesn't. I'll keep it at the requested settings anyhow, until you request a change.
-
Make sure that your webserver fulfills the pre-requisites for allowing URI uploads - check phpinfo. I wouldn't mind though: URI upload is a silly feature anyway. You as admin should use FTP-upload plus batch-add anyway.
-
I need URL uploads mostly for another script i've written, which won't be nearly as user-friendly without it.
I've checked the upload prerequisites, but I may be missing something. Here's any possible errors:
- allow_fopen_url is called allow_url_fopen on my phpinfo, but i'm fairly sure that was just a typo on the post.
- upload_max_filesize < post_max_size < memory_limit:
upload_max_filesize = 40M
post_max_size = 8M
memory_limit = 40M
would that be a problem/should I increase post_max_size? I don't think that it uploads this small would require that much memory though. - PHP's LimitRequestBody - 512KB default limit. (mainly an issue on Redhat/Apache systems. Found in /etc/http/conf.d)
I cannot find this file (there's no http folder within etc, only "/priceypixel.com", and the file wasn't in there either - There's a setting I've only recently seen in phpinfo, "allow_url_include," which i believe (according to google) was introduced in php 5.2. I'm thinking that this should be set to on. I'm going to contact my host and let you know.
Thanks again.
-
[lli]There's a setting I've only recently seen in phpinfo, "allow_url_include," which i believe (according to google) was introduced in php 5.2. I'm thinking that this should be set to on. I'm going to contact my host and let you know.[/li][/list]
I finally got this set to On, but it did nothing.
-
URI upload is a silly feature in the first place. We consider removing it from future versions anyway. I wouldn't bother if I were you. You (as admin) should use FTP-upload plus batch-add anyway.
-
I've written a script that requires URL uploads to work, but I guess I'll try rewriting it for File uploads.
-
Okay, I decided to enter outputs throughout the program to see what's happening first.
Line ~1773:
// Undocumented error. Note an error. Return status code.
$URI_failure_array[] = array( 'failure_ordinal'=>$failure_ordinal, 'URI_name'=> $_POST['URI_array'][$counter], 'error_code'=>$header['wrapper_data'][0]);That's where the error is. Apparently, $header['wrapper_data'][0] is blank.
However, there is no real error, because when I remove the continue; statement on line ~1779, it works.
Thus, since this is an else rather than an else if, the problem lies here:
if(!(strstr($header['wrapper_data'][0], '200'))) {on line ~1736
The server does not return a status code 200, but there is no error.
Removing the continue is probably not the best way to go about solving this in case another uncoded error is encountered.
Seeing as $header['wrapper_data'][0] is blank, and we're looking for a substr of 200 in the front, I'm going to do the following. Let me know if other users should/shouldn't use this mini "mod":
Open upload.php
Find
if(!(strstr($header['wrapper_data'][0], '200'))) {
Replace with
if(!(strstr($header['wrapper_data'][0], '200')) && $header['wrapper_data'][0]!="") {
I hope this helps.