I am curious as to know if the basic PHP File Upload procedure will work on all devices.
Such as:
All Major Browsers
Mobile Phones (iPhone, Blackberry, Android, Palm)
I need to be able to upload Videos/Photos from any device onto our server, will there be any issues that you can forsee?
First Off, PHP is not the one that handles file uploads, that dependent on the browser and how they handle it. The browser is the one sending the information about the file (contents, size, type)
Second, mobile platforms will not do this well. iPhone doesn't allow file uploads from their browser. I'm not sure on android, but iPhone alone should be enough to re-think this.
The browser doesn't "SEE" PHP....php is server side code. The interaction on the front end might happen with flash (often used in "ajax-styled" uploads") javascript, and/or html. HTML is about as basic as it gets, so 99% of the devices out there can deal with it.
Just imagine the chaos if we had to coordinate our browsers with the back-end technology. It's tough enough as it is with the lack of current standards and half-decade-in-the-dark browser team that does IE....thanks Microsoft.....
I'd personally caution you against using bleeding-edge technology such as CSS3 or HTML5 if you're trying to make something "universally" compatible. For example, AOL's browser, which is still in use, believe it or not, is essentially an old version of IE6. Some of the phone browsers are even more basic, though I'd question whether people would ever REALLY use those in an upload situation. It's not fun to use "old" technology, but especially when clients are very specific about backwards compatibility, you often don't have a choice.
Related
I am writing a mobile version of a website, and I want to
use WURFL-PHP to perform the mobility check on the client.
re-use the existing .htaccess files. I don't want to parse anything manually. This is better left to Apache.
For simplicity, let's say I have two flat files: file.d.html and file.m.html. In index.php, I consider making an appropriate HTTP request on one of these files depending on the client we are serving (mobile vs non-mobile) and forwarding the response to the client. Everything will be the way .htaccess files prescribe.
To make the request, a PHP library called pecl_http exists. Problem is: I only have a shared hosting plan, so my webhost is reluctant to make it available.
So, can someone tell me if this is reasonable, or I'm just complicating things?
Also, is there any way to accomplish this without an extra HTTP request? I wonder if Apache has some way to test for mobility. Perhaps I can add something to .htaccess instead of coding it in PHP.
Many thanks.
Personally I wouldn't do this server-side but with javascript and CSS media queries. Specifically there is process called 'Responsive Web Design' where your browser picks your styles based on the screen width in pixels. This avoids the evil of browser sniffing and therefore will generally support future mobile platforms without any changes. You can use the display style to hide whole blocks of content if necessary or just use different values for width and float to change from horizontal to vertical layouts. The Wikipedia page on RWD warns that some mobile platforms don't support media queries but in practice as of 2012 that's an extremely small share of the mobile market.
My client having a requirement that need to upload huge video files (e.g. 5GB) to his own server via browser, need have progress bar and pause/resume would be even better.
Wondering if there's any existing services (paid or not) for doing such a thing. Also any technique that I might able to implement this by myself. I've seen Vimeo allows user upload huge file by HTTP, not sure how they make it.
Currently I'm using JAVA FTP applet but it really slow and not that stable if transferring time is hours (e.g. I got socket exception, peer reset). So really keen to seek some more stable and lightweighted solution
Any tips?
In order to upload such large files with a browser, you can use SWFUpload and the native HTML4 method and if the user selects a large file, he is prompted to click on a button to toggle the native uploader. In Webkit, Firefox and IE8 that seems to work great for files in the 10+ gigabyte range.
Remember Youtube runs on Googles custom server software.
I just saw the McDonald's commercial which I have linked to below and I would like to try developing something similar for a festival. We have been talking about making a game in which the user has to use their iPhone and something like what McDonald's has done would be great.
My question is if anyone have an idea how I can send the data and what technology they might have used? I imagine making two websites. One on which the game itself is shown and one which is the controller but how would I make sure that the data is sent and handled fast enough?
I am familiar with JavaScript and PHP. I have been working a bit with flash and ActionScript and I am wondering if that might be best for the game (obviously not the controller)
You can see the McDonald's commercial on the link below. Basically, the user visits a webpage which is the controller and then they are able to play the ping-pong game on the big screen.
Any ideas and brainstorming on how to do this is welcome.
Watch the McDonald's Pick n Play commercial here.
Just use WebSockets. The problem with them is browser support and supporting older browsers / platforms.
To handle this there are various abstractions. I would personally recommend socket.io A solid abstraction that relies on node.js. Has a range of fallbacks (including COMET and Flash). Whilst your at it, you might want to looking into using node for realtime applications (it's great!)
I would create a socket server that hosts the game (socket TCP/IP connection). The purpose of the socket server application would be to listen for connections, wait for 2 players, start the game, decide who wins and sett-era (it could also have some queue of players that will play next and inform the players where they are in the queue).
Now, how do we establish a connection from the website to that socket server?
I wouldn't use WebSockets because it's not widely supported at the moment, disabled by default in FireFox and IE does not have it implemented yet (AFAIK).
Now you have to decide, do you want to do the website in Flash or HTML. You could even use hybrid of both. For example:
Hybrid:
Use the Flash application on the controller website to act as the communicator between JavaScript and the server. When Flash retrieves data from the socket server then it will make JavaScript take care of the retrieved command. E.g. move pad up. (I use that method for my online chat application and it works like a charm).
Flash only:
Use pure Flash application as the controller and communicator to the socket server.
Voila! You have something similar to the MacDonalds game.
I hope my answer is clear enough and feel free to comment if some of my statements are wrong.
In my view, This is what I would go for :
A small client app that will be downloaded when connected to the website.Considering it in mobile platform, java app preferably. Alternative is flash, which is also suitable, but if graphics is not our aim then I suppose better hold it off.
A server to provide real time connections to the users one-at-a-time. (As shown in video). This is the actual pain for all the games out there. I would go looking for one of these projects as platforms:
http://opensource.adobe.com/wiki/display/blazeds/BlazeDS
http://www.smartfoxserver.com/
http://www.cubeia.org/
http://appengine.google.com/
Besides that, ideas - I would have liked if it was multi player (there was quite a crowd), but that would have meant at least person winning every game & more of free give aways for them.
As alternative can be COMET a web application model in which a long-held HTTP request allows a web server to push data to a browser, without the browser explicitly requesting it
have a look here: Comet
So far I've figured out HOW to upload files asynchronously with Ajax and PHP, no problem there. But I want to get the percentage of the file that's already been uploaded, as it's uploading, and, after hours of research, I can't find a good way to do this without cheating.
Some implementations I've seen used Flash to upload, and getting the percentage in Flash is apparently fairly common, but I'd like to avoid this if I can.
Any ideas?
The core problem is that RFC 1867, the specification for file uploads over HTTP via the multipart/form-data MIME type, does not provide any method for providing file upload progress.
A file upload is actually just a fancy form submit. CGI scripts, PHP, and all other web technologies that rely on a front-end web server to first accept the request might not actually begin executing until the entire upload has completed. This means that they generally can't even know when the upload has started, only when it's been completed.
New versions of PHP's APC extension include a workaround for this problem that performs some level of black magic that allows it to know about uploads earlier. It only works as part of mod_php, though. The devs don't seem to have plans to support it under FastCGI.
Another server-side option would be the "uploadprogress" PECL extension. I'm not entirely sure what kind of black magic it uses. The source suggests that it actually hooks into the processing of the multipart MIME parts. (This suggests that at least some SAPIs stream form data to PHP as the client uploads it. I know that at least some FastCGI servers buffer the entire request before passing it along, so this might not work for you. YMMV.)
Both of these options are for normal file uploads. Ajax -- or rather, XMLHttpRequest -- does not support file upload operations. Most of the workarounds in this area involve creating an iframe and submitting a form there, and that also implies someone else's client-side work. If you're going to go through that level of hoop jumping, you'd may as well use one of the modern file upload widgets.
Personally, I use Plupload, a Javascript widget that can work with everyone's favorite Javascript library, jQuery. Some others swear by Uploadify. Regardless, both of these widgets offer a high degree of user feedback as to upload progress. They are likely to be easier for you to implement than APC or uploadprogress and have the advantage of being built and tested thoroughly by other people.
Plupload supports multiple upload engines, including HTML5, Gears, Flash, Silverlight, oldschool HTML4 and more. Between HTML5, Flash and Silverlight, you've pretty much just covered 100% of your audience. It also allows you to subscribe to events and have your own code perform magic. For example, if you need server-side file upload progress information, you can have the client regularly send updates to a different script. This would be useful if you regularly have clients uploading huge files and you want to know about it in real time.
tl;dr: Uploading is hard, let's go client-side!
Yeah,I dont like that "cheating" method either, In my opinon, the best method is to use APC , and its method, apc_fetch
Using ajax to make a apc_fetch, with a unique key specifying the upload, will return what you need .. ie bytes uploaded / total bytes.
Then simply do a progress bar with javascript.
I have heard chrome and safari dont allow you to do ajax calls during post upload, the work arround includes using an iframe to do the calls with the apc identifier.
I code primarily in PHP and Perl. I have a client who is insisting on seeking video submissions (any encoding) from the public via one of their pages rather than letting YouTube do its job.
Server in question is a virtual machine and I can adjust ini settings for max post, max upload size etc as needed.
My initial thought is to use a Flash based uploader with PHP on the back end but I wondered if someone might have useful advice and experience on the subject?
Doing large file transfers of HTTP is not usually fun -- but sometimes it's necessary.
For large files, you'll definitely want to provide some kind of progress gauge for end-users.
There are flash-based tools that do this (swfUpload comes to mind).
If you want to avoid flash and do it with pretty html/javascript/css, you can leverage PHP's APC extension, which for some reason provides support for getting upload status from the server, as explained here
You can adjust the post size and use a normal html form. The big problem is not Apache, its http. If anything goes wrong in the transmission you will have no way to detect the error. Further more there is no way to resume the transfer. This is exactly why BitTorrent is so popular.
I don't know how against youtube your client is, but you can use their api to do the uploads from a page on your site.
http://code.google.com/apis/youtube/2.0/developers_guide_protocol.html#Uploading_Videos
See: browser based uploading.
For web-based uploads, there's not many options. Regardless of web platform, web server, etc. you're still transferring over HTTP. The transfer is all or nothing.
Your best option might be to find a Flash, Java, or other client side option that can chunk files and upload them piecemeal, then do a checksum to verify. That will allow for resuming uploads. Unfortunately, I don't know of any such open source component that does this.
Try to convince your client to change point of view.
Using http (and the browser, hell, the browser!) for this kind of issue is rarely a good deal; Will his users wait 40 minutes with the computer and the browser running until the upload is complete?
I dont think so.
Maybe, you could set up a public ftp account, where users can upload but not download and see the others user's files.. then, who want to use FTP software can, who like to do it via browser can too.
The big problem dealing using a browser is that, if something go wrong, you cant resume but have to restart from zero again.
the past year i had the same issue, i gave a look to ZUpload
, but i didnt use it so i can suggest (we wrote a small python script that we send to our customer; the python script create a torrent of the folder our costumer need to send to us, and we download it via utorrent ;)
p.s: again, sorry for my bad english ;)
I used jupload. Yes it looks horrible, but it just works.
With that said, it's still a better idea to convince the client that doing so is stupid.
I would agree with others stating that using HTML is a poor option. I believe there is a size limitation using Flash as well. I know of a script that uses a JavaScript Applet to perform an actual FTP transfer. It is called Simple2FTP and can be found at http://www.simple2ftp.com
Not sure but perhaps worth a try?