i made sure my php.ini settings were correct (uploads on, uploads and post max sizes set), and permissions were correct (tried everything including 777) ... but the upload link is still grayed out.
any ideas? i can create files and folders just fine, so it shouldn't be a write issue. the upload size is set to 20 megs, the post size to 8 megs.
this is probably a bad idea, but i went into the include file fun_list.php, found the UPLOAD section, and got rid of the if statement. whatever the if is checking for, i made it not check for it ...
if anyone can tell me what repercussions this would have, that would be great.
I'm not sure which line you have removed from fun_list.php but i think this is an bad idea.
Check this points to enable file uploading:
- in your conf.php there must be an configuration entry:
$GLOBALS["file_uploads"] = true;
- enable user authentication to control who may upload files (also in your conf.php):
$GLOBALS["require_login"] = true;
- ensure the user is allowed to upload files to the (current) directory
- check (as you did) write permissions on the directory for the webserver.
ah ok, that's the solution i think. there is no $GLOBALS["file_uploads"]
entry in conf.php. on the other hand, the line i removed from the
fun_list.php file was the if statement that checks for this variable ...
did the same sort of thing, but obviously not as good a solution since
it's hard-coding essentially.
the following news: I had the same 'upload does not work'-grayed out-issue for hours now and seems there is a little php thing the developers might wanna have an eye on. Here
in the very last comment is the interesting fact! The function get_cfg_var only reads config-values already written to the php.ini - but as we set $GLOBALS["file_upload"] = true; in the conf.php-file it can not be read by the get_cfg_var function then of course.
To correctly read the value, line 288 in fun_list.php hast to be changed to
ini_get can read the value of $GLOBALS["file_upload"] correctly (ini_get reads values set during runtime) and QuiXplorer will behave as we want it to.
Little difference, big effect - it works now! This cost me hours and hours and hopefully saves time for others; bug has to be tested, confirmed and fixed by the developers of course.
Log in to post a comment.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.