Haha, the infamous button mystery solved by Paul. I never saw that one comment. But you're right. He did say it.
There certainly was a button. It simply said "Migrate" if I remember right. It was visible right within the first "NewsFlash" or whatever on my Legacy Homepage the first day the New Smug was available. First you could read about it, then you could literally hit the button that said "Migrate". That's why so many people were saying they'd hit the button or they were terrified to hit the button. It wasn't a metaphor. I wouldn't know where to find that anymore either, now that I've already read the NewsFlash, because it disappears from your homepage once you've read or dismissed it. Those NewsFlashes usually are still visible on Homepage "Tools" somewhere but it sounds like the infamous button itself disappeared when migrations were paused, and maybe will never again be seen in its original form.
Honestly though, no one should have to go digging when migrations are possible again. Just put another NewsFlash on people's homepage & give them the info & the link. Shouldn't need to dig around here in a "SmugMug Update from Baldy" thread to find out how/when/where to migrate! Even Zac's " /migrate " suggestion... that doesn't tell the average site-owner anything. I myself have no clue what to put in there! Show people! Tell people!
This is a legacy policy and what it took to recruit labs like Bay Photo, because they didn't want a flood of consumer orders, which was more the domain of Shutterfly, whose color correction is by machine and not by humans.
Yes, I believe that they could create a fix for that at the moment. However, fixing and retesting all those APIs would be a large project. It'd be a huge investment of developer time for a feature that only a tiny fraction of their customer-base is going to use, and from what I can tell they're already hoping to eliminate ad-hoc JavaScript development.
They'll probably take the direction of manually reviewing and approving JavaScript customisations instead, which would be significantly less work than fixing the security.
Actually, we did invest in a huge re-write of our API, and things like the new organizer are built upon it. We're spending a lot of time moving most other functions to it because it has a stronger security model and bunch of other stuff. In time, when we get done dogfooding it, we'll want to move all third party products to it.
But even with that effort, around 60 days before launch we decided that the JavaScript block could not make it in this release due to many concerns, some of which we've talked about here. We haven't given up, but we're a lot more sober about what it takes than we were before.
Actually, we did invest in a huge re-write of our API, and things like the new organizer are built upon it. We're spending a lot of time moving most other functions to it because it has a stronger security model and bunch of other stuff. In time, when we get done dogfooding it, we'll want to move all third party products to it.
But even with that effort, around 60 days before launch we decided that the JavaScript block could not make it in this release due to many concerns, some of which we've talked about here. We haven't given up, but we're a lot more sober about what it takes than we were before.
Is the new API (that covers new SM) released for our use? If so, I haven't been able to find it. Other developers with similar requests/confusion: http://www.dgrin.com/showthread.php?t=236580
With all due respect, Baldy, your QA guys can't guarantee any changes won't break something even without JavaScript. Many recent "fixes" have made things better for some but worse for others.
Yes, but imagine the added complexity our heroes face when someone writes help and says their site broke. It's one thing for them to troubleshoot HTML and CSS, quite another to debug JavaScript that was copied and pasted from somewhere on the net with the person doing the pasting being unfamiliar with JavaScript.
What I'm seeing here, on the unrepresentative microcosm of dgrin (and to a certain extent on G+), is a few customers arguing for its inclusion, a whole host of customers not really caring either way, and a few customers saying "this is why it might not be as easy as you like to add Javascript". Not really seeing anyone up in arms with concerns about it possibly being included in future. Of course, I see far fewer customers opinions on it than Smugmug does!
That's pretty much what we see too, except that life as a software company means we get emails from security firms or really bright engineers telling us of a vulnerability we didn't think of. It happens to all companies. They're kind enough to not make them public, at least until we've been able to patch them.
The thing is, we have so many things to do that almost everyone wants relating to commerce, comments, yada, and so we have to trade off investing a lot of engineering into one versus another. BTW, Brad Clawsie here is digging into the 301 redirect problem.
And finally, I think everyone wants security, they just don't know to talk about it.
... because a button to migrate (or upgrade, or change) is a logical and expected visual element to have on the website that announces a migration step. The button was supposed to be ON THE USER'S WEBPAGE the moment the user signs in or in the user's Account Settings. To have the link posted in the forum, or in the help pages area - is a very un-intuitive, user unfriendly, backward approach. Yes, it didn't take me too long to find the link. I actually had to ask this question in this forum:) So, it didn't take too much of my time. But I am still, up until this day puzzled how come the button or the link or any other visual element was not present loud and clear on my website as I signed in after the migration was announced.
It was there for a week but caused tens of thousands of migrations and we couldn't handle the volume, so we removed it. Sorry for the confusion.
It would be enlightening to know what SmugMugs vision/mission statement is...
The vision hasn't changed, it's still to provide customizable photo websites. The execution has changed to make it easier.
I used to work at NeXT, where Steve Jobs landed after leaving Apple. We licensed FreeBSD and thought we were doing the best thing you could do for UNIX: adding a GUI to make it easier. But it was hotly debated because so many UNIX experts thought we were ruining UNIX, making a pig of it for the sake of grandmas, making the command line hard to find.
When Apple bought NeXT, NeXTstep became OS X. And the transition to OS X was painful because apps written for OS 9 wouldn't run on OS X and vice versa. Consider customers like Stanford, who had 20,000 OS 9 installs....
But OS X had the better security model, it scaled better, apps written for it were prettier and could do more. And it drove Apple's Renaissance. And now a derivative of it powers your iPhone.
The vision hasn't changed, it's still to provide customizable photo websites. The execution has changed to make it easier.
I used to work at NeXT, where Steve Jobs landed after leaving Apple. We licensed FreeBSD and thought we were doing the best thing you could do for UNIX: adding a GUI to make it easier. But it was hotly debated because so many UNIX experts thought we were ruining UNIX, making a pig of it for the sake of grandmas, making the command line hard to find.
When Apple bought NeXT, NeXTstep became OS X. And the transition to OS X was painful because apps written for OS 9 wouldn't run on OS X and vice versa. Consider customers like Stanford, who had 20,000 OS 9 installs....
But OS X had the better security model, it scaled better, apps written for it were prettier and could do more. And it drove Apple's Renaissance. And now a derivative of it powers your iPhone.
That's all we're trying to do here.
...and developers could create software that worked in osx. Smugmug is my web operating system and I just lost the ability to install new applications. I just want to add some simple JavaScript for a non supported analytics tool. I've been paying to use that tool since before smugmug existed, and I don't want to stop now. We need a way... waiting for my feature to win the uservoice popularity contest isn't the right way to go. I know it'll never happen if that's my only option. And that's my one little feature preventing me from unveiling my new site. I don't know the right answer but there has to be another solution than just eliminating JavaScript.
Yes, but imagine the added complexity our heroes face when someone writes help and says their site broke. It's one thing for them to troubleshoot HTML and CSS, quite another to debug JavaScript that was copied and pasted from somewhere on the net with the person doing the pasting being unfamiliar with JavaScript.
As I've posted elsewhere on Dgrin, I don't understand why Smugmug feels obligated to support (in the troubleshooting sense of the word) JavaScript, or, for that matter, HTML and CSS. There's a clear distinction between what Smugmug provides vs. what Smugmug allows.
It is obviously expected that Smugmug would provide support to its customers for the core functionality and usability of its product. But I have certainly never expected support for the various HTML, CSS, and JavaScript coding that I have used to customize my site above and beyond the embedded wherewithal provided by Smugmug. And I've never bothered Smugmug's helpdesk with those matters. I was under the impression that's what Dgrin is for.
The help with coding that has been sometimes provided by Smugmug Support Heroes on Dgrin has always been appreciated, but I've never construed it to be obligatory.
Why not put a disclaimer of sorts on HTML, CSS, and, eventually (hopefully), JavaScript blocks, with words to the effect that "Smugmug is happy to provide our customers with these advanced code blocks that can facilitate site customizations beyond the many awesome tools we already provide. But be aware that the use of these code blocks are at your own risk and any code applied therein will not be directly supported by Smugmug Support Staff. Also be advised that any of your existing coding may break if and when Smugmug makes necessary changes to our own core code. See the Customization Support Forum on Dgrin for help and support with advanced coding."
Seems like such a policy would free up Smug's support staff to focus more concisely on matters directly related to core product functionality and relieve them from having to troubleshoot customers' own code that's riddled with typos.
The vision hasn't changed, it's still to provide customizable photo websites. The execution has changed to make it easier.
Ah but for whom? Everybody, from those that want somewhere other than Facebook to store their phone snaps, right up to high-end pros cranking out large numbers of photos, and having specific requirements for delivery and display of those photos to clients? Or a particular section of the market?
And now a derivative of it powers your iPhone.
most likely the same people asking to have more control over their websites shunned Apple's nanny approach ages ago and switched to Android I don't want iPhotoHosting
The vision hasn't changed, it's still to provide customizable photo websites. The execution has changed to make it easier.
I used to work at NeXT, where Steve Jobs landed after leaving Apple. We licensed FreeBSD and thought we were doing the best thing you could do for UNIX: adding a GUI to make it easier. But it was hotly debated because so many UNIX experts thought we were ruining UNIX, making a pig of it for the sake of grandmas, making the command line hard to find.
When Apple bought NeXT, NeXTstep became OS X. And the transition to OS X was painful because apps written for OS 9 wouldn't run on OS X and vice versa. Consider customers like Stanford, who had 20,000 OS 9 installs....
But OS X had the better security model, it scaled better, apps written for it were prettier and could do more. And it drove Apple's Renaissance. And now a derivative of it powers your iPhone.
That's all we're trying to do here.
Smugmug isn't Apple, nor should it try to be.
Smugmug's core constituency are photographers, and it is the needs of photographers alone that should be the focus of Smugmug's design and engineering.
To stay with you analogy, Smug's new release may be far more secure (a very good thing!) and it may be much prettier (also a good thing!) but the net sum of this release is that I can do less, not more, with it than with your prior release.
I don't recall that ever being the case with Apple.
... but the net sum of this release is that I can do less, not more, with it than with your prior release....
This is very well said, sir! Absolutely agree with this: New SM is much prettier, perhaps more secure (what do I know?:) ), much easier to create a basic site for a regular user.... but it is SO MUCH MORE LIMITED than previous version...
SmugMug - at the end you will get what you are asking for - your user base will change, you will get less demanding, simpler crowd. Majority of your new client-base will not care about quality of the prints but will care about the (cheap) price. At some point you will not be able to justify charging what you are charging now to your new client-base because they will not appreciate the quality you used to provide. They will eventually run to the first competitor who offers 10 cents less than you. You will lose big time down the road. Unfortunately it is a prediction that is hard to take or accept, but don't dismiss it without giving a lot of thoughts about it.
case sensitive resolution?
I've tried to dig through all the posts, so I apologize if I missed it or if there is somewhere better to look (I'm happy to hear if there is somewhere easy I should be checking to see any updates on this issue- maybe smugmug.com/StillCaseSensitivE ).
Has there been a final decision or resolution of the issue of case sensitive URLs? Even a "no, it won't be fixed" would be helpful so I can start packing my boxes.
0
Options
BaldyRegistered Users, Super ModeratorsPosts: 2,853moderator
Yeah, I wasn't aware of this issue before we went live and it has taken me awhile to mostly understand it. A wedding pro wrote into the heroes saying she had printed 800 handouts that had an URL with /wedding in it and we produced a 404 page unless it was /Wedding. Ouch.
I think we have a 99.9% use case solution in the works, which is to redirect when no conflict with one of our system pages is detected, which is what we do on SmugMug Legacy today. That will fix the case, for example, of the wedding pro's handouts.
What's less obvious to me is what to do on system pages SmugMug uses today, such as /signup and /pro. I am aware of a use case where a pro printed collateral with /signup on it and was surprised to find out it went to our signup form. I think with the solution we're working on, we can avoid 99.9% of the use cases we're seeing, but for system pages like /signup I'm not aware that we have figured out a solution (this is the part of the problem that's not new; it has existed on legacy for years too).
We're really sorry for the problems this has been causing in the meantime.
Also looking for an update on the case sensitivity problem. It has been a long time since an update, I thought I was being patient, but perhaps just foolish. Time to renew my search for alternatives, just in case..
Also looking for an update on the case sensitivity problem. It has been a long time since an update, I thought I was being patient, but perhaps just foolish. Time to renew my search for alternatives, just in case..
Can you give me a specific example of it not working, please?
Is there any news on case-sensitive URLs? I have lots of old links out there that go to lower-case URLs. ex: http://www.benjamindbloom.com/stowederby I'd really like to continue to use SmugMug, but the fact that the URLs are case sensitive and require uppercase characters is really frustrating.
Is there any news on case-sensitive URLs? I have lots of old links out there that go to lower-case URLs. ex: http://www.benjamindbloom.com/stowederby I'd really like to continue to use SmugMug, but the fact that the URLs are case sensitive and require uppercase characters is really frustrating.
If I had one request to fix with a magic wand, this would be it. (If I had two, JavaScript would be the other!)
Thanks.
Hi, the issue here is not the first letter of your URL, but rather the capital D. Change the URL to be Stowederby and you should be fine. There are numerous cases where customers want intercapping to be enforced. We try to gracefully handle that first letter by trying the uppercase version if the lowercase one fails, but the same method can't be used for every single letter in the URL. It simply wouldn't scale with all the possible combinations.
Hi, the issue here is not the first letter of your URL, but rather the capital D. Change the URL to be Stowederby and you should be fine. There are numerous cases where customers want intercapping to be enforced. We try to gracefully handle that first letter by trying the uppercase version if the lowercase one fails, but the same method can't be used for every single letter in the URL. It simply wouldn't scale with all the possible combinations.
Hi, the issue here is not the first letter of your URL, but rather the capital D. Change the URL to be Stowederby and you should be fine. There are numerous cases where customers want intercapping to be enforced. We try to gracefully handle that first letter by trying the uppercase version if the lowercase one fails, but the same method can't be used for every single letter in the URL. It simply wouldn't scale with all the possible combinations.
Hi Sheaf - I appreciate the reply, but the issue is not just the capital D. The links that have been shared in past years are all lowercase, so having a forced uppercase S is a problem. It's exactly the same as the wedding photographer that printed hundreds of flyers with site.com/wedding only to find that they had to go to site.com/Wedding.
In a quick survey of people I asked, people who saw a case sensitive URL on a flyer would not necessarily key it in with matching case. Thus, even if site.com/Wedding had been printed on flyers, end users would have entered /wedding.
Hi Sheaf - I appreciate the reply, but the issue is not just the capital D. The links that have been shared in past years are all lowercase, so having a forced uppercase S is a problem. It's exactly the same as the wedding photographer that printed hundreds of flyers with site.com/wedding only to find that they had to go to site.com/Wedding.
In a quick survey of people I asked, people who saw a case sensitive URL on a flyer would not necessarily key it in with matching case. Thus, even if site.com/Wedding had been printed on flyers, end users would have entered /wedding.
I'm sorry, but that's no longer the case and hasn't been for quite a while.
You need to start it with a capital letter like it says. If someone types it in lowercase, we will automatically direct it to the correct capitalized URL.
You need to start it with a capital letter like it says. If someone types it in lowercase, we will automatically direct it to the correct capitalized URL.
Comments
Haha, the infamous button mystery solved by Paul.
My Smugmug Gallery
There is no button now because migrations are paused until the 27th. A button may or may not appear in the future
Just use /migration link.
Support Hero
Honestly though, no one should have to go digging when migrations are possible again. Just put another NewsFlash on people's homepage & give them the info & the link. Shouldn't need to dig around here in a "SmugMug Update from Baldy" thread to find out how/when/where to migrate! Even Zac's " /migrate " suggestion... that doesn't tell the average site-owner anything. I myself have no clue what to put in there! Show people! Tell people!
DayBreak, my Folk Music Group (some free mp3s!) http://daybreakfolk.com
But even with that effort, around 60 days before launch we decided that the JavaScript block could not make it in this release due to many concerns, some of which we've talked about here. We haven't given up, but we're a lot more sober about what it takes than we were before.
Homepage • Popular
JFriend's javascript customizations • Secrets for getting fast answers on Dgrin
Always include a link to your site when posting a question
The thing is, we have so many things to do that almost everyone wants relating to commerce, comments, yada, and so we have to trade off investing a lot of engineering into one versus another. BTW, Brad Clawsie here is digging into the 301 redirect problem.
And finally, I think everyone wants security, they just don't know to talk about it.
I used to work at NeXT, where Steve Jobs landed after leaving Apple. We licensed FreeBSD and thought we were doing the best thing you could do for UNIX: adding a GUI to make it easier. But it was hotly debated because so many UNIX experts thought we were ruining UNIX, making a pig of it for the sake of grandmas, making the command line hard to find.
When Apple bought NeXT, NeXTstep became OS X. And the transition to OS X was painful because apps written for OS 9 wouldn't run on OS X and vice versa. Consider customers like Stanford, who had 20,000 OS 9 installs....
But OS X had the better security model, it scaled better, apps written for it were prettier and could do more. And it drove Apple's Renaissance. And now a derivative of it powers your iPhone.
That's all we're trying to do here.
...and developers could create software that worked in osx. Smugmug is my web operating system and I just lost the ability to install new applications. I just want to add some simple JavaScript for a non supported analytics tool. I've been paying to use that tool since before smugmug existed, and I don't want to stop now. We need a way... waiting for my feature to win the uservoice popularity contest isn't the right way to go. I know it'll never happen if that's my only option. And that's my one little feature preventing me from unveiling my new site. I don't know the right answer but there has to be another solution than just eliminating JavaScript.
Dave
As I've posted elsewhere on Dgrin, I don't understand why Smugmug feels obligated to support (in the troubleshooting sense of the word) JavaScript, or, for that matter, HTML and CSS. There's a clear distinction between what Smugmug provides vs. what Smugmug allows.
It is obviously expected that Smugmug would provide support to its customers for the core functionality and usability of its product. But I have certainly never expected support for the various HTML, CSS, and JavaScript coding that I have used to customize my site above and beyond the embedded wherewithal provided by Smugmug. And I've never bothered Smugmug's helpdesk with those matters. I was under the impression that's what Dgrin is for.
The help with coding that has been sometimes provided by Smugmug Support Heroes on Dgrin has always been appreciated, but I've never construed it to be obligatory.
Why not put a disclaimer of sorts on HTML, CSS, and, eventually (hopefully), JavaScript blocks, with words to the effect that "Smugmug is happy to provide our customers with these advanced code blocks that can facilitate site customizations beyond the many awesome tools we already provide. But be aware that the use of these code blocks are at your own risk and any code applied therein will not be directly supported by Smugmug Support Staff. Also be advised that any of your existing coding may break if and when Smugmug makes necessary changes to our own core code. See the Customization Support Forum on Dgrin for help and support with advanced coding."
Seems like such a policy would free up Smug's support staff to focus more concisely on matters directly related to core product functionality and relieve them from having to troubleshoot customers' own code that's riddled with typos.
www.djdigitaldave.net
Ah but for whom? Everybody, from those that want somewhere other than Facebook to store their phone snaps, right up to high-end pros cranking out large numbers of photos, and having specific requirements for delivery and display of those photos to clients? Or a particular section of the market?
most likely the same people asking to have more control over their websites shunned Apple's nanny approach ages ago and switched to Android
Smugmug isn't Apple, nor should it try to be.
Smugmug's core constituency are photographers, and it is the needs of photographers alone that should be the focus of Smugmug's design and engineering.
To stay with you analogy, Smug's new release may be far more secure (a very good thing!) and it may be much prettier (also a good thing!) but the net sum of this release is that I can do less, not more, with it than with your prior release.
I don't recall that ever being the case with Apple.
www.djdigitaldave.net
This is very well said, sir! Absolutely agree with this: New SM is much prettier, perhaps more secure (what do I know?:) ), much easier to create a basic site for a regular user.... but it is SO MUCH MORE LIMITED than previous version...
SmugMug - at the end you will get what you are asking for - your user base will change, you will get less demanding, simpler crowd. Majority of your new client-base will not care about quality of the prints but will care about the (cheap) price. At some point you will not be able to justify charging what you are charging now to your new client-base because they will not appreciate the quality you used to provide. They will eventually run to the first competitor who offers 10 cents less than you. You will lose big time down the road. Unfortunately it is a prediction that is hard to take or accept, but don't dismiss it without giving a lot of thoughts about it.
I've tried to dig through all the posts, so I apologize if I missed it or if there is somewhere better to look (I'm happy to hear if there is somewhere easy I should be checking to see any updates on this issue- maybe smugmug.com/StillCaseSensitivE
Has there been a final decision or resolution of the issue of case sensitive URLs? Even a "no, it won't be fixed" would be helpful so I can start packing my boxes.
The short story is easy to do but there are downsides. I posted in this thread
http://www.dgrin.com/showthread.php?p=1905484
and we can debate the plusses and minuses there.
Thanks,
Baldy
Any update here?
Also looking for an update on the case sensitivity problem. It has been a long time since an update, I thought I was being patient, but perhaps just foolish. Time to renew my search for alternatives, just in case..
Can you give me a specific example of it not working, please?
Bulk Edit Keywords
My Website index | My Blog
In my ideal world, www.benjamindbloom.com/stowederby, www.benjamindbloom.com/StoweDerby and www.benjamindbloom.com/STOWEDERBY would all behave the same way. Why? Because users have been conditioned that URL paths are not case sensitive.
If I had one request to fix with a magic wand, this would be it. (If I had two, JavaScript would be the other!)
Thanks.
Hi, the issue here is not the first letter of your URL, but rather the capital D. Change the URL to be Stowederby and you should be fine. There are numerous cases where customers want intercapping to be enforced. We try to gracefully handle that first letter by trying the uppercase version if the lowercase one fails, but the same method can't be used for every single letter in the URL. It simply wouldn't scale with all the possible combinations.
Can you, please, share those reason with us?
Hi Sheaf - I appreciate the reply, but the issue is not just the capital D. The links that have been shared in past years are all lowercase, so having a forced uppercase S is a problem. It's exactly the same as the wedding photographer that printed hundreds of flyers with site.com/wedding only to find that they had to go to site.com/Wedding.
In a quick survey of people I asked, people who saw a case sensitive URL on a flyer would not necessarily key it in with matching case. Thus, even if site.com/Wedding had been printed on flyers, end users would have entered /wedding.
I'm sorry, but that's no longer the case and hasn't been for quite a while.
http://sheaf.smugmug.com/Wedding
http://sheaf.smugmug.com/wedding
Do you have an example of it not working?
I'm glad to hear it. How do I get my Stowe Derby example to allow lowercase? Every time I've tried, it rejects my lowercase s as a starting character.
No dice: http://www.benjamindbloom.com/stowederby throws a 404.
Is this a difference between a page and a category/folder?
Ah - a bit more fiddling and now I get it. Now I see the D issue that you brought up. Thanks.
Where should I have found out about this? I was searching for days..