for me the flash uploader is simply blank, but I experienced something like this also in wordpress. But they provide a fallback html upload form, which works. Is there something like this possible also for c5? Not everyone is running flash anyway.
For my associate the problem is something else, he gets further. It even seems to upload the file, but afterwards the new file does not show up.
We do not have mod_sec installed, basically it's a stock debian linux apache install. The only thing worth mentioning is, that we running on a non-standard port. maybe this could be a clue.
It will be accessible if flash fails AND via a link in case people can use the flash uploader, but the server rejects it.
we added it because http uploads tend to die on huge files and the multi-upload is keen...
...what might make more sense..
turn add file into a submit button next to a traditional form uploader /actually on/ the file manager page. Put the link to launch the flash multi-file as a (advanced) text link around that single file. I find it frustrating that it takes as many steps as it does to add a single, small, image today... this would make that simpler for everyone most of the time, and still leave the flash-goodness for big stuff..
this issue still bugs me. unfortunately the flash uploader source is unavailable to me, so i had to resort to lower level tools.
since the uploader uses an own http client engine no traffic can be seen in firebug. so i fired up wireshark for some sniffing. turns out, that our c5 runs on https only. so the sniffing was not really informative. that gave me the clue: we use self-signed certs for https, could this make the uploader http engine bail? other tools usually do.
anyway, i set up our server to also serve on http, i sniffed that. maybe the request reveals something:
POST /c4/index.php/tools/required/al_upload_process.php?cID= HTTP/1.1\r\n
this had the file to be uploaded correctly attached as a
MIME Multipart Media Encapsulation, Type: multipart/form-data
the response is misleading:
HTTP/1.1 200 OK\r\n
the interesing part is the content of the response, quoted entirely:
i rechecked the fs permissions for c5, and the owner and write rights should be correct, but i must admit i only checked c5/files.
i don't know, whether this helps, it might be a dead end, but i hope someone can make something of this. why is the access denied?
grepping the source reveals that seemingly every file in c5 has this line:
contains this line. Turns out, that this checks, whether the user can access /dashboard/mediabrowser. Somehow it seems to me, that the cookie representing myself in firefox is not carried over to the flash engine and thus the POST will not contain my valid user id, resulting in the 'Access Denied' message, which is unfortunately hidden from the user, and only visible via advanced tools like wireshark. I believe the error handling could be improved in the uploader flash applet as well.
So the question is, why the flash request does not carry the cookie? I use the noscript and flashblock extensions. Trying this in a profile without those didn't help. I guess, that it might be, that firefox introduces some good security and does not leak cookies to flash apps. but this is just a wild ass guess.
ps: btw, i tried to look for the public version control repository (cvs,svn,git?) for c5 and couldn't find one via google.
i only wish you could create directories for the files ...
maybe my wish comes true?! :)
thx for c5!!!
I added a "session_destroy()" just after the first line.
I think this issue has something to do with server configurations where "session.auto_start" is on.
This is just a hack, but I think it points to the issue.
Warning: session_destroy() [function.session-destroy]: Trying to destroy uninitialized session in /var/www/c5/concrete/startup/session.php on line 3 Warning: session_start() [function.session-start]: Cannot send session cookie - headers already sent by (output started at /var/www/c5/concrete/startup/session.php:3) in /var/www/c5/concrete/startup/session.php on line 17 Warning: session_start() [function.session-start]: Cannot send session cache limiter - headers already sent (output started at /var/www/c5/concrete/startup/session.php:3) in /var/www/c5/concrete/startup/session.php on line 17 Warning: Cannot modify header information - headers already sent by (output started at /var/www/c5/concrete/startup/session.php:3) in /var/www/c5/concrete/libraries/controller.php on line 210
PHP Warning: ini_set() [<a href='function.ini-set'>function.ini-set</a>]: A session is active. You cannot change the session module's ini settings at this time. in.....
A session had already been started - ignoring session_start()
Still no file after uploading though.