I try to use multi file upload, but it's not working for me.
I choose file in file browser dialog, file upload progress bar appeared, but nothing happens then. albums folder has rwx rights for all. Http upload working fine.

A few more infos please. What browser? Any errors in the error log? Check that you have the right flash plugin (at least v9) and javascript enabled. It may not work with older browsers. Not much we can do about that in general as this is a adaption of a third party plugin.

I use IE7, Opera 9.64, Firefox 3.0.10 All with latest Flash 10 from adobe.com
In logs I only see:
[error] [client xxx.xxx.xxx.xxx] PHP Fatal error: Call to undefined function json_encode() in /var/www/html/site/zp-core/admin-uploadify/check.php on line 13, referer: http://xxx.xxx.xxx.xxx/site/zp-core/admin-upload.php?uploadtype=multifile

I've look at the demo at http://www.uploadify.com/demo/
and it's look like I add files to quene but it's doesn't start uploading auomatically
and there is no button to start it.

Ok, that is at least a hint. We will take a look.

Our upload does not start automatically, you have to click on "upload" after you selected files. Just tried successfully Safari 3.2 and FF 3.0.10 with the nightly.

Anyway, I think I know why you get the error. The functionjson_encode() is php5.2+ only, so I guess you have php4 on your server. Although we specifically support php 4.1 we actually develop on php5 so sometimes issues with php4 do escape us as with this one. We will try to solve that.

Sorry, Upload button is appearing, but clicking on it have no action.

My server OS is Centos 5.2 with packages installed:
php.i386 5.1.6-23.2.el5_3 installed php-cli.i386 5.1.6-23.2.el5_3 installed php-common.i386 5.1.6-23.2.el5_3 installed php-gd.i386 5.1.6-23.2.el5_3 installed php-mbstring.i386 5.1.6-23.2.el5_3 installed php-mysql.i386 5.1.6-23.2.el5_3 installed php-odbc.i386 5.1.6-23.2.el5_3 installed php-pdo.i386 5.1.6-23.2.el5_3 installed

As I said your error results from json_encode() being a php 5.2+ function, you have 5.1.6. We will try to find a workaround. Meanwhile you can only use the brower upload or ftp. Sorry.

Thanks for help, I'll be waiting for workaround or try to upgrade php version on server

Upgraded to 5.2.9, everything work perfectly!

Is 5.2.1 recent enough? I have the same problem with multi file upload. I chose files, click upload, I see the progress bars go to 100% for all files, and then the page refreshes and there are no images. I checked the appropriate album folders and nothing is there.

I set DEBUG_ERROR to true, as well as DEBUG_IMAGE and can't find any new files being created (I remember doing this once before when getting support here, but it was for a different site). Where is the error log supposed to show up?

FWIW: I am on IIS5 with PHP 5.2.1, and single HTTP file upload works.

5.2.1 is the release I am using. Perhaps it is IIS that is at issue. The DEBUG stuff won't help here as it seems that the upload is not occurring.

OK, so I started trying to debug this, and it is either a problem with PHP settings or IIS, but I also think there might be more than one issue.

Uploadify dev says:
http://www.uploadify.com/forum/viewtopic.php?f=4&t=643&p=1580&hilit=iis#p1580

I updated both the front and backend to use "uploadedFiles" for the array name.

$_FILES is not empty
$_FILES['uploadedFiles'] is not empty, and the data seems to be correct.

So here is the really funny (or strange) part, and it confirms your statement about the upload not occuring: when I upload through the normal single-file-upload, I see a temp file in C:\php5\uploadtemp while the upload is taking place. This is not the case when using the multi file uploader.

I did notice that $tempFile has all blackslashes removed so it is no longer a valid path, but the problem seems to even before this. And $_FILES['uploadedFiles']['tmp_name'] has a full valid path name. This could be a red herring...

Why would this happen?

I will try to get support from Uploadify too.

So the base install of uploadify works on the same site. Comparing/contrasting the code now....

So the problem is with lines 6-17 in /zp-core/admin-uploadify/uploader.php, which is the auth code. I removed this temporarily and everything started working.

Setting fileDataName to "uploadedFiles" is a non-starter, as not changing this in the default install of uploadify still worked.

I checked the value of $_GET['auth'] and from what I know of how the auth system works, it seems valid (it is not blank, for sure).

Thoughts?

You could log the comparisons of the loop. Maybe that would shed some light. Also, if memory serves me, IE preserves the logon state (session info) so that loop is not used. Have you tried it?

It would be nice to know if the loop gets a match and the failure is in the isMyAlbum() check or if the loop does not find the admin. The latter would indicate some kind of corruption of the auth value passed.

I'm actually not using IE, this is happening in Chrome, Opera and FF.

How would I go about checking the status of isMyAlbum()? I'm actually using email to debug this, so I am just sending the value of what ever for the body of the email (I don't know how to save to a file in PHP )

There is a function available: debugLog($msg); that you can insert into the code. Call this function passing whatever you want to record. It will be placed in the file debug_log.txt.

Try the following:
`
if (!zp_loggedin()) {
if (isset($_GET['auth'])) {
$auth = $_GET['auth'];
$admins = getAdministrators();

debugLog("target:$auth");

    foreach ($admins as $admin) {

debugLog("try:".md5(serialize($admin)));

        if (md5(serialize($admin)) == $auth) {
            $_zp_loggedin = checkAuthorization($admin['pass']);

debugLog('success');

            break;
        }
    }
}

}
`
and see what you get.

here is the output:

target:e166e2e1c07fcb59a55eac2c5a4c23af
try:e166e2e1c07fcb59a55eac2c5a4c23af
success

so if (md5(serialize($admin)) == $auth) is the problem?

so if (md5(serialize($admin)) == $auth) is the problem?

oops, the values are identical. guess that isn't it.

very strange, it should work, no?

Something else is the problem, then. Next thing to check is the parameters passed.

add: debugLogArray('$_FILES', $_FILES);debugLogArray('$_GET', $_GET);debugLog(sprintf('$_zp_loggedin%X', $_zp_loggedin));
just before the line if (!empty($_FILES)) {

and see what that reports.

$_FILES => (
uploadedFiles => ( name => celtic.jpg, type => application/octet-stream,
tmp_name => C:\PHP5\uploadtemp\php5FDF.tmp, error => 0, size => 109818 ),
)
$_GET => ( folder => /test, auth => e166e2e1c07fcb59a55eac2c5a4c23af )
$_zp_loggedin1355C

Again, the temp file never appears in the temp folder at the above referenced path. I can definitely see the file showing up when lines 6-17 are removed.