We've all used the various uploaders that are available. And all of us have had an instance where an uploader doesn't work, or suddenly stops working, thereby disrupting our entire workflow.
Transferring files over the Internet isn't rocket science. In fact there's a special protocol for it--the File Transfer Protocol, or FTP for short. FTP is much more robust than http for sending files. It is cross-platform and supports almost every computing device out there, new and old. This way, the only time uploading stops working is when something is broken at SM, not when some code on a third party uploader needs updating. Exposure Manager has FTP uploading capability.
I use a FTP program to upload/download and maintain my own website. It would be a grand idea for us to be able to use FTP for uploading. I hope you can fit this in the system in the future.
This is not rocket science, FOTKI and several others have been doing it forever. Until you know the ease of this process you really DO NOT KNOW how disappointing smugmug is. This is what is keeping my from purchasing an account along with two other photographers I work with.
Smugmug already is a pain to setup folders, with sub cats etc.. here is an example of what they need that fotki and other have.
For example (Equine events I shoot have almost 175 riders) each with photos of course.
First I set up a Equine, then create a folder (eg. Fox Lea Event). SIMPLE stupid on Fotki. Then you go and open up your FTP in this case (Filezilla) a free FTP program. AGAIN very simple, not complicated like smug. Then you log in to your FTP, go to public folders, and navigate to the FOX LEA event. You then right click, and click create directory. I put in rider number, horse name, and hit enter BOOM folder created. You just drag your photos over, then go back up right click and create your directory, takes 10 seconds if that and it's FAST/SIMPLE. IF your files mess up during the upload, it's put into a failed folder. You then go there, highlight them all, and REupload. It's that simple.
Why is it a company that already charges too much (150.00, PLUS on your files) where as fotki is only 40 a year.. can't implement simple features. To me, that makes no sense what so ever.
Get it resolved!
Im just starting, where do you get and use FTP uploading information?
In trial version now. If there is no possibility of uploading by FTP, won't purchase it, for sure. Well, there is, but not wanting to pay extra 50$ for the job.
Fernando Scheps Serra commented
Definitely SFTP with our exact galleries structure should be added as an upload way. Thanks!
John Ortt commented
Yet another +1 for this. I am losing count of how many files are failing to upload.
This has already cost Smugmug a lot of users and I will be another if they don't sort it by my next renewal!
I haven't tried SmugFTP because (1) I don't want to pay extra since I'm already paying SmugMug, and (2) I don't want to upload files to a third party (same reason I don't use DropBox or the like).
I have written some Bash shell scripts that I run on the Unix side of my Mac, that upload multiple files. You tell the script all files you want to upload, then it uploads each of them one-by-one using the web API. I wrote the script to grab the IPTC data using the GraphicConverter interface, which means that it works for both pictures and videos. It's slow, and annoying that I have to resort to this.
Ah...I just saw the catch for SmugFTP... after 1 GB you have to pay... oh well, back to the drawing board =(
Wow, I'm so glad I found this post! Thank you because I found SmugFTP, and though I haven't tried it I think it will be exactly what I'm looking for and what you all are talking about.
This may not be exactly the topic, but...honestly, I've been looking everywhere for weeks, downloading apps, writing posts in Digital Grin about batch uploading... nobody answers and I couldn't find any solutions...
I just can't believe that something so basic as uploading your library (especially when you first arrive at SM and have 1000+ albums to upload!) could be made such a complicated thing, through plugs into iPhoto and Aperture that don't really work are too complicated and take too long, or MacDaddy that had no sorting options and doesn't work anymore anyways, or Star Explorer that only works on Windows and doesn't work anymore either... and the guys from SM just push you off to their "third party" page http://help.smugmug.com/customer/portal/articles/84267 ! Are they always so unspecific and brusk?
Anyways, I looked and nothing seems to work for a Mac computer wanting to do multiple-gallery uploads
Can anyone explain to me, who is new to SM, how you can sell people on their wonderful UNLIMITED PHOTOS AND VIDEOS, make them pay, and then when they start looking for ways to upload their library they find out they can only do it... one by one ?! Are any of them photographers? And how many pro and amateur photographers have been uploading albums one by one and for how many years?! This is truly mind-boggling for me.
I understand what one of you said about them being afraid for their disk space, but that doesn't excuse them making this so complicated for their clients. Having said that, let me say that everything else is great. But this is such a deficiency that it discredits them... and I nearly said "ciao".
So anyways, I'm hoping SmugFTP will do the job - thanks Wong Liang Zan !
smugftp.com is an option for those that want FTP uploading now. It's written by an independent developer that I worked with personally to debug. But smugftp isn't native on SM, so there are actually two uploads--one from you to smugftp, and then smugftp to SM. If FTP was native at SM, it would be so much faster!
This is exactly how Exposure Manager implemented their FTP uploading. You would upload to ftp, then in your control panel you can see what you uploaded and transfer that to albums--easy peasy.
smugftp.com has a similar implementation, except that it automatically transfers to a gallery. But smugftp still isn't native like EM's implementation.
Check out smugftp.com and see if this can do what you want until SM builds native FTP capability.
I know! I've been there! I actually have videos that are two years old that I never uploaded. :( F--T--P! F--T--P!
While FTP may be dated, I don't agree that it's poorly designed for uploads. It was built ground-up for file transfers including uploads. Yes, it doesn't have the security of SSH or SSL encryption built-in. Yes, it does require ports open that may not be open on a firewall. Yes, it doesn't have a checksum to verify that a file is bit-for-bit perfect.
But I'm sure that the native SM http transfers aren't highly encrypted, and even if they are not, you can't read the random information that's in an image and gain anything like passwords from it. Other applications also use other ports, and this is still common, so port problems will be minimal. And what use is a checksum if the file never gets there? Even if it gets corrupted a few bits, do you really think that materially alters an image? (I've actually tried experiments on this.) Even with SM's checksums, I've still seen images upload corrupted, so that system has flaws too.
The main issue may be the software 'glue' that a native FTP application would require. But as far as FTP not being directly capable on Amazon S3, you're incorrect. I checked myself as I was considering S3 as a cloud backup, and smugftp.com uses the S3 network for it's services. If a single person can code up a solution, I know SM can.
I agree with you. When I originally posted this idea, I thought I was part of just a small group of SM users, maybe 10%, that wanted this feature. Obviously with it being the #3 top requested feature, it's a lot more of us than I ever imagined. And I know SM hears us. We just have to keep the votes coming in to make FTP a reality! F--T--P! F--T--P!
Thank you for some more insight into the innerds of HTML programming. I thought an HTML uploading implementation had to be tedious to code, but you revealed how complicated that implementation can be when compared to FTP.
I like the KISS model. FTP is simple and pretty stupid--and it works!--day-in day-out for better part of a quarter century now (or maybe even more). Why reinvent the wheel? Use the protocol that's uploaded trillions of files in the last few decades. Yes, there may be hiccups, but those have been documented and have pretty simple fixes as well.
Personally, I'm not too concerned about SFTP at the moment. Images and video are basically just raw digital data (except for possibly the header), and there's nothing in there that can be used maliciously like passwords or bank information. Pure, plain-Jane FTP would be a great place to start since it's a well documented protocol. I highly doubt any issue in development hasn't already had a fix in the last few decades.
I think realistically SFTP (which uses SSH) is the most appropriate mechanism. It's widely supported by tools, is fully cross-platform, it's easy to use in scripts and automation. SSH itself is widely used so there's no question about it already being supported.
Possibly there might be an issue with SSH checking a different account database (e.g., one for admins rather than SmugMug users), but this can be solved in any number of ways, including using an email address for authentication (since it then becomes obvious that it is an end user account and not an admin).
Wolfgang Weisselberg commented
Kieran, unless you are saying that it's impossible to run an FTP server on the Amazon EC2 I don't get your point. Smugmug is already running lots of EC2 instances for such unimportant things like uploading photos, rotating and scaling them. EC2 servers have a direct connection to S3, one of the things SmugMug leverages to deliver the potos when you browse them.
And FTP is not poorly designed at all. It allows you to upload data from computer A (say your home box) to computer B (say Smugmug) using computer C (say, you and your smartphone on the road and only having EDGE or GRPS connectivity and being charged by the kilobyte). What you probably wanted to say is that it was not designed for ease of integration with packet filters. Which wasn't a concern when FTP was designed. Better blame IPv4 for too small an address space: after all, they should have known everything would change, shouldn't they?
It's easy to script an upload to happen via FTP. HTML ... not so. If you're lucky, you don't need to resort to much screen scraping. Uploaders using Flash or HTML5 --- oh, yes, that's real fun.
As to the metadata do you really think a simple HTML uploader does add a file checksum? Which checksum does SmugMug's own "Olde Faithful" add?
As to "more support stuff" ... maybe. Though it seems that every router-firewall has learnded how to handle 2-computer-FTP. After all FTP has been around for a while. And there's no need to advertise FTP heavily. Those that know FTP enough to want it will use it. You may stick to the web interface if you like --- nothing wrong with "the computer doesn't do a thing if I'm not watching it" model if you want it for yourself. But don't force others to endure it if they don't want to.
Ilya P commented
Kieran, *everything* is possible given enough desire! Great overview, but seriously, making it work (S3 or not S3) is not that much harder or "worse" than making email uploads work, lets stop with the excuses already. This request has been out since August 2009 and there are 1,148 votes for it at the moment- it either has enough ROI for SM to do it or it does not.
Kieran Clancy commented
While I can understand the desire for this, FTP is actually a very poorly designed protocol for uploads. It is insecure and causes all sorts of problems with port access.
Some users below said that SFTP is the same but with SSL. This is incorrect; SFTP is based on the SSH protocol, which is much better and more modern, but carries its own issues. FTP with SSL is called FTPS, but is still poorly designed due to port issues.
Also, important metadata such as file checksum can't be sent using FTP, which means the receiving server cannot verify that the file was not corrupted during upload.
I believe the main issue is that Amazon S3 doesn't support FTP uploads. For Smugmug to do FTP uploads then, they would need to pay for extra bandwidth and hardware so that you can upload to their own servers before that is then sent to Amazon S3. Plus they would have to pay for more support staff because many users would have firewall problems because of the poor design of the FTP protocol.
Absolutely necessary. Uploading to SM is driving me CRAZY!!!
Fernando M commented
Need it, would like to upload to my local NAS and it could FTP files overnight to my smugmug site using FTP. This would be great automation.
if you have problem coding the complex ftp feature.
why not have a temp ftp directory for each user where all files will be ftp-ed there, then from the control panel, we will move select photos into the specific album.
Slava V. commented
FTP very useful when the upload aborted by any reason (I am trying to upload 2Gb video file for days already using HTML5 and Flash uploader and it gets aborted at different stages) - FTP will allow to resume the upload.
This also should will save much incoming traffic for smugmug...
I can very sophisticated FTP client (smugmug needs invest 0 USD in developing one) to manage my uploads including options like scheduling etc.
Anyhow bring us FTP, while uploading images with HTTP works fine the same is not true for large video files.
Now number 3 on the top 10 requests! :o I never knew so many people wanted ftp. Lets push this idea all the way to the top! F--T--P!! F--T--P!!
James, have you checked out smugftp.com? It's almost exactly what you describe as a quick way to get files into smugmug via ftp. :)
Interesting note on ftps--I only knew about sftp. If there's enough demand for *two* versions of secure ftp, there's enough demand for ftp at smugmug. F--T--P! F--T--P!
+3 for this option
Common Heroes, you can do it!
This option would make our workflow much easier. It's too bad they don't seem to want to give their paying customers a method to make their lives happier.
It doesn't even need to be instant, for me at least. It could work like Scene7 where files are uploaded to an intermediate server (FTP), a scheduled process picks up the files, processes them, then makes them available. (Optional) A report is emailed (DM tweet?) out when the batch process is completed.
My only idea of why they wouldn't make FTP available is because they really don't want to give us an easy method of bulk uploading. Could be due to worries of us sucking up all their disk space.
@Samir, you might be thinking of ftps, not sftp. They are actually two different ways to achieve a secure FTP connection. SFTP is SSH FTP and FTPS is basically FTP using SSL/TLS...back to our chant: F--T--P!!! F--T--P!!! F--T--P!!!
Somewhere in these comments (a few years ago, I think), someone from SM commented on how FTP will NEVER happen. There wasn't much of an explanation except that it wasn't something they were planning on doing.
Oddly enough, Zenfolio also has a similar request on their feedback site with similar resistance from Zen:
Let the masses cry out! F--T--P!!! F--T--P!!! F--T--P!!!
Sheer numbers will force a change. I never in a million years dreamed my suggestion would become the top 4 thing SM users want. Let's keep it going to number one!