Symphony.

Would it be possible to fallback to a plain (JS) version if Flash (10) is unavailable?

Not really, I will do all the posting in flash, so it would require me to really make the application twice.

Also, in JS, the extension doesn’t really make sense..;)

Thanks for the heads up, guys!

Oh, before I forget, do you think resizing the image before uploading it would be valuable?

Updated:

I am now using plupload for the file uploads. Current version on github works, it just needs feedback build in.

The best part about plupload is that is supports html5, flash, silverlight, gears, and html4. It can also do client based resizing of images.

If any of you would be willing to test, it would be very much appreciated!

Edit: I have only tested this with the html5 and flash version in firefox.

You see I’d use JavaScript, Flash is a pain on my dev box with Ubuntu…

Edit: Ah, late post… missed the next page…

I’m not getting any response at all now after I click the create entry button, the uploader isn’t even responding now…

I’m not getting any response at all now after I click the create entry button

As I said, it has no feedback yet.

If you check the section you will see stuff happening though (if everything went as planned)

@designermonkey: Please let me know if you find any bugs/weird behaviour. I can not test on linux yet, so any information is very much appreciated.

Thanks for testing!

When I add the field to a section, the “save” button is broken, and nothing will be uploaded at all.

So what exactly should we test? :-)

That’s the same here. Yes, there’s no feedback, but there’s no action either. (I’m on my MacBook, will try the Ubuntu later).

So what exactly should we test? :-)

Well, the fact that its not working means I will have to do some more work on other platforms ;)

The difficulty is that the data sent by the server can’t be seen very easily (except when using a packet sniffer), and I can’t really ask you to install one.

I will add more feedback today, maybe then the reason it doesn’t work is more clear.

Looking forward to trying again! ;)

The difficulty is that the data sent by the server can’t be seen very easily (except when using a packet sniffer), and I can’t really ask you to install one.

Doesn’t the Firebug Network pane suffice for that?

Aha! Good call Nils!

Checking the net panel produces this.

require_once(/./../fields/field.upload_many.php) [function.require-once]: failed to open stream: No such file or directory

An error occurred in /Users/designermonkey/Projects/web/designermonkey.co.uk/extensions/upload_many/content/content.create.php around line 3

There’s a ‘.’ missing from the path There’s an extra ‘.’ in the path. Although fixing this doesn’t work either and throws the same error. I think therefore that there is something wrong with the way that the require_once works.

The path is relative, and this file is called relative to content.inject.php, does this file get called into anything else? Would that cause the relativity to be off?

At least we’re getting somewhere! ;)

Edit: Whoops changed a line.

Doesn’t the Firebug Network pane suffice for that?

Wow, thanks a lot for that!

I’ve always been running Fiddler as a packet sniffer, but this is way easier!

The path is relative, and this file is called relative to content.inject.php, does this file get called into anything else? Would that cause the relativity to be off?

I believe symphony changes the import path, and this might be causing the errors.

The easiest solution would be to hard code the location. Fix is on its way!

EDIT:

There’s an extra ‘.’ in the path.

Yes, that should turn the relative path into an absolute path (sortof). Symphony replaces the place php looks for includes, and by adding the dot php should also look in the current directory.

I’ve had more trouble with this though, just making it absolute will fix it, I guess.

just making it absolute will fix it, I guess.

Is this done on Github? I can test again if so…

EDIT: Answered my own question. I’ll have another blast when I get home…

Ok. Test ed again, and now I get this:

{"error":{"23":{"fieldName":"files","error":"A file with the name already exists in /workspace/uploads/photos. Please rename the file first, or choose another."}}}

There are, however, no files in the directory.

Yes, that’s a very weird bug.

For some reason, when using some modes (html4 for instance) the file is not properly saved. I am working on a fix though.

Oh, before I forget, in the javascript directory, there is a setting for the plugins to use (html5, flash etc). If you set that to html5 or flash, does that make it work?

Thanks for testing!

I’ll have a look later at that setting…

To make the extension more user friendly, I would like to improve the UI, especially the feedback to the user (upload failed, succeeded, etc).

For failed uploads, the bar turns red, and if the failure is due to another field, that field is marked as errornous like with a normal save. This seemed like the best solution to me. However, if a field uses non-standard error styles, this will not work properly.

Also, if an upload succeeds, what should I do? Right now, the bar stays red, and there is no feedback to the user. How do you think this should work?

I know development is slow, but any help is very much appreciated!

IMHO, the bar should only turn green when the whole ‘entry’ is saved, thus meaning the files are uploaded and the data is saved into the section. If the file fails to upload, the bar should turn red, and use the standard ‘failed entry’ error at the top of the page, or highlighting the field and explaining the error, as is done with other fields. If another field is the cause of the error, then leave it to that field to sort it’s feedback out.

Consistency is key, and established error feedback needs to be followed imho, that way users won’t get confused…

Also, I think the bars are way too tall, if you have 20 files, you’re going to have a massive scroll to find all the files, say if you want to delete one from the queue.

So far so good though ;o)

If another field is the cause of the error, then leave it to that field to sort it’s feedback out.

Also need to make sure that no files are uploaded until all of the other data in the entry is verified, so the file commit is the last action.