RE: [PHP] Upload Progress Meter
Essentially, they all require Flash or Java... Most use Flash... If you want one that is in Java, and is scriptable in JavaScript, I have one on my website: http://www.bbroerman.net/code.html -Brad -Original Message- From: Floyd Resler [mailto:fres...@adex-intl.com] Sent: Wednesday, March 23, 2011 10:29 AM To: sstap...@mnsi.net Cc: PHP Subject: Re: [PHP] Upload Progress Meter On Mar 23, 2011, at 10:10 AM, Steve Staples wrote: On Wed, 2011-03-23 at 09:59 -0400, Floyd Resler wrote: I am in need of an upload progress meter. I've seen plenty of tutorials = on-line requiring installing modules, hooks, patches, etc. However, my = Wordpress install accomplished this without me having to make any = modifications to my PHP install. So, how is it done? Thanks! Floyd you can google this... jquery upload progress meter or: http://www.nixboxdesigns.com/demos/jquery-uploadprogress.php http://www.bitrepository.com/uploading-files-with-progress-bar.html Steve I'll check it out! Thanks! Floyd -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Upload Progress Meter
Brad Broerman wrote: Essentially, they all require Flash or Java... You are generally talking about two different sides of the client/server relationship.. unless you are talking about Applets, right?... so I have an issue with the statement. If jquery does one (as mentioned), it's likely not Flash nor Java. I'm not trying to be an arse or anything, but I don't see it being that limiting. I do think it's difficult to recommend a progress meter when there is not a lot of info given of what is being metered. If you need to meter the processes for javascript, then you'd likely use javascript, if you need to meter a server-side intensive task, then you could use a server-side method, or a combination of things. It all comes down to a pretty graphic to watch while your waiting for a task to finish. ;-) Donovan -- D Brooke -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Upload Progress Meter
On Wed, 2011-03-23 at 09:59 -0400, Floyd Resler wrote: I am in need of an upload progress meter. I've seen plenty of tutorials = on-line requiring installing modules, hooks, patches, etc. However, my = Wordpress install accomplished this without me having to make any = modifications to my PHP install. So, how is it done? Thanks! Floyd you can google this... jquery upload progress meter or: http://www.nixboxdesigns.com/demos/jquery-uploadprogress.php http://www.bitrepository.com/uploading-files-with-progress-bar.html Steve -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Upload Progress Meter
On Mar 23, 2011, at 10:10 AM, Steve Staples wrote: On Wed, 2011-03-23 at 09:59 -0400, Floyd Resler wrote: I am in need of an upload progress meter. I've seen plenty of tutorials = on-line requiring installing modules, hooks, patches, etc. However, my = Wordpress install accomplished this without me having to make any = modifications to my PHP install. So, how is it done? Thanks! Floyd you can google this... jquery upload progress meter or: http://www.nixboxdesigns.com/demos/jquery-uploadprogress.php http://www.bitrepository.com/uploading-files-with-progress-bar.html Steve I'll check it out! Thanks! Floyd -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] upload progress (was www.soongy.com)
On Mon, 2009-03-02 at 18:35 -0800, mike wrote: On Mon, Mar 2, 2009 at 3:29 PM, Ashley Sheridan a...@ashleysheridan.co.uk wrote: There are a lot of free FTP Java applets out there, which you could easily integrate with a web page and your hosting. You'll have the advantage of a familiar interface, multiple uploads, queues, and progress bars. Worst case scenario, user has no Java and you have to offer a standard upload form. since it's java, you're getting into Michael's infinite paranoia soapbox... :) also it requires FTP credentials, or an FTP account, which makes life a living hell. firewalls, NATted setups, people finding out it's an open FTP, etc. If you are requiring an applet, I don't see why there is even a discussion. Go with Gears, no extra server code or configuration necessary. If you are anti-applet, you'll still need javascript, and depending on the file sizes you're dealing with, you'll need to modify the server configuration (which is out of a lot of people's control) Whoever said anything about open FTP? Ash www.ashleysheridan.co.uk -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] upload progress (was www.soongy.com)
On Tue, Mar 3, 2009 at 12:02 AM, Ashley Sheridan a...@ashleysheridan.co.uk wrote: Whoever said anything about open FTP? how else do you do it? either it's open/anonymous, or some hardcoded account info. either way, not very secure, and due to the nature of it, kinda requires the user to have enough privileges to upload N files of X bytes (you could put quotas on it, chroot it, blahblah... but still) -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] upload progress (was www.soongy.com)
On Tue, 2009-03-03 at 02:20 -0800, mike wrote: On Tue, Mar 3, 2009 at 12:02 AM, Ashley Sheridan a...@ashleysheridan.co.uk wrote: Whoever said anything about open FTP? how else do you do it? either it's open/anonymous, or some hardcoded account info. either way, not very secure, and due to the nature of it, kinda requires the user to have enough privileges to upload N files of X bytes (you could put quotas on it, chroot it, blahblah... but still) The way I've done it for a system at work (it is for staff and clients only, so I guess that offers some protection) is to use scripts in conjunction with vsftp. Accounts are managed through an admin web interface, and each user has their own login credentials. Admittedly, the username and password are passed as plain text for it to auto log-in, but afaik, that happens with standard FTP anyway (unencrypted connections). This is more than likely overkill for this situation, but I had to resort to it as the system has to handle files over 2GB, and file upload forms are just not meant to handle that kind of load in the upstream! Ash www.ashleysheridan.co.uk -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] upload progress (was www.soongy.com)
-Original Message- From: mike [mailto:mike...@gmail.com] Sent: Monday, March 02, 2009 12:17 AM To: Gevorg Harutyunyan Cc: tedd; German Geek; php-general@lists.php.net Subject: Re: [PHP] www.soongy.com I have a basic demo here. The code is not at it's best, you have to hit reload to upload a new file. http://mikehost.com/~mike/tmp/u/ It does show you though with some javascript trickery and some math you can derive estimated time and approximate speed. I did have an example of multiple files too (I don't think this one supports that) At some point I'll publish all the components required and clean it up nicely. I also have an nginx module to complement it that should be available soon, to alleviate the need for the PHP processing piece (even though it does work like a charm) On Sun, Mar 1, 2009 at 10:05 PM, Gevorg Harutyunyan gevorg...@gmail.com wrote: Thank you all for your help! I tried to do without being dependent from flash, but as I see there are only two ways for this: flash and loading without tracking percentage. I choose second way :) On Mon, Mar 2, 2009 at 1:58 AM, mike mike...@gmail.com wrote: gears will allow you to do that, more or less. i have it going... Gears will allow you to do a lot of things. So will site-proprietary Firefox extensions that go well outside the realm of basic client-server interaction via webpages. I was under the impression that Gears requires a local installation of their client library in order to work. I don't think download this new extension so you can upload files to our site is going to go over so well. On Sun, Mar 1, 2009 at 12:34 PM, tedd tedd.sperl...@gmail.com wrote: At 12:13 PM -0800 3/1/09, mike wrote: you can use gears pretty easily to make a seamless multiple file upload now. it's all javascript too so you can make it look how you want, behave how you want, etc. without having to buy/tweak flash code. On Sun, Mar 1, 2009 at 12:07 PM, German Geek geek...@gmail.com wrote: Also check this one out: google uses it in gmail: http://code.google.com/p/jquery-multifile- plugin/downloads/detail?name=multiple-file-upload.zipcan=2q= Understood, but I don't think either of these do what the OP wanted, whcih was a real time file upload progress bar. // Todd
Re: [PHP] upload progress (was www.soongy.com)
On Mon, Mar 2, 2009 at 7:45 AM, Boyd, Todd M. tmbo...@ccis.edu wrote: Gears will allow you to do a lot of things. So will site-proprietary Firefox extensions that go well outside the realm of basic client-server interaction via webpages. I was under the impression that Gears requires a local installation of their client library in order to work. I don't think download this new extension so you can upload files to our site is going to go over so well. Of course not, but a) browsers don't have it built-in, yet (I was working on trying to make a standard that I could pitch to browser creators) b) how do you think the flash or java applets got there anyway? :) Have a standard upload form. Tell people if they want more advanced multi-file support, progress support, etc, etc, install Gears as well. To me, Gears should be something just like Flash and Java... and I think is lighter-weight and allows for extending browser capabilities across nearly every platform without learning new languages. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] upload progress (was www.soongy.com)
-Original Message- From: mike [mailto:mike...@gmail.com] Sent: Monday, March 02, 2009 12:59 PM To: Boyd, Todd M. Cc: PHP General list Subject: Re: [PHP] upload progress (was www.soongy.com) On Mon, Mar 2, 2009 at 7:45 AM, Boyd, Todd M. tmbo...@ccis.edu wrote: Gears will allow you to do a lot of things. So will site-proprietary Firefox extensions that go well outside the realm of basic client- server interaction via webpages. I was under the impression that Gears requires a local installation of their client library in order to work. I don't think download this new extension so you can upload files to our site is going to go over so well. Of course not, but a) browsers don't have it built-in, yet (I was working on trying to make a standard that I could pitch to browser creators) b) how do you think the flash or java applets got there anyway? :) Have a standard upload form. Tell people if they want more advanced multi-file support, progress support, etc, etc, install Gears as well. To me, Gears should be something just like Flash and Java... and I think is lighter-weight and allows for extending browser capabilities across nearly every platform without learning new languages. Well it's just Javascript with access to local database storage and a caching facility, isn't it? I mean, I know Google threw a bunch of their API libraries in there with it (geolocation, for instance), but what little digging I've done into the matter has produced what I consider extended Javascript. Again, I don't know a whole lot about it--I've just looked over the example scripts and read an article about its caching capabilities as applied to Wikipedia. // Todd
Re: [PHP] upload progress (was www.soongy.com)
mike wrote: On Mon, Mar 2, 2009 at 7:45 AM, Boyd, Todd M. tmbo...@ccis.edu wrote: Gears will allow you to do a lot of things. So will site-proprietary Firefox extensions that go well outside the realm of basic client-server interaction via webpages. I was under the impression that Gears requires a local installation of their client library in order to work. I don't think download this new extension so you can upload files to our site is going to go over so well. Of course not, but a) browsers don't have it built-in, yet (I was working on trying to make a standard that I could pitch to browser creators) b) how do you think the flash or java applets got there anyway? :) Have a standard upload form. Tell people if they want more advanced multi-file support, progress support, etc, etc, install Gears as well. To me, Gears should be something just like Flash and Java... and I think is lighter-weight and allows for extending browser capabilities across nearly every platform without learning new languages. I don't like to install firefox extensions, I keep them to a bare minimum (more stable that way, less annoyances from updates to some extension or another being found ever session, etc) and I don't like sites that depend upon flash and java for functionality. I won't install an extension just to use a specific site, I only install an extension if it is something I want (IE noscript - to keep your annoying flash from using my browsers resources). You can do a good multi-file upload progress bar w/ the client only needing to allow JavaScript. In the OP's case that may mean the OP has to change hosts or use perl to process the upload, but here's the thing - if the client doesn't allow JavaScript, the upload still works fine - they just don't get a progress bar. You can use the same form - just use noscriptfoo/noscript to tell users to be patient and not hit submit 20 zillion times. With a flash / java based solution, you have to have different code for users who wisely do not allow flash and/or java, which is more work for you (you have to test and maintain multiple uploads) and requires the user to take specific action depending upon their setup. // steps off soap box -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] upload progress (was www.soongy.com)
I have just been wondering for the 20 zillion time why does people always stick together 20 and zillion? you can't just use zillion times? is that not enough for you? On Mon, Mar 2, 2009 at 10:26 PM, Michael A. Peters mpet...@mac.com wrote: mike wrote: On Mon, Mar 2, 2009 at 7:45 AM, Boyd, Todd M. tmbo...@ccis.edu wrote: Gears will allow you to do a lot of things. So will site-proprietary Firefox extensions that go well outside the realm of basic client-server interaction via webpages. I was under the impression that Gears requires a local installation of their client library in order to work. I don't think download this new extension so you can upload files to our site is going to go over so well. Of course not, but a) browsers don't have it built-in, yet (I was working on trying to make a standard that I could pitch to browser creators) b) how do you think the flash or java applets got there anyway? :) Have a standard upload form. Tell people if they want more advanced multi-file support, progress support, etc, etc, install Gears as well. To me, Gears should be something just like Flash and Java... and I think is lighter-weight and allows for extending browser capabilities across nearly every platform without learning new languages. I don't like to install firefox extensions, I keep them to a bare minimum (more stable that way, less annoyances from updates to some extension or another being found ever session, etc) and I don't like sites that depend upon flash and java for functionality. I won't install an extension just to use a specific site, I only install an extension if it is something I want (IE noscript - to keep your annoying flash from using my browsers resources). You can do a good multi-file upload progress bar w/ the client only needing to allow JavaScript. In the OP's case that may mean the OP has to change hosts or use perl to process the upload, but here's the thing - if the client doesn't allow JavaScript, the upload still works fine - they just don't get a progress bar. You can use the same form - just use noscriptfoo/noscript to tell users to be patient and not hit submit 20 zillion times. With a flash / java based solution, you have to have different code for users who wisely do not allow flash and/or java, which is more work for you (you have to test and maintain multiple uploads) and requires the user to take specific action depending upon their setup. // steps off soap box -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] upload progress (was www.soongy.com)
Nitsan Bin-Nun wrote: I have just been wondering for the 20 zillion time why does people always stick together 20 and zillion? you can't just use zillion times? is that not enough for you? My server can handle 19 zillion multiple submits. ;) -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] upload progress (was www.soongy.com)
Nitsan Bin-Nun wrote: I have just been wondering for the 20 zillion time why does people always stick together 20 and zillion? you can't just use zillion times? is that not enough for you? Actually, instead of 20 zillion I would say 2 bazillion, or .2 gazillion. Now if I really wanted to impress, I would go for jillions, bajillions or maybe gajillions. Umptillion is right out... -- Thanks! -Shawn http://www.spidean.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] upload progress (was www.soongy.com)
Yes you can do it with only javascript but you'll need server components to deal with large files ... Which the OP does not have access to. Post and file limits could become an issue. Not to mention flash and java penetration is huge. I think flash is on something like 96% of browsers now... Just think of how usenet, bittorrent, etc work. They split up larger files into smaller chunks and assemble it after. The same idea was in my head when I approached this. On Mar 2, 2009, at 12:26 PM, Michael A. Peters mpet...@mac.com wrote: mike wrote: On Mon, Mar 2, 2009 at 7:45 AM, Boyd, Todd M. tmbo...@ccis.edu wrote: Gears will allow you to do a lot of things. So will site- proprietary Firefox extensions that go well outside the realm of basic client-server interaction via webpages. I was under the impression that Gears requires a local installation of their client library in order to work. I don't think download this new extension so you can upload files to our site is going to go over so well. Of course not, but a) browsers don't have it built-in, yet (I was working on trying to make a standard that I could pitch to browser creators) b) how do you think the flash or java applets got there anyway? :) Have a standard upload form. Tell people if they want more advanced multi-file support, progress support, etc, etc, install Gears as well. To me, Gears should be something just like Flash and Java... and I think is lighter-weight and allows for extending browser capabilities across nearly every platform without learning new languages. I don't like to install firefox extensions, I keep them to a bare minimum (more stable that way, less annoyances from updates to some extension or another being found ever session, etc) and I don't like sites that depend upon flash and java for functionality. I won't install an extension just to use a specific site, I only install an extension if it is something I want (IE noscript - to keep your annoying flash from using my browsers resources). You can do a good multi-file upload progress bar w/ the client only needing to allow JavaScript. In the OP's case that may mean the OP has to change hosts or use perl to process the upload, but here's the thing - if the client doesn't allow JavaScript, the upload still works fine - they just don't get a progress bar. You can use the same form - just use noscriptfoo/noscript to tell users to be patient and not hit submit 20 zillion times. With a flash / java based solution, you have to have different code for users who wisely do not allow flash and/or java, which is more work for you (you have to test and maintain multiple uploads) and requires the user to take specific action depending upon their setup. // steps off soap box -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] upload progress (was www.soongy.com)
mike wrote: Yes you can do it with only javascript but you'll need server components to deal with large files ... Which the OP does not have access to. Post and file limits could become an issue. Not to mention flash and java penetration is huge. I think flash is on something like 96% of browsers now... And more and more people are using something like noscript to block it because XSS hacks are out of control. It is too easy to publish a website and too many web developers only care about their own data, they don't care about protecting users from malicious content. That's why more and more users who have flash installed are not letting web sites execute it (or anything). If you are youtube, it is reasonable to require the user have flash installed. Otherwise there's a good chance they won't. I don't let a site execute flash in my browser unless I'm sure I need it to get what I want. Sites that code in flash that don't need to, I'm not going to open up myself to possible XSS exploits just because they chose to make their site only work when I open up my browser to vulnerabilities. Many corporate environments are now also mandating that flash and javascript be disables as well because of the XSS dangers. Use Javascript to make life easier on those who have it enabled but if things don't work peachy without it, you are doing it wrong. Use flash for what really genuinely requires flash, and file upload isn't one of them. Once http://people.mozilla.org/~bsterne/content-security-policy/ is properly implemented - I intend to only allow sites that set a reasonable security policy to execute anything in my browser, and I suspect other users will do the same. Then maybe if you have properly coded your site to send a content-security-policy header with reasonable policies I might let you use flash to upload files, assuming your policy specifies the source for the flash must be on your domain, but right now there just isn't enough client side security available to properly protect the users who allow execution, so educated users are very leery of allowing anything to run in their browser. If I attached somefile.exe and told you to run it, would you? Web masters who require the user to allow execution are doing just that, and users who allow such execution of code they know nothing about are, to be blundt, fools and easy targets. // steps off soap box - permanently for awhile, I'm getting too preachy -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] upload progress (was www.soongy.com)
On Mon, 2009-03-02 at 15:02 -0800, mike wrote: Yes you can do it with only javascript but you'll need server components to deal with large files ... Which the OP does not have access to. Post and file limits could become an issue. Not to mention flash and java penetration is huge. I think flash is on something like 96% of browsers now... Just think of how usenet, bittorrent, etc work. They split up larger files into smaller chunks and assemble it after. The same idea was in my head when I approached this. On Mar 2, 2009, at 12:26 PM, Michael A. Peters mpet...@mac.com wrote: mike wrote: On Mon, Mar 2, 2009 at 7:45 AM, Boyd, Todd M. tmbo...@ccis.edu wrote: Gears will allow you to do a lot of things. So will site- proprietary Firefox extensions that go well outside the realm of basic client-server interaction via webpages. I was under the impression that Gears requires a local installation of their client library in order to work. I don't think download this new extension so you can upload files to our site is going to go over so well. Of course not, but a) browsers don't have it built-in, yet (I was working on trying to make a standard that I could pitch to browser creators) b) how do you think the flash or java applets got there anyway? :) Have a standard upload form. Tell people if they want more advanced multi-file support, progress support, etc, etc, install Gears as well. To me, Gears should be something just like Flash and Java... and I think is lighter-weight and allows for extending browser capabilities across nearly every platform without learning new languages. I don't like to install firefox extensions, I keep them to a bare minimum (more stable that way, less annoyances from updates to some extension or another being found ever session, etc) and I don't like sites that depend upon flash and java for functionality. I won't install an extension just to use a specific site, I only install an extension if it is something I want (IE noscript - to keep your annoying flash from using my browsers resources). You can do a good multi-file upload progress bar w/ the client only needing to allow JavaScript. In the OP's case that may mean the OP has to change hosts or use perl to process the upload, but here's the thing - if the client doesn't allow JavaScript, the upload still works fine - they just don't get a progress bar. You can use the same form - just use noscriptfoo/noscript to tell users to be patient and not hit submit 20 zillion times. With a flash / java based solution, you have to have different code for users who wisely do not allow flash and/or java, which is more work for you (you have to test and maintain multiple uploads) and requires the user to take specific action depending upon their setup. // steps off soap box -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php There are a lot of free FTP Java applets out there, which you could easily integrate with a web page and your hosting. You'll have the advantage of a familiar interface, multiple uploads, queues, and progress bars. Worst case scenario, user has no Java and you have to offer a standard upload form. Ash www.ashleysheridan.co.uk -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] upload progress (was www.soongy.com)
On Mon, Mar 2, 2009 at 3:29 PM, Ashley Sheridan a...@ashleysheridan.co.uk wrote: There are a lot of free FTP Java applets out there, which you could easily integrate with a web page and your hosting. You'll have the advantage of a familiar interface, multiple uploads, queues, and progress bars. Worst case scenario, user has no Java and you have to offer a standard upload form. since it's java, you're getting into Michael's infinite paranoia soapbox... :) also it requires FTP credentials, or an FTP account, which makes life a living hell. firewalls, NATted setups, people finding out it's an open FTP, etc. If you are requiring an applet, I don't see why there is even a discussion. Go with Gears, no extra server code or configuration necessary. If you are anti-applet, you'll still need javascript, and depending on the file sizes you're dealing with, you'll need to modify the server configuration (which is out of a lot of people's control) -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] upload progress (was www.soongy.com)
On Mon, Mar 2, 2009 at 3:25 PM, Michael A. Peters mpet...@mac.com wrote: And more and more people are using something like noscript to block it because XSS hacks are out of control. It is too easy to publish a website and too many web developers only care about their own data, they don't care about protecting users from malicious content. More and more ... yes, a handful a day. The vast majority of users don't. Just like people going insane about cookie security. It's the uninformed and paranoid spreading FUD. I have Javascript, Java, Flash and Gears all enabled on my browsers - I have zero issues. I enjoy the capabilities that Flash and Gears add too, and nowadays almost every website relies on Javascript for something. That's why more and more users who have flash installed are not letting web sites execute it (or anything). Got some stats/URLs for this? If you are youtube, it is reasonable to require the user have flash installed. Otherwise there's a good chance they won't. Interesting. Flash has a 96% or some sort penetration, and it is not usually based on a per-site basis. Why is youtube the only site someone would allow Flash on? More and more websites are turning to rich media, with Flash being the defacto standard. Go to almost any major website, and if the content itself doesn't have Flash mixed in, the banner ads and other functionality does. I don't let a site execute flash in my browser unless I'm sure I need it to get what I want. Sites that code in flash that don't need to, I'm not going to open up myself to possible XSS exploits just because they chose to make their site only work when I open up my browser to vulnerabilities. Only the paranoid survive... I also don't drive on days ending with y because of the chance of an automobile accident. Many corporate environments are now also mandating that flash and javascript be disables as well because of the XSS dangers. Funny, I work for a fortune 50 company and Java is mandatory on our machines due to the intranet applications which require applet support. Use Javascript to make life easier on those who have it enabled but if things don't work peachy without it, you are doing it wrong. Gears is basically extensiosn to Javascript with some security baked in... so thank you for further reiterating my point. Use flash for what really genuinely requires flash, and file upload isn't one of them. Agreed. It's just another applet option. Just like ActiveX or Java. If I attached somefile.exe and told you to run it, would you? Web masters who require the user to allow execution are doing just that, and users who allow such execution of code they know nothing about are, to be blundt, fools and easy targets. Last I checked, Flash applets aren't very insecure. Java is a bit easier. ActiveX is very easy. It's all about the installation and the user. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Upload Progress Meter - what's the latest?
On Tue, April 25, 2006 9:23 pm, D. Dante Lorenso wrote: Richard Lynch wrote: On Tue, April 25, 2006 5:28 pm, D. Dante Lorenso wrote: Everything PHP returns from a server is client side, so your Oh yeah. I forgot to say... The above presumption is patently false. Let me clarify: Assuming client/server architecture, if PHP is on the server side then something else needs to be on the client side to interpret the output of the PHP server. That output is what PHP returns and it is interpreted and rendered on the client side by definition. Alternatively: If it is not meant for the client to receive, it is not (should not) be output by PHP. Guess I'd better throw away all my command-line scripts and cron jobs, and all my PHP GTK half-finished projects, and... Plus, all the times I've got a web page that initiates some asynchronous process and outputs only a tiny fraction of its output to the browser, while generating a GREAT DEAL of output elsewhere. :-) Maybe we're just posting at cross-purposes here, but PHP does a hell of a lot more than spit out HTML web pages... -- Like Music? http://l-i-e.com/artists.htm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Upload Progress Meter - what's the latest?
On Tue, April 25, 2006 9:55 pm, D. Dante Lorenso wrote: Richard Lynch wrote: that the replies I've gotten from this list so far suggest that internals of PHP development are seriously opposed to such a feature? They may or may not be opposed to attempting to use server-side technology to provide client-side statistical data, for a file that the CLIENT is uploading. Which is why I suggested that the request for server-side statistical tracking of uploads in progress for the server-side statistical analysis would be a Good Thing to propose. I am more interested in which project extensions are leading in momentum to solve the problem I am trying to solve and not blaming other projects (browsers) for not building the feature first. The momentum, as far as I know, of all the project extensions to do what you describe is zero (0). The back-and-forth you refer to is termed 'polling'. With a protocol like HTTP, polling is really the only option unless I implement a socket server which is capable of sending events. Gah! I know what it's called. Let's try AGAIN. You want to use POLLING from server to client to measure how much data the client has sent. Does not the CLIENT already *KNOW* how much data it sent? Why in the world would you generate all that traffic to compute data already in existence on the client in the first place? That is the fundamental problem to which objections are raised on this issue. It's just plain daft to poll the server to find out how much data you sent it, when you're the one sending the data. Right. Under the callback method example, I would have access to $_SESSION which would already contain enough information about the logged in account for my purposes. This is trivial. If it's trivial, code up the patch and send it. For tying the filenames back to the users who are logged in, you'd have to have an onClick() on the submit button which would send some kind of information (filename, filesize, user) to a PHP script that would log the upload about to begin in a database. The onClick would then return false so that the normal form submission process would kick in. This will not work. And this is exactly WHY an extention/patch is needed. Between the time PHP choses a /tmp file name and the time the upload is completed, there is not execution of PHP code. Therefor, we don't know the /tmp name assigned to an upload until AFTER the upload is completed and then it's too late. Oh but there *IS* execution of all kinds of PHP code between that time -- Just not in the script that is receiving the file. Since you're building a statistical monitoring of the process, I'm suggesting that you have ANOTHER PHP script running to examine the state of /tmp and monitor the progress from outside the script actually receiving the file. It won't be pretty, but it can be done with what's available in PHP today, without patches. You're not going to get ... accuracy ... It won't be so hot for tracking who's uploading what in real-time, It should be. Using the patch, I already have this working. I now want a cleaner, supported solution which doesn't involve a custom patch which will not be supported in the future. Although the patch I am using works, it was build for PHP 5.0.3 RC1 and since I am using 5.1.2 you can understand my concerns that it will fail to continue working when the switch is made to PHP 5.2 or PHP 6.0. If you submit a similar patch, and specifically label it as server-side statistical analysis feature for uploaded files in progress, I SUSPECT it has a much better chance of going than a server-side hack to solve a client-side problem. Another option is to provide patch to PHP which gives a special INPUT parameter to a FORM that can be used to provide a callback file to load, and a callback function within that file to call, and then modify the file upload routine to load and call that function. Passing this from the client form is insecure and can not be trusted. Declaring callback functions needs to remain a server-side declaration either through code or an INI setting, etc. You're right. That would be a gaping security hole. It seems genuinely useful enough to this naive reader, and should not cause an undue burden for those who don't use it. Check with PHP-Dev to see if such a patch is likely to be accepted before putting in TOO much time on it. My original email was searching for advice on which project has momentum and what the current state of any discussions about the issue were. Does anybody have information on the PEAR package which appears to be vapor? http://pecl.php.net/package/postparser I see the name Curt Zirzow, but no contact information for that author. He posted a few zillion messages here in PHP-General... His email has to be in the Marc archives. Is there not a package which has been adopted by the community or does every developer share Richard's opinion that
Re: [PHP] Upload Progress Meter - what's the latest?
On Tue, April 25, 2006 12:18 pm, D. Dante Lorenso wrote: I'm trying to figure out which direction the PHP community is going when it comes to an upload progress meter. Since that meter would necessarily be CLIENT side, the PHP community is pretty much ignoring it, since PHP runs on the SERVER. Anything you see with PHP upload progress meter together has to be some kind of hack whose under-pinning is NOT PHP at all, but is JavaScript or similar client-side technology. Why don't you ask the guys who write BROWSERS why *they* don't provide a nice API/interface to display progress, or, better yet, why the browser itself doesn't just do it once and for all for everybody? -- Like Music? http://l-i-e.com/artists.htm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Upload Progress Meter - what's the latest?
Richard Lynch wrote: On Tue, April 25, 2006 12:18 pm, D. Dante Lorenso wrote: I'm trying to figure out which direction the PHP community is going when it comes to an upload progress meter. Since that meter would necessarily be CLIENT side, the PHP community is pretty much ignoring it, since PHP runs on the SERVER. Anything you see with PHP upload progress meter together has to be some kind of hack whose under-pinning is NOT PHP at all, but is JavaScript or similar client-side technology. Why don't you ask the guys who write BROWSERS why *they* don't provide a nice API/interface to display progress, or, better yet, why the browser itself doesn't just do it once and for all for everybody? let's consider that 99% of all clients would want a 'nice' looking progress bar (in the same way they often asking me to do something about the std form fields, which they consider ugly). i.e. it would just be moving the problem somewhere else in practical terms, in so far as we'd probably still have to figure out hacks to make the bl**dy thing look nice (in the eyes of the guy/girl paying the bill ;-) and for the record there are other languages that support a progress bar idiom ... php being the pragmatic thing that it is should imho entertain this idea more seriously (waiting for browsers to implement it or ignoring the continually recurring request for such functionality) that said Richard has a very strong argument. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Upload Progress Meter - what's the latest?
Richard Lynch wrote: On Tue, April 25, 2006 12:18 pm, D. Dante Lorenso wrote: I'm trying to figure out which direction the PHP community is going when it comes to an upload progress meter.Since that meter would necessarily be CLIENT side, the PHP community is pretty much ignoring it, since PHP runs on the SERVER. Everything PHP returns from a server is client side, so your argument seems to indicate that we need to write all of our HTML using JavaScript also. No, the fact is that a client-side GUI does NOT exist, so we need to build it ourselves using the tools we have. I do not have source control access to Mozilla, IE, Safari, and Opera, but I can control my own PHP source. PHP receives uploads from clients and that client may not even be a web browser in all cases. From the server side, I need to be able to monitor * who is currently uploading files, * which files are being uploaded, * how big are the files being uploaded, * how much time has passed since upload began, and * what percentage of those files is completed I do not need to return this data to a client at all times. Sometimes I just want to use the data system administration, analysis, and tracking. The most popular need would be for returning the information to the client, however, as you suggest. Right now, PHP stops executing code from the time an upload begins until the time it is completed. In other languages like PERL as CGI, you can read STDIN directly in order to slurp in large POST data like file attachments. In such a case as that, solving this problem is trivial. Since PHP locks a programmer out of the loop during parsing and importing POST and GET variables, we need PHP code to break into that loop and return callback functions or update internal data structures directly. Part of the problem in addition to collection of the data is being able to share it with other PHP instances. Remember that PHP runs in Apache in most cases and does not have shared memory between PHP instances. Therefore, writing the upload data to an external data storage is necessary. That external storage could be Sqlite, PostgreSQL, MySQL, files, or even Memcache. I would love to see a memcache-like solution. But more importantly, I would like to see a solution which is adopted by the community rather than miserably hacked together then not supported and abandoned. Anything you see with PHP upload progress meter together has to be some kind of hack whose under-pinning is NOT PHP at all, but is JavaScript or similar client-side technology. Not true. The graphical display is HTML, DHTML, JavaScript, etc...but the means of monitoring the progress from the server side MUST be done with PHP. The code that I have seen so far requires hooks into PHP which execute callback functions periodically in order to update the progress of uploaded files as PHP processes input. Why don't you ask the guys who write BROWSERS why *they* don't provide a nice API/interface to display progress, or, better yet, why the browser itself doesn't just do it once and for all for everybody? That is a good idea, and I will recommend it for future solutions. For short term, that is not the focus of this email. Dante -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Upload Progress Meter - what's the latest?
On Tue, April 25, 2006 5:28 pm, D. Dante Lorenso wrote: Richard Lynch wrote: On Tue, April 25, 2006 12:18 pm, D. Dante Lorenso wrote: Anything you see with PHP upload progress meter together has to be some kind of hack whose under-pinning is NOT PHP at all, but is JavaScript or similar client-side technology. Not true. The graphical display is HTML, DHTML, JavaScript, etc...but the means of monitoring the progress from the server side MUST be done with PHP. I'm sorry. Your original post sounded (to me) like you wanted a progress meter on the browser (client-side) for the user to see their files uploaded. AFAIK, all the tools you referenced were written with that purpose in mind. Presumably even the worst browsers have some concept of how large the file is, and how many bytes have been sent to the server. So you certainly DO NOT need server-side information to implement a client-side progress meter of the progress of a file upload! The code that I have seen so far requires hooks into PHP which execute callback functions periodically in order to update the progress of uploaded files as PHP processes input. Yes, which is a silly place to try and fix this for client-side progress meters, as you then generate traffic back-and-forth from the client to measure the number of bytes received, instead of the browser just measuring bytes sent. browser in all cases. From the server side, I need to be able to monitor * who is currently uploading files, * which files are being uploaded, * how big are the files being uploaded, * how much time has passed since upload began, and * what percentage of those files is completed I do not need to return this data to a client at all times. Sometimes I just want to use the data system administration, analysis, and tracking. The most popular need would be for returning the information to the client, however, as you suggest. In this case, a meter isn't going to cut it... You'd need a battery of meters, for all running processes, or at least all the ones currently in file upload state. You'd also need tie-ins to your login/authentication to determin who is uploading files as the only answer inherent to PHP is the User set in httpd.conf Which files are being uploaded would presumably display both the original name as sent by the browser, which is not something one can trust for anything useful, and the /tmp name. How big they are relies on the browser sending the correct Content-length: for the upload. I don't know how often they get it right, but I'm betting that are some pretty common errors in this area that PHP corrects for already. So your meters would not be accurate in some (hopefully few) cases. While I can see where this might be a useful tool to have server-side, I can suggest several possible ways to implement some portions of it without hacking PHP source. First, it's a pretty safe bet that PHP uses a common prefix on the files being uploaded. So you could write a tool to watch /tmp for files and get a list of the /tmp names being uploaded. That would at least tell you how many files are currently in upload status. Using filectime and filemtime would tell you the timing info -- Though Windows will suck (as usual) as it only tracks to the nearest minute or something... For tying the filenames back to the users who are logged in, you'd have to have an onClick() on the submit button which would send some kind of information (filename, filesize, user) to a PHP script that would log the upload about to begin in a database. The onClick would then return false so that the normal form submission process would kick in. You would then have to use heuristics about the file timing to guess which files were most likely which -- though you could probably get pretty accurate about that part, especially if you are willing to code it so that completed uploads tie back in and eliminate incorrect guesses. You're not going to get the level of accuracy you'd have with hacked PHP source, but you can get enough accuracy for statistical analysis. It won't be so hot for tracking who's uploading what in real-time, due to the guessing part -- but after the upload finishes your information will be as accurate as it can be with hacked source. Another option is to provide patch to PHP which gives a special INPUT parameter to a FORM that can be used to provide a callback file to load, and a callback function within that file to call, and then modify the file upload routine to load and call that function. It seems genuinely useful enough to this naive reader, and should not cause an undue burden for those who don't use it. Check with PHP-Dev to see if such a patch is likely to be accepted before putting in TOO much time on it. HTH Why don't you ask the guys who write BROWSERS why *they* don't provide a nice API/interface to display progress, or, better yet, why the browser itself doesn't just do it once and for all
Re: [PHP] Upload Progress Meter - what's the latest?
On Tue, April 25, 2006 5:28 pm, D. Dante Lorenso wrote: Everything PHP returns from a server is client side, so your Oh yeah. I forgot to say... The above presumption is patently false. :-) -- Like Music? http://l-i-e.com/artists.htm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Upload Progress Meter - what's the latest?
On Tue, April 25, 2006 5:27 pm, Jochem Maas wrote: Richard Lynch wrote: On Tue, April 25, 2006 12:18 pm, D. Dante Lorenso wrote: Why don't you ask the guys who write BROWSERS why *they* don't provide a nice API/interface to display progress, or, better yet, why the browser itself doesn't just do it once and for all for everybody? let's consider that 99% of all clients would want a 'nice' looking progress bar (in the same way they often asking me to do something about the std form fields, which they consider ugly). i.e. it would just be moving the problem somewhere else in practical terms, in so far as we'd probably still have to figure out hacks to make the bl**dy thing look nice (in the eyes of the guy/girl paying the bill ;-) Well, yes, if the browser doesn't provide hooks for the look n feel of the darn thing, we're not solving anything. I still don't think a progress meter for browsers is something that belongs in PHP in any way, shape, or form. Please note my other much longer post on useful server-side statistical info about file uploads, however. There *IS* a progress meter on some browsers down in the status bar, or in other places, which, apparently, the average user is too clueless to notice consciously. Though I have noted that semi-experienced users know it is there subconsciously if you ask them the right questions about how far along the upload is. Very weird animal, those users... :-) -- Like Music? http://l-i-e.com/artists.htm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Upload Progress Meter - what's the latest?
[snip] ...a pretty good discussion... [/snip] I have used output buffering to flush stuff (like lengthy data) to the client before the end of the script so that those pesky users could see something was happening (because they couldn't be bothered to watch the browser's progress meter) and at one time thought that you might be able to do something like a progress meter with that. Since the http process is stateless it would be hard to provide a truly accurate progress meter. There are too many factors at play. Using PHP in an Ajax environment might move it a little closer and is an interesting thought and depends upon the reliability of the asynchronous request. There is the old stand-by...send an animated gif to the browser with no real timing involved. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Upload Progress Meter - what's the latest?
Richard Lynch wrote: On Tue, April 25, 2006 5:28 pm, D. Dante Lorenso wrote: Everything PHP returns from a server is client side, so your Oh yeah. I forgot to say... The above presumption is patently false. Let me clarify: Assuming client/server architecture, if PHP is on the server side then something else needs to be on the client side to interpret the output of the PHP server. That output is what PHP returns and it is interpreted and rendered on the client side by definition. Alternatively: If it is not meant for the client to receive, it is not (should not) be output by PHP. Dante -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Upload Progress Meter - what's the latest?
Richard Lynch wrote: Anything you see with PHP upload progress meter together has to be some kind of hack whose under-pinning is NOT PHP at all, but is JavaScript or similar client-side technology. Not true. The graphical display is HTML, DHTML, JavaScript, etc...but the means of monitoring the progress from the server side MUST be done with PHP. I'm sorry. Your original post sounded (to me) like you wanted a progress meter on the browser (client-side) for the user to see their files uploaded. Yes, I want that also. Really, I want the feature to exist in the PHP language regardless of how I intend to use it. That's the beauty of a programming language vs a program. I want the tools to be able to build what I want however I might want it at the time. Presumably even the worst browsers have some concept of how large the file is, and how many bytes have been sent to the server. So you certainly DO NOT need server-side information to implement a client-side progress meter of the progress of a file upload! Agreed. I SHOULD not NEED this feature. Other server-side languages exist, so I technically don't NEED PHP either. I don't really want to debate whether this feature should exist or not, but it seems to me that the replies I've gotten from this list so far suggest that internals of PHP development are seriously opposed to such a feature? I am more interested in which project extensions are leading in momentum to solve the problem I am trying to solve and not blaming other projects (browsers) for not building the feature first. The code that I have seen so far requires hooks into PHP which execute callback functions periodically in order to update the progress of uploaded files as PHP processes input. Yes, which is a silly place to try and fix this for client-side progress meters, as you then generate traffic back-and-forth from the client to measure the number of bytes received, instead of the browser just measuring bytes sent. The back-and-forth you refer to is termed 'polling'. With a protocol like HTTP, polling is really the only option unless I implement a socket server which is capable of sending events. This is something I may be building into the project also, but aside from HOW I move the server-side collect data back to a web client, that is independent of needing to collect the information on the server side in a format which can be accessed and read easily. browser in all cases. From the server side, I need to be able to monitor * who is currently uploading files, * which files are being uploaded, * how big are the files being uploaded, * how much time has passed since upload began, and * what percentage of those files is completed I do not need to return this data to a client at all times. Sometimes I just want to use the data system administration, analysis, and tracking. The most popular need would be for returning the information to the client, however, as you suggest. You'd need a battery of meters, for all running processes, or at least all the ones currently in file upload state. I would like to have a list of all file uploads in progress, yes. A semi-frequently updated snapshot of the information I defined would be sufficient. If a callback function is invoked periodically it would be equivalent to firing an event and would allow a php program to log the data to a common data repository which could be ready by another process on the system. You'd also need tie-ins to your login/authentication to determin who is uploading files as the only answer inherent to PHP is the User set in httpd.conf Right. Under the callback method example, I would have access to $_SESSION which would already contain enough information about the logged in account for my purposes. This is trivial. How big they are relies on the browser sending the correct Content-length: for the upload. I don't know how often they get it right, but I'm betting that are some pretty common errors in this area that PHP corrects for already. So your meters would not be accurate in some (hopefully few) cases. The POST method sets the Content-length, right. So, PHP must trust that the browsers are not lying. For security purposes we don't need to worry about whether this number is wrong because it is only for display. Processing uploaded files does not occur until the file completes uploading. While I can see where this might be a useful tool to have server-side, I can suggest several possible ways to implement some portions of it without hacking PHP source. First, ... you could write a tool to watch /tmp for files and get a list of the /tmp names being uploaded. Yes, this is simple. Using filectime and filemtime would tell you the timing info -- Though Windows will suck (as usual) as it only tracks to the nearest minute or something... Yes. Using Linux. This will work. For tying the
Re: [PHP] Upload Progress
http://electroteque.dyndns.org:1023/demo/uploader/ following my other posts i have a working flash progress bar , although i cannot remove the empty arrays in the count how can i remove empty arrays in an array , the empty file inputs seem to still contain something , so instead of 1 as the count if you upload only one file , its still 5 for 5 file input fields Jed Verity [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... You're right about it costing more money. But we had one server handling a bunch of uploads, most of them over 25 MB, and 99% being instigated by very impatient, not very technical, people. People who kept canceling and canceling, despite our directions, because they thought it was stuck or frozen or taking too long. It was worth $150 for us to buy the ASP component (I think we used ABCUpload, maybe?). The development time required for a creative PHP solution -- and one that might not have worked as well -- would have been dramatically more expensive than the almost out-of-the-box solution with ASP's components. (And much of the site was already written in ASP.) Other than that, you'll get know argument from me about ASP vs. PHP. I'm head over heels for PHP and, in any context other than the one stated above (and maybe one or two others), I would choose to use God Blessed PHP over anything else. Cheers! Jed P.S. I knew I'd get some fighters with that comment. Haven't learned my lesson yet... ;-) On the threshold of genius, Jay Blanchard wrote: [snip] There really isn't a great solution for this, that I know of. It's one of the few things that makes an argument for ASP over PHP, as far as I'm concerned (if you have the luxury of choosing). Below is what I did once to try to get around the problem. It worked *okay*. [/snip] How does this argue for ASP over PHP? I don't see how. File upload on PHP is built in and therefore free. ASP file upload mechs cost more money. And, having used ASP for a while, and having looked for this feature, no upload progress bar exists there either. And PHP is a language, where ASP is a service ... please do not confuse the two. If you want to argue VBScript vs. PHP , well ,come on ... let's go. :^] PHP can beat VBScript with one curly-brace tied behind its back. I mentioned a while back, when this came up before (see the archives) that this could probably be done with an IFRAME in the upload dialog box. Now I haven't given this much thought, but maybe it could be done. The largest problem that I see is the communication back and forth between client and server. The server would have to know the original size of the file at the point the upload is started, then it would be checked for original_size minus bits_uploaded, flush the reults to the IFRAME drawing a GD graph, and continue to do this as it went on. Another method is to start the upload with a non-progressive animation that quits when is_upload_file() returns true. Jay -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Upload Progress
Jed Verity [EMAIL PROTECTED] wrote: There really isn't a great solution for this, that I know of. It's one of the few things that makes an argument for ASP over PHP, as far as I'm concerned (if you have the luxury of choosing). How is this an argument for ASP? HTTP has no way of tracking file upload progress, no matter what scripting language you are using. Luke Welling. -- PHP and MySQL Web Development by Luke Welling and Laura Thomson http://www.amazon.com/exec/obidos/ASIN/0672317842/tangledwebdesign -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Upload Progress
How is this an argument for ASP? HTTP has no way of tracking file upload progress, no matter what scripting language you are using. Asp has some nice upload components (ATL/COM), which handle the upload progress. Therefor they will be able to put nice upload dialogs to the user. On the other side, the ASP solution is kind of the same as Jed's, so you are right, it isn't an argument. Grtz Erwin -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Upload Progress
[snip] There really isn't a great solution for this, that I know of. It's one of the few things that makes an argument for ASP over PHP, as far as I'm concerned (if you have the luxury of choosing). Below is what I did once to try to get around the problem. It worked *okay*. [/snip] How does this argue for ASP over PHP? I don't see how. File upload on PHP is built in and therefore free. ASP file upload mechs cost more money. And, having used ASP for a while, and having looked for this feature, no upload progress bar exists there either. And PHP is a language, where ASP is a service ... please do not confuse the two. If you want to argue VBScript vs. PHP , well ,come on ... let's go. :^] PHP can beat VBScript with one curly-brace tied behind its back. I mentioned a while back, when this came up before (see the archives) that this could probably be done with an IFRAME in the upload dialog box. Now I haven't given this much thought, but maybe it could be done. The largest problem that I see is the communication back and forth between client and server. The server would have to know the original size of the file at the point the upload is started, then it would be checked for original_size minus bits_uploaded, flush the reults to the IFRAME drawing a GD graph, and continue to do this as it went on. Another method is to start the upload with a non-progressive animation that quits when is_upload_file() returns true. Jay -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Upload Progress
You're right about it costing more money. But we had one server handling a bunch of uploads, most of them over 25 MB, and 99% being instigated by very impatient, not very technical, people. People who kept canceling and canceling, despite our directions, because they thought it was stuck or frozen or taking too long. It was worth $150 for us to buy the ASP component (I think we used ABCUpload, maybe?). The development time required for a creative PHP solution -- and one that might not have worked as well -- would have been dramatically more expensive than the almost out-of-the-box solution with ASP's components. (And much of the site was already written in ASP.) Other than that, you'll get know argument from me about ASP vs. PHP. I'm head over heels for PHP and, in any context other than the one stated above (and maybe one or two others), I would choose to use God Blessed PHP over anything else. Cheers! Jed P.S. I knew I'd get some fighters with that comment. Haven't learned my lesson yet... ;-) On the threshold of genius, Jay Blanchard wrote: [snip] There really isn't a great solution for this, that I know of. It's one of the few things that makes an argument for ASP over PHP, as far as I'm concerned (if you have the luxury of choosing). Below is what I did once to try to get around the problem. It worked *okay*. [/snip] How does this argue for ASP over PHP? I don't see how. File upload on PHP is built in and therefore free. ASP file upload mechs cost more money. And, having used ASP for a while, and having looked for this feature, no upload progress bar exists there either. And PHP is a language, where ASP is a service ... please do not confuse the two. If you want to argue VBScript vs. PHP , well ,come on ... let's go. :^] PHP can beat VBScript with one curly-brace tied behind its back. I mentioned a while back, when this came up before (see the archives) that this could probably be done with an IFRAME in the upload dialog box. Now I haven't given this much thought, but maybe it could be done. The largest problem that I see is the communication back and forth between client and server. The server would have to know the original size of the file at the point the upload is started, then it would be checked for original_size minus bits_uploaded, flush the reults to the IFRAME drawing a GD graph, and continue to do this as it went on. Another method is to start the upload with a non-progressive animation that quits when is_upload_file() returns true. Jay -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Upload Progress
Ya' know guys i'm sitting here thinking about this problem because I have the same problem on one of my sites. A bunch of inpatient stupid users whom are click happy when they get impatient. Event a 100K upload can take to long! I don't like the ASP idea. It's really not a good solution. I'm almost wondering if a JAVA solution which can do FTP directly or maybe a direct socket connection/transfer with Macromedia Flash would work. Both of these ways you could better monitor what's going on at the packet level and therefore giving a lot of control over something like a progress bar. Who knows. It's got to be something other than PHP though because PHP is after all only a server side language. -Original Message- From: Jed Verity [mailto:[EMAIL PROTECTED]] Sent: Monday, September 09, 2002 11:08 AM To: Jay Blanchard; [EMAIL PROTECTED] Subject: Re: [PHP] Upload Progress You're right about it costing more money. But we had one server handling a bunch of uploads, most of them over 25 MB, and 99% being instigated by very impatient, not very technical, people. People who kept canceling and canceling, despite our directions, because they thought it was stuck or frozen or taking too long. It was worth $150 for us to buy the ASP component (I think we used ABCUpload, maybe?). The development time required for a creative PHP solution -- and one that might not have worked as well -- would have been dramatically more expensive than the almost out-of-the-box solution with ASP's components. (And much of the site was already written in ASP.) Other than that, you'll get know argument from me about ASP vs. PHP. I'm head over heels for PHP and, in any context other than the one stated above (and maybe one or two others), I would choose to use God Blessed PHP over anything else. Cheers! Jed P.S. I knew I'd get some fighters with that comment. Haven't learned my lesson yet... ;-) On the threshold of genius, Jay Blanchard wrote: [snip] There really isn't a great solution for this, that I know of. It's one of the few things that makes an argument for ASP over PHP, as far as I'm concerned (if you have the luxury of choosing). Below is what I did once to try to get around the problem. It worked *okay*. [/snip] How does this argue for ASP over PHP? I don't see how. File upload on PHP is built in and therefore free. ASP file upload mechs cost more money. And, having used ASP for a while, and having looked for this feature, no upload progress bar exists there either. And PHP is a language, where ASP is a service ... please do not confuse the two. If you want to argue VBScript vs. PHP , well ,come on ... let's go. :^] PHP can beat VBScript with one curly-brace tied behind its back. I mentioned a while back, when this came up before (see the archives) that this could probably be done with an IFRAME in the upload dialog box. Now I haven't given this much thought, but maybe it could be done. The largest problem that I see is the communication back and forth between client and server. The server would have to know the original size of the file at the point the upload is started, then it would be checked for original_size minus bits_uploaded, flush the reults to the IFRAME drawing a GD graph, and continue to do this as it went on. Another method is to start the upload with a non-progressive animation that quits when is_upload_file() returns true. Jay -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Upload Progress
why not just get creative, pop up a window on submit with an animated gif of a dot moving back and forth or similar and an uploading message and then close it when the page reloads. most of these things on have nothing to do with progress of what's really happening in my experience. Paul Roberts http://www.paul-roberts.com [EMAIL PROTECTED] - Original Message - From: David Buerer [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, September 09, 2002 7:20 PM Subject: RE: [PHP] Upload Progress Ya' know guys i'm sitting here thinking about this problem because I have the same problem on one of my sites. A bunch of inpatient stupid users whom are click happy when they get impatient. Event a 100K upload can take to long! I don't like the ASP idea. It's really not a good solution. I'm almost wondering if a JAVA solution which can do FTP directly or maybe a direct socket connection/transfer with Macromedia Flash would work. Both of these ways you could better monitor what's going on at the packet level and therefore giving a lot of control over something like a progress bar. Who knows. It's got to be something other than PHP though because PHP is after all only a server side language. -Original Message- From: Jed Verity [mailto:[EMAIL PROTECTED]] Sent: Monday, September 09, 2002 11:08 AM To: Jay Blanchard; [EMAIL PROTECTED] Subject: Re: [PHP] Upload Progress You're right about it costing more money. But we had one server handling a bunch of uploads, most of them over 25 MB, and 99% being instigated by very impatient, not very technical, people. People who kept canceling and canceling, despite our directions, because they thought it was stuck or frozen or taking too long. It was worth $150 for us to buy the ASP component (I think we used ABCUpload, maybe?). The development time required for a creative PHP solution -- and one that might not have worked as well -- would have been dramatically more expensive than the almost out-of-the-box solution with ASP's components. (And much of the site was already written in ASP.) Other than that, you'll get know argument from me about ASP vs. PHP. I'm head over heels for PHP and, in any context other than the one stated above (and maybe one or two others), I would choose to use God Blessed PHP over anything else. Cheers! Jed P.S. I knew I'd get some fighters with that comment. Haven't learned my lesson yet... ;-) On the threshold of genius, Jay Blanchard wrote: [snip] There really isn't a great solution for this, that I know of. It's one of the few things that makes an argument for ASP over PHP, as far as I'm concerned (if you have the luxury of choosing). Below is what I did once to try to get around the problem. It worked *okay*. [/snip] How does this argue for ASP over PHP? I don't see how. File upload on PHP is built in and therefore free. ASP file upload mechs cost more money. And, having used ASP for a while, and having looked for this feature, no upload progress bar exists there either. And PHP is a language, where ASP is a service ... please do not confuse the two. If you want to argue VBScript vs. PHP , well ,come on ... let's go. :^] PHP can beat VBScript with one curly-brace tied behind its back. I mentioned a while back, when this came up before (see the archives) that this could probably be done with an IFRAME in the upload dialog box. Now I haven't given this much thought, but maybe it could be done. The largest problem that I see is the communication back and forth between client and server. The server would have to know the original size of the file at the point the upload is started, then it would be checked for original_size minus bits_uploaded, flush the reults to the IFRAME drawing a GD graph, and continue to do this as it went on. Another method is to start the upload with a non-progressive animation that quits when is_upload_file() returns true. Jay -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Upload Progress
your problem is nothing seems to happen when they click the submit button, you can use JavaScript to prevent re-submission, change the text on the submit button or you could even pop up a window on submit with an animated gif of a dot moving back and forth or similar and an uploading message and then close it when the page reloads. Just a few ideas. Paul Roberts http://www.paul-roberts.com [EMAIL PROTECTED] - Original Message - From: David Buerer [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, September 09, 2002 7:20 PM Subject: RE: [PHP] Upload Progress Ya' know guys i'm sitting here thinking about this problem because I have the same problem on one of my sites. A bunch of inpatient stupid users whom are click happy when they get impatient. Event a 100K upload can take to long! I don't like the ASP idea. It's really not a good solution. I'm almost wondering if a JAVA solution which can do FTP directly or maybe a direct socket connection/transfer with Macromedia Flash would work. Both of these ways you could better monitor what's going on at the packet level and therefore giving a lot of control over something like a progress bar. Who knows. It's got to be something other than PHP though because PHP is after all only a server side language. -Original Message- From: Jed Verity [mailto:[EMAIL PROTECTED]] Sent: Monday, September 09, 2002 11:08 AM To: Jay Blanchard; [EMAIL PROTECTED] Subject: Re: [PHP] Upload Progress You're right about it costing more money. But we had one server handling a bunch of uploads, most of them over 25 MB, and 99% being instigated by very impatient, not very technical, people. People who kept canceling and canceling, despite our directions, because they thought it was stuck or frozen or taking too long. It was worth $150 for us to buy the ASP component (I think we used ABCUpload, maybe?). The development time required for a creative PHP solution -- and one that might not have worked as well -- would have been dramatically more expensive than the almost out-of-the-box solution with ASP's components. (And much of the site was already written in ASP.) Other than that, you'll get know argument from me about ASP vs. PHP. I'm head over heels for PHP and, in any context other than the one stated above (and maybe one or two others), I would choose to use God Blessed PHP over anything else. Cheers! Jed P.S. I knew I'd get some fighters with that comment. Haven't learned my lesson yet... ;-) On the threshold of genius, Jay Blanchard wrote: [snip] There really isn't a great solution for this, that I know of. It's one of the few things that makes an argument for ASP over PHP, as far as I'm concerned (if you have the luxury of choosing). Below is what I did once to try to get around the problem. It worked *okay*. [/snip] How does this argue for ASP over PHP? I don't see how. File upload on PHP is built in and therefore free. ASP file upload mechs cost more money. And, having used ASP for a while, and having looked for this feature, no upload progress bar exists there either. And PHP is a language, where ASP is a service ... please do not confuse the two. If you want to argue VBScript vs. PHP , well ,come on ... let's go. :^] PHP can beat VBScript with one curly-brace tied behind its back. I mentioned a while back, when this came up before (see the archives) that this could probably be done with an IFRAME in the upload dialog box. Now I haven't given this much thought, but maybe it could be done. The largest problem that I see is the communication back and forth between client and server. The server would have to know the original size of the file at the point the upload is started, then it would be checked for original_size minus bits_uploaded, flush the reults to the IFRAME drawing a GD graph, and continue to do this as it went on. Another method is to start the upload with a non-progressive animation that quits when is_upload_file() returns true. Jay -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Upload Progress
Regarding the idea of using a socket connection with Flash: It's not possible. You neither have file access with Flash (at least not from the browser plugin), nor access to a low level of the data to send it packet-wise. It would be nice if the POST method did handle more details (total file size). But then we would still have to wait for PHP and the whole bunch of browsers to support it. (Maybe there already is a related RFC?) Timo Am Montag den, 9. September 2002, um 20:20, schrieb David Buerer: Ya' know guys i'm sitting here thinking about this problem because I have the same problem on one of my sites. A bunch of inpatient stupid users whom are click happy when they get impatient. Event a 100K upload can take to long! I don't like the ASP idea. It's really not a good solution. I'm almost wondering if a JAVA solution which can do FTP directly or maybe a direct socket connection/transfer with Macromedia Flash would work. Both of these ways you could better monitor what's going on at the packet level and therefore giving a lot of control over something like a progress bar. Who knows. It's got to be something other than PHP though because PHP is after all only a server side language. -Original Message- From: Jed Verity [mailto:[EMAIL PROTECTED]] Sent: Monday, September 09, 2002 11:08 AM To: Jay Blanchard; [EMAIL PROTECTED] Subject: Re: [PHP] Upload Progress You're right about it costing more money. But we had one server handling a bunch of uploads, most of them over 25 MB, and 99% being instigated by very impatient, not very technical, people. People who kept canceling and canceling, despite our directions, because they thought it was stuck or frozen or taking too long. It was worth $150 for us to buy the ASP component (I think we used ABCUpload, maybe?). The development time required for a creative PHP solution -- and one that might not have worked as well -- would have been dramatically more expensive than the almost out-of-the-box solution with ASP's components. (And much of the site was already written in ASP.) Other than that, you'll get know argument from me about ASP vs. PHP. I'm head over heels for PHP and, in any context other than the one stated above (and maybe one or two others), I would choose to use God Blessed PHP over anything else. Cheers! Jed P.S. I knew I'd get some fighters with that comment. Haven't learned my lesson yet... ;-) On the threshold of genius, Jay Blanchard wrote: [snip] There really isn't a great solution for this, that I know of. It's one of the few things that makes an argument for ASP over PHP, as far as I'm concerned (if you have the luxury of choosing). Below is what I did once to try to get around the problem. It worked *okay*. [/snip] How does this argue for ASP over PHP? I don't see how. File upload on PHP is built in and therefore free. ASP file upload mechs cost more money. And, having used ASP for a while, and having looked for this feature, no upload progress bar exists there either. And PHP is a language, where ASP is a service ... please do not confuse the two. If you want to argue VBScript vs. PHP , well ,come on ... let's go. :^] PHP can beat VBScript with one curly-brace tied behind its back. I mentioned a while back, when this came up before (see the archives) that this could probably be done with an IFRAME in the upload dialog box. Now I haven't given this much thought, but maybe it could be done. The largest problem that I see is the communication back and forth between client and server. The server would have to know the original size of the file at the point the upload is started, then it would be checked for original_size minus bits_uploaded, flush the reults to the IFRAME drawing a GD graph, and continue to do this as it went on. Another method is to start the upload with a non-progressive animation that quits when is_upload_file() returns true. Jay -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Upload Progress
Regarding the idea of using a socket connection with Flash: It's not possible. You neither have file access with Flash (at least not from the browser plugin), nor access to a low level of the data to send it packet-wise. It would be nice if the POST method did handle more details (total file size). But then we would still have to wait for PHP and the whole bunch of browsers to support it. (Maybe there already is a related RFC?) Timo Am Montag den, 9. September 2002, um 20:20, schrieb David Buerer: Ya' know guys i'm sitting here thinking about this problem because I have the same problem on one of my sites. A bunch of inpatient stupid users whom are click happy when they get impatient. Event a 100K upload can take to long! I don't like the ASP idea. It's really not a good solution. I'm almost wondering if a JAVA solution which can do FTP directly or maybe a direct socket connection/transfer with Macromedia Flash would work. Both of these ways you could better monitor what's going on at the packet level and therefore giving a lot of control over something like a progress bar. Who knows. It's got to be something other than PHP though because PHP is after all only a server side language. -Original Message- From: Jed Verity [mailto:[EMAIL PROTECTED]] Sent: Monday, September 09, 2002 11:08 AM To: Jay Blanchard; [EMAIL PROTECTED] Subject: Re: [PHP] Upload Progress You're right about it costing more money. But we had one server handling a bunch of uploads, most of them over 25 MB, and 99% being instigated by very impatient, not very technical, people. People who kept canceling and canceling, despite our directions, because they thought it was stuck or frozen or taking too long. It was worth $150 for us to buy the ASP component (I think we used ABCUpload, maybe?). The development time required for a creative PHP solution -- and one that might not have worked as well -- would have been dramatically more expensive than the almost out-of-the-box solution with ASP's components. (And much of the site was already written in ASP.) Other than that, you'll get know argument from me about ASP vs. PHP. I'm head over heels for PHP and, in any context other than the one stated above (and maybe one or two others), I would choose to use God Blessed PHP over anything else. Cheers! Jed P.S. I knew I'd get some fighters with that comment. Haven't learned my lesson yet... ;-) On the threshold of genius, Jay Blanchard wrote: [snip] There really isn't a great solution for this, that I know of. It's one of the few things that makes an argument for ASP over PHP, as far as I'm concerned (if you have the luxury of choosing). Below is what I did once to try to get around the problem. It worked *okay*. [/snip] How does this argue for ASP over PHP? I don't see how. File upload on PHP is built in and therefore free. ASP file upload mechs cost more money. And, having used ASP for a while, and having looked for this feature, no upload progress bar exists there either. And PHP is a language, where ASP is a service ... please do not confuse the two. If you want to argue VBScript vs. PHP , well ,come on ... let's go. :^] PHP can beat VBScript with one curly-brace tied behind its back. I mentioned a while back, when this came up before (see the archives) that this could probably be done with an IFRAME in the upload dialog box. Now I haven't given this much thought, but maybe it could be done. The largest problem that I see is the communication back and forth between client and server. The server would have to know the original size of the file at the point the upload is started, then it would be checked for original_size minus bits_uploaded, flush the reults to the IFRAME drawing a GD graph, and continue to do this as it went on. Another method is to start the upload with a non-progressive animation that quits when is_upload_file() returns true. Jay -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Upload Progress
A bunch of inpatient stupid users whom are click happy when they get impatient. impatient, not very technical, people. People who kept canceling and canceling, despite our directions, because they thought it was stuck or frozen or taking too long. the simplest and most elegant work around i've seen is to use javascript to disable the submit button after it has been clicked. a second click creates a javascript alert that says 'be patient, your request is being handled'. josh -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Upload Progress
There really isn't a great solution for this, that I know of. It's one of the few things that makes an argument for ASP over PHP, as far as I'm concerned (if you have the luxury of choosing). Below is what I did once to try to get around the problem. It worked *okay*. The bummer is that I had to ask people to enter the size of their file in a field. (Rough estimates were okay.) Then, as soon as somebody hit the submit button on my form, I popped up a small, modal, progress bar sized window that was actually two frames. I passed the file size value from the form field to the top frame. In the bottom frame, JavaScript created a bordered div equal in pixel length to the number of MB of the file being uploaded. The top frame, a PHP doc, would then refresh every three seconds, executing a filesize() on the uploaded file, converting it to MB, rounding up, and then using DHTML to resize the width of a blue-gradient gif contained in the div of the bottom frame of the progress bar window. Typically, this worked okay for me. It wasn't the prettiest progress bar in the world, but it did the trick for most people. HTH! Jed On the threshold of genius, Jacob Miller wrote: Everything I've read says that there is no way to display the progress of a file upload (via a form) using PHP. I'm currently working on a site which will regularly be accepting very large uploads, anywhere from 10 to 250+ mb and I really need a way to display the progress of the upload so that it doesn't appear as if the browser has frozen for a few hours. Any suggestions for a solution? thanks -jacob -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Upload Progress
Sorry, I wrote too quickly. I meant that the file size field value is passed to the bottom frame. And JavaScript is used to resize the gif, not DHTML. (Used to be DHTML when I was adding nbsp instead of resizing an image.) HTH, Jed On the threshold of genius, Jed Verity wrote: There really isn't a great solution for this, that I know of. It's one of the few things that makes an argument for ASP over PHP, as far as I'm concerned (if you have the luxury of choosing). Below is what I did once to try to get around the problem. It worked *okay*. The bummer is that I had to ask people to enter the size of their file in a field. (Rough estimates were okay.) Then, as soon as somebody hit the submit button on my form, I popped up a small, modal, progress bar sized window that was actually two frames. I passed the file size value from the form field to the top frame. In the bottom frame, JavaScript created a bordered div equal in pixel length to the number of MB of the file being uploaded. The top frame, a PHP doc, would then refresh every three seconds, executing a filesize() on the uploaded file, converting it to MB, rounding up, and then using DHTML to resize the width of a blue-gradient gif contained in the div of the bottom frame of the progress bar window. Typically, this worked okay for me. It wasn't the prettiest progress bar in the world, but it did the trick for most people. HTH! Jed On the threshold of genius, Jacob Miller wrote: Everything I've read says that there is no way to display the progress of a file upload (via a form) using PHP. I'm currently working on a site which will regularly be accepting very large uploads, anywhere from 10 to 250+ mb and I really need a way to display the progress of the upload so that it doesn't appear as if the browser has frozen for a few hours. Any suggestions for a solution? thanks -jacob -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Upload Progress
Yikes, I sort of lied. It's been awhile... Clients uploaded files from an intranet server to an external servier via their browser and ftp_put. It wasn't local machine to remote server. Sorry! Best of luck, Jed P.S. I wonder, though, if there isn't some way to execute a script with exec() to get the info through the file system. There was some talk awhile back about using flush(), too. If you haven't already, check the archives for that one... On the threshold of genius, Jacob Miller wrote: I was considering this option earlier but I couldn't figure out how to determine the tmp file name of the file being uploaded (in cases where there is more than one upload in progress at a time). How did you go about determining the name of the tmp file? thanks - Jacob At 01:29 09/09/2002, you wrote: There really isn't a great solution for this, that I know of. It's one of the few things that makes an argument for ASP over PHP, as far as I'm concerned (if you have the luxury of choosing). Below is what I did once to try to get around the problem. It worked *okay*. The bummer is that I had to ask people to enter the size of their file in a field. (Rough estimates were okay.) Then, as soon as somebody hit the submit button on my form, I popped up a small, modal, progress bar sized window that was actually two frames. I passed the file size value from the form field to the top frame. In the bottom frame, JavaScript created a bordered div equal in pixel length to the number of MB of the file being uploaded. The top frame, a PHP doc, would then refresh every three seconds, executing a filesize() on the uploaded file, converting it to MB, rounding up, and then using DHTML to resize the width of a blue-gradient gif contained in the div of the bottom frame of the progress bar window. Typically, this worked okay for me. It wasn't the prettiest progress bar in the world, but it did the trick for most people. HTH! Jed On the threshold of genius, Jacob Miller wrote: Everything I've read says that there is no way to display the progress of a file upload (via a form) using PHP. I'm currently working on a site which will regularly be accepting very large uploads, anywhere from 10 to 250+ mb and I really need a way to display the progress of the upload so that it doesn't appear as if the browser has frozen for a few hours. Any suggestions for a solution? thanks -jacob -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
