I was about 30 minutes off going live tonight, before I was alerted to the fact that the workaround customers had been using to embed wufoo contact forms on their site has been 'fixed' without warning (http://dgrin.com/showthread.php?p=1890993).
I'm sorry that happened to you, Paul. Unfortunately, we have to pay much closer attention to security than ever before, so this is something we had to close off quickly before anyone else started to use it.
I'm sorry that happened to you, Paul. Unfortunately, we have to pay much closer attention to security than ever before, so this is something we had to close off quickly before anyone else started to use it.
Out of interest, what were/are the actual JS security risks? I'm hoping it's not just some variant of "Won't someone think of the children" argument where a buzzword is said thereby shutting down any rational conversation or understanding of the issue. I guess it's like "Terrorism" - use that as the justification and no-one bothers to ask any more questions.
I ask because it's strange that after many years of JS being on the site - all of a sudden it's too risky to leave there for a few more hours/days to alert people?
Now, if it's a case of "We're strictly enforcing our current no JS policy for now unless you are an authorised customiser and that's just the way it is now", then that's fine (Well, it sucks really, but at least it's honest :-)
Since it's all shut down now - what security issues have been fixed please?
Actually curious to know since JS is going to remain working on the old Smugmug for many months.
looking at some responses to other issues, its obvious changing security needs have had to play a significant part in the development of SM
(and not just javascript - e.g. hiding gallery passwords from site owners - http://www.dgrin.com/showthread.php?t=237564).
Don't suppose you can elaborate further on this? (I'm guessing not, but thought I'd ask! )
I think what's hard to understand for many people who had heavily customized sites on Legacy SmugMug was how ineffective the system was for others. The vast majority of SmugMug customers a month ago had little or no customization. We browsed through thousands of them. Their sites were relatively bland and out of date. If you paid a customizer hundreds of dollars or had knowledge of CSS/HTML and had time to customize, you could get a nice-looking site. But otherwise you were out of luck.
This can be represented by a bell curve. A bell curve is a graphical representation of how things (in this case high quality SmugMug sites) are distributed in a population. The reason that a standard distribution looks like this is, to put it simply, is that individuals within a population possess "valuable attributes" (coding skills, free time, etc.) in varying degrees. To put it another way, outstanding abilities, or in this case outstanding websites, are such due to their scarcity (somewhere between 2% and 16%). If a majority of people can achieve the goal (here represented in green) then it falls into the yellow section of the graph which by definition is considered average.
It was an absolutely agonizing decision for us to make, to blow away old customization and make people start over. Many of our very best and most loyal customers had spent long hours tinkering on their site to get it looking just right. It was also very, very difficult for us to rebuild everything from the ground up. I have never been involved with anything in my professional career that was so complicated and challenging.
What you have really accomplished here, with the removal of the more powerful customization tools (java script, etc.) is to artificially force those SmugMug sites that had distinguished themselves from the pack into the yellow section of the graph, which will for a brief time skew the curve. Which is ironic since, by your own admission, your very best and most loyal customers were falling into the green section of the graph.
But artificial external influences (famine, disease, war, SmugMug updates ) are invariably corrected and the graph returns to "normal" due to the fact that "valuable attributes" remain in the population to varying degrees. There will always be the small group (2%) of people that "stay ahead of the curve" as they are driven individuals who are determined to be successful.
Our main goal for over a decade has been quite simple: build the best possible tools for passionate photographers to display, share, and sell their photos. But the old system simply made it too difficult for most to get a beautiful site. We were failing our customers.
This really isn't true.(And I'm not pointing fingers here.) The customers were really failing themselves by not grabbing hold of the opportunity to excel that customizations provided. (Or perhaps they were satisfied with their sites and felt no need). And it is simply not possible. Most people cannot have a beautiful (Goal) site. Most people will have an average site, approximately 68% of them in fact, 82% if you include the "below average" sites. The only real failure was in denying those who fell into the green portion of the graph the ability to further customize their sites. (ie. self fulfillment, foreign currency, and various other issues). This failure has not been remedied, in fact it has been made worse.
It has been both rewarding and depressing to see the responses over the past week. Thousands of people who were stuck with the legacy default now have dramatically improved sites. On average, SmugMug sites are considerably more beautiful than they were before.
It is depressing, and, well actually mathematically impossible because you are beating your head against a paradox, a battle which no mortal can win. In point of fact, on average, the average SmugMug website is, well, average, just like it was before and always will be. The reward that you think you are feeling is simply a function of the artificial skew in the graph created by the update that has temporarily caused some to think that their sites have reached the "Goal". This will correct shortly as the "green" 16% break away from the pack once again with unanticipated customizations, hacks, and workarounds.
But some people who had spent long hours customizing are understandably frustrated. I just hope you'll give us a chance to continue to improve things and move the platform along.
That is because we all desire to be "exceptional", but only some are willing to put in the time and work to make it so. They are in fact the "exception". You just created more work for those who were already working hard. You pushed 14% of the people who had "reached the goal" of an outstanding website into the average category. And as for those that weren't working very hard in the first place with the legacy SmugMug (no time, no willingness to customize or learn how to customize, etc.) represented in the red portion of the graph, well I think we all know how those sites look already, very cookie cutter.
Don't you intuitively know this to be true? Are you getting complaints from somewhere around 8-15% of the customer base?
I'm just sayin', if your trying to make the average site above average, well...
good stuff Dreadnote, and its not often I see bell-curves on dgrin. However what you seem to have not mentioned is that people (and their potential clients) aren't measuring their sites vs other smugmug sites, but against other photography sites. If smug can move/drag the average customer from right in the middle to closer to the goal, thats of benefit to both Smugmug and their customers.
Anyway, I plan on staying in the Green. Might even launch today....
good stuff Dreadnote, and its not often I see bell-curves on dgrin. However what you seem to have not mentioned is that people (and their potential clients) aren't measuring their sites vs other smugmug sites, but against other photography sites. If smug can move/drag the average customer from right in the middle to closer to the goal, thats of benefit to both Smugmug and their customers.
Anyway, I plan on staying in the Green. Might even launch today....
Can't wait to see it Paul! Let me know when it's ready.
I also liked the Bell Curve....even though the numbers and percentages made my head explode.
If a majority of people can achieve the goal (here represented in green) then it falls into the yellow section of the graph which by definition is considered average.
I'm just sayin', if your trying to make the average site above average, well...
I think every site on SmugMug can be beautiful. They can be well above the average for the internet and for other photography sites. That's why I go to work every day. If I didn't believe that and if I didn't work on that, I might as well find another job.
That doesn't preclude the possibility of having exceptional sites on SmugMug's platform. As we have said, we're working on the JavaScript problem. It's certainly not about trying to limit your creativity or purposely handicapping people to make it "fair".
Ideally though, the exceptional sites on the new SmugMug wouldn't be limited to people with a deep knowledge of CSS, HTML, and JavaScript. We need to provide the tools for anyone to easily add things like Statcounter.
good stuff Dreadnote, and its not often I see bell-curves on dgrin. However what you seem to have not mentioned is that people (and their potential clients) aren't measuring their sites vs other smugmug sites, but against other photography sites. If smug can move/drag the average customer from right in the middle to closer to the goal, thats of benefit to both Smugmug and their customers.
Anyway, I plan on staying in the Green. Might even launch today....
Sorry, I should have specified that the original premise and the basis of my continuing SmugMug subscription is that SmugMug leans to the right of the curve when compared with photo hosting platforms in general. This however, is/was largely due to the "advanced customizations" that were possible with the legacy platform. Therefore the above post is in reference to SmugMug sites as a representative of those "leading the pack" so to speak.
As far as people not "measuring their sites vs. other SmugMug sites, but against other photography sites," this is not necessarily true. They are perhaps not knowingly doing so, but they are comparing you to dozens, perhaps hundreds of other photographers in your area of operation, many of whom are, with SmugMug's many thousands of customers, using SmugMug as their platform. I seriously doubt that your paying customer cares who hosts your photos so long as you have a great product and have distinguished yourself from the crowd.
Ideally though, the exceptional sites on the new SmugMug wouldn't be limited to people with a deep knowledge of CSS, HTML, and JavaScript. We need to provide the tools for anyone to easily add things like Statcounter.
Yes, that would be ideal. I'll keep an eye open for rainbows and unicorn poop, which I hear are vital ingredients for an ideal world. But in the mean time please keep us updated with respect to the progress you are making with the JS implementation.
I think that you will find that your customer base is a lot less irritated with a 'longish' wait then they are with a lack of communication and documentation.
"For having lived long, I have experienced many instances of being obliged, by better information or fuller consideration, to change opinions, even on important subjects, which I once thought right but found to be otherwise" - Benjamin Franklin
Nice set of posts, Dreadnote. Interesting take at the situation.
Since Baldy and Sheaf are active in this thread, I'm hoping that one or both could answer a few questions.
1) Is it true that all lowercase URLs (at least the part after the domain name) will no longer be valid? So www.mysite.com\myphotos will not be a valid URL - only www.mysite.com\Myphotos? It is really hard for me to believe that Smugmug is willing to break potentially thousands of existing links due to a lazy, poorly thought out decision.
2) The idea of the site being rewritten from the ground up sounds like it's going to make updates/enhancements a lot easier on your side. I'm wondering if the shopping cart was included in this total rewrite or if it's still the old code, making updates/enhancements as difficult as before?
3) It doesn't seem like anything has changed with the cart/coupons/packages - is this the case?
Nice set of posts, Dreadnote. Interesting take at the situation.
Since Baldy and Sheaf are active in this thread, I'm hoping that one or both could answer a few questions.
1) Is it true that all lowercase URLs (at least the part after the domain name) will no longer be valid? So www.mysite.com\myphotos will not be a valid URL - only www.mysite.com\Myphotos? It is really hard for me to believe that Smugmug is willing to break potentially thousands of existing links due to a lazy, poorly thought out decision.
2) The idea of the site being rewritten from the ground up sounds like it's going to make updates/enhancements a lot easier on your side. I'm wondering if the shopping cart was included in this total rewrite or if it's still the old code, making updates/enhancements as difficult as before?
3) It doesn't seem like anything has changed with the cart/coupons/packages - is this the case?
Thank you.
Mike
We're active in a lot of threads, but can't respond to everything.
1) Yes. We need to reserve the space for special pages like /browse, /date/, /keyword/, etc. Some of our URL structures also depend on a lowercase first letter. We did our best to preserve older links, so if there is a problem with any I would love to see specific examples.
2) Not yet.
3) There were a few changes to packages updated as part of this, but the changes happened a month or so ago. For example, the interface for filling a package used to have a terrible filmstrip-style thing at the bottom to choose photos. Now people can simply click to choose photos.
We recognize that these tools are important to people running their businesses off of SmugMug, but we haven't yet made significant improvements to them.
We're active in a lot of threads, but can't respond to everything.
I know you are - I wasn't intending for that to be a snarky comment - more of a "this seems like a good place to post this" thing. Sorry if it came across otherwise. And thanks for the quick response.
1) Yes. We need to reserve the space for special pages like /browse, /date/, /keyword/, etc. Some of our URL structures also depend on a lowercase first letter. We did our best to preserve older links, so if there is a problem with any I would love to see specific examples.
I don't have specific examples of broken links, but I saw a thread about this. Can't find it at the moment. I help manage a site for a high school track/cross country team (we have not converted, so this isn't a direct issue for us yet.) It has been a common thing to tell someone "photos will be at oursite.com slash mason5k". Or the URL could be typed by someone to be emailed or texted. There are many possibilities for this to be an issue.
I don't see a case where you'd ever need mysite.com/browse or mysite.com/date, but if you say it's possible I'm sure it is. It just seems like reserving your keywords - preventing sub categories or galleries from being called "browse" or "date" would be easier than breaking all urls that are entered with a lowercase first letter.
I guess time will tell how much of an issue this is going to be.
3) There were a few changes to packages updated as part of this, but the changes happened a month or so ago. For example, the interface for filling a package used to have a terrible filmstrip-style thing at the bottom to choose photos. Now people can simply click to choose photos.
I haven't seen the new package fulfillment - I stopped using packages because of the terrible filmstrip-style thing. This is good news.
We recognize that these tools are important to people running their businesses off of SmugMug, but we haven't yet made significant improvements to them.
Yeah - these tools are more important to me than having the latest and greatest site layouts, but it sounds like I'm in the minority here.
I don't see a case where you'd ever need mysite.com/browse or mysite.com/date, but if you say it's possible I'm sure it is. It just seems like reserving your keywords - preventing sub categories or galleries from being called "browse" or "date" would be easier than breaking all urls that are entered with a lowercase first letter.
Except that we don't know what structures we will need in the future. For example, we now use /organize and /customize. We have a few more in planning, but we don't know what we'll need in a few years. The potential collisions in the future can be avoided by restricting the case of the first letter.
Except that we don't know what structures we will need in the future. For example, we now use /organize and /customize. We have a few more in planning, but we don't know what we'll need in a few years. The potential collisions in the future can be avoided by restricting the case of the first letter.
I'm sure it's too late now, but could you trigger on all uppercase? So /ORGANIZE and /CUSTOMIZE would be reserved, but all lowercase - the case that most people will naturally use when they type in a URL - would still be available.
Frankly, I'd rather take the risk of you breaking a link in the future by adding a new keyword that just so happens to be a name of a sub category or gallery or whatever that I've created. Has anyone ever named a gallery "organize"?
Another option would have been to tag all of your keywords with a prefix - sm_organize, sm_date, etc. Then have a rule saying that users can't create any object starting with sm_.
I'm sorry for being critical, but this just doesn't seem to be very well thought out. Using case as a differentiator is seldom a good idea.
0
Options
BaldyRegistered Users, Super ModeratorsPosts: 2,853moderator
Out of interest, what were/are the actual JS security risks?
You're probably noticing by now crickets whenever someone asks a question like that because the first law of security on the Internet is don't talk about security publicly.
The only thing I feel that's responsible to say is we have to continually pay attention to security, more with each passing year.
We met again this morning on the JavaScript question because we continue to work on it, but it looks very much like if we do implement it, and we're trying, it will only run on custom domains. Is that a deal-killer for anyone?
We met again this morning on the JavaScript question because we continue to work on it, but it looks very much like if we do implement it, and we're trying, it will only run on custom domains. Is that a deal-killer for anyone?
I suppose that depends on how quickly you roll out the functionality that people without a custom domain have lost in the new version. The ball's in your court.
You're probably noticing by now crickets whenever someone asks a question like that because the first law of security on the Internet is don't talk about security publicly.
The only thing I feel that's responsible to say is we have to continually pay attention to security, more with each passing year.
We met again this morning on the JavaScript question because we continue to work on it, but it looks very much like if we do implement it, and we're trying, it will only run on custom domains. Is that a deal-killer for anyone?
Only problem with that is, I keep seeing my username.smugmug.com address showing up from time to time instead of automatically changing to my custom domain. Used to be if someone typed username.smugmug.com it would automatically change to customdomain.com. Doesn't seem to do that anymore...
PS - I don't want javascript, I just want Statcounter to work
We met again this morning on the JavaScript question because we continue to work on it, but it looks very much like if we do implement it, and we're trying, it will only run on custom domains. Is that a deal-killer for anyone?
Whereas I won't presume to speak for the masses, I think that is a fair compromise. My guess is that most of the folks interested in JS customizations already have custom domains anyway.
Only problem with that is, I keep seeing my username.smugmug.com address showing up from time to time instead of automatically changing to my custom domain. Used to be if someone typed username.smugmug.com it would automatically change to customdomain.com. Doesn't seem to do that anymore...
PS - I don't want javascript, I just want Statcounter to work
Hmmmm, I will look into that. For as long as I remember, bonocorephotography.smugmug.com always went to that URL, not my custom domain...but I could be wrong.
You're probably noticing by now crickets whenever someone asks a question like that because the first law of security on the Internet is don't talk about security publicly.
The only thing I feel that's responsible to say is we have to continually pay attention to security, more with each passing year.
We met again this morning on the JavaScript question because we continue to work on it, but it looks very much like if we do implement it, and we're trying, it will only run on custom domains. Is that a deal-killer for anyone?
I have a custom domain, so it won't affect me if it's like that.
Of course, the only reason I need JS back is to have my Adsense ad back on my page. I don't even need scripting, and it's ludicrous that I'm being stopped, for security reasons, from using the single biggest CPC network known to man... lol. I know a lot of people would abhor the thought of an Adsense ad on their page... but I was making good money from it... far more than my yearly subscription cost. This needs to be allowed again soon, it's really not OK to just take away a major source of income.
Only problem with that is, I keep seeing my username.smugmug.com address showing up from time to time instead of automatically changing to my custom domain. Used to be if someone typed username.smugmug.com it would automatically change to customdomain.com. Doesn't seem to do that anymore...
Hmmmm, I will look into that. For as long as I remember, bonocorephotography.smugmug.com always went to that URL, not my custom domain...but I could be wrong.
If I remember correctly, it was a javascript hack. And a handy one.
re: limiting javascript to custom domains, on a personal level that would suit me nicely. I would have thought though it might make more sense to limit it to an account level (either Power or Portfolio I guess)
Security-wise I'm not sure how a custom domain would make any difference, or necessarily correlate to a higher level of coding experience. It might however, arguably make Smugmug less liable for the content displayed.
You're probably noticing by now crickets whenever someone asks a question like that because the first law of security on the Internet is don't talk about security publicly.
The only thing I feel that's responsible to say is we have to continually pay attention to security, more with each passing year.
We met again this morning on the JavaScript question because we continue to work on it, but it looks very much like if we do implement it, and we're trying, it will only run on custom domains. Is that a deal-killer for anyone?
Perfect... at least for me it is perfect. Custom domain it is...
0
Options
BaldyRegistered Users, Super ModeratorsPosts: 2,853moderator
I suppose that depends on how quickly you roll out the functionality that people without a custom domain have lost in the new version. The ball's in your court.
So the thing is, and I know it's hard to see this perspective by just reading dgrin, the vast majority never had the functionality of statcounter and the rest because they were unwilling or unable to go to dgrin and install JavaScript on their sites.
So it's the right thing to do to make that functionality built-in not just from a security perspective, but also for the masses. We're working on them and many of them shouldn't take a long time because they're much easier than adding JavaScript, for example, which is a big undertaking.
I just looked all through my old customizations though (I emailed them to myself before I started playing around w/the new smugmug), and I don't see anything like that in there...
You're probably noticing by now crickets whenever someone asks a question like that because the first law of security on the Internet is don't talk about security publicly.
The only thing I feel that's responsible to say is we have to continually pay attention to security, more with each passing year.
We met again this morning on the JavaScript question because we continue to work on it, but it looks very much like if we do implement it, and we're trying, it will only run on custom domains. Is that a deal-killer for anyone?
So the thing is, and I know it's hard to see this perspective by just reading dgrin, the vast majority never had the functionality of statcounter and the rest because they were unwilling or unable to go to dgrin and install JavaScript on their sites.
So it's the right thing to do to make that functionality built-in not just from a security perspective, but also for the masses. We're working on them and many of them shouldn't take a long time because they're much easier than adding JavaScript, for example, which is a big undertaking.
Mr. MacAskill - I do understand your reservation about javascript, believe me, I do. Please, begging you, just glance at my website (please disregard photography there:(, look at it from the website design point of view). Can you allow rules-based template that can mimic some of it? Then I do not need javascript. Go to About page, see how the button's text changing based on the status of the page? can you create a rule-based button customization like that? Then javascript can be, perhaps, omitted. But the thing is.. other people have different things they implemented with javascript... different functionality... (please, don't call these functionality "hacks").
Comments
Out of interest, what were/are the actual JS security risks? I'm hoping it's not just some variant of "Won't someone think of the children" argument where a buzzword is said thereby shutting down any rational conversation or understanding of the issue. I guess it's like "Terrorism" - use that as the justification and no-one bothers to ask any more questions.
I ask because it's strange that after many years of JS being on the site - all of a sudden it's too risky to leave there for a few more hours/days to alert people?
Now, if it's a case of "We're strictly enforcing our current no JS policy for now unless you are an authorised customiser and that's just the way it is now", then that's fine (Well, it sucks really, but at least it's honest :-)
Since it's all shut down now - what security issues have been fixed please?
Actually curious to know since JS is going to remain working on the old Smugmug for many months.
Cheers - N
http://www.nzsnaps.com (talkiet.smugmug.com)
(and not just javascript - e.g. hiding gallery passwords from site owners - http://www.dgrin.com/showthread.php?t=237564).
Don't suppose you can elaborate further on this? (I'm guessing not, but thought I'd ask!
This can be represented by a bell curve. A bell curve is a graphical representation of how things (in this case high quality SmugMug sites) are distributed in a population. The reason that a standard distribution looks like this is, to put it simply, is that individuals within a population possess "valuable attributes" (coding skills, free time, etc.) in varying degrees. To put it another way, outstanding abilities, or in this case outstanding websites, are such due to their scarcity (somewhere between 2% and 16%). If a majority of people can achieve the goal (here represented in green) then it falls into the yellow section of the graph which by definition is considered average.
What you have really accomplished here, with the removal of the more powerful customization tools (java script, etc.) is to artificially force those SmugMug sites that had distinguished themselves from the pack into the yellow section of the graph, which will for a brief time skew the curve. Which is ironic since, by your own admission, your very best and most loyal customers were falling into the green section of the graph.
But artificial external influences (famine, disease, war, SmugMug updates
This really isn't true.(And I'm not pointing fingers here.) The customers were really failing themselves by not grabbing hold of the opportunity to excel that customizations provided. (Or perhaps they were satisfied with their sites and felt no need). And it is simply not possible. Most people cannot have a beautiful (Goal) site. Most people will have an average site, approximately 68% of them in fact, 82% if you include the "below average" sites. The only real failure was in denying those who fell into the green portion of the graph the ability to further customize their sites. (ie. self fulfillment, foreign currency, and various other issues). This failure has not been remedied, in fact it has been made worse.
It is depressing, and, well actually mathematically impossible because you are beating your head against a paradox, a battle which no mortal can win. In point of fact, on average, the average SmugMug website is, well, average, just like it was before and always will be. The reward that you think you are feeling is simply a function of the artificial skew in the graph created by the update that has temporarily caused some to think that their sites have reached the "Goal". This will correct shortly as the "green" 16% break away from the pack once again with unanticipated customizations, hacks, and workarounds.
That is because we all desire to be "exceptional", but only some are willing to put in the time and work to make it so. They are in fact the "exception". You just created more work for those who were already working hard. You pushed 14% of the people who had "reached the goal" of an outstanding website into the average category. And as for those that weren't working very hard in the first place with the legacy SmugMug (no time, no willingness to customize or learn how to customize, etc.) represented in the red portion of the graph, well I think we all know how those sites look already, very cookie cutter.
Don't you intuitively know this to be true? Are you getting complaints from somewhere around 8-15% of the customer base?
I'm just sayin', if your trying to make the average site above average, well...
Anyway, I plan on staying in the Green.
Can't wait to see it Paul! Let me know when it's ready.
I also liked the Bell Curve....even though the numbers and percentages made my head explode.
Facebook
Google+
Twitter
Photo Blog
I think every site on SmugMug can be beautiful. They can be well above the average for the internet and for other photography sites. That's why I go to work every day. If I didn't believe that and if I didn't work on that, I might as well find another job.
That doesn't preclude the possibility of having exceptional sites on SmugMug's platform. As we have said, we're working on the JavaScript problem. It's certainly not about trying to limit your creativity or purposely handicapping people to make it "fair".
Ideally though, the exceptional sites on the new SmugMug wouldn't be limited to people with a deep knowledge of CSS, HTML, and JavaScript. We need to provide the tools for anyone to easily add things like Statcounter.
Sorry, I should have specified that the original premise and the basis of my continuing SmugMug subscription is that SmugMug leans to the right of the curve when compared with photo hosting platforms in general. This however, is/was largely due to the "advanced customizations" that were possible with the legacy platform. Therefore the above post is in reference to SmugMug sites as a representative of those "leading the pack" so to speak.
As far as people not "measuring their sites vs. other SmugMug sites, but against other photography sites," this is not necessarily true. They are perhaps not knowingly doing so, but they are comparing you to dozens, perhaps hundreds of other photographers in your area of operation, many of whom are, with SmugMug's many thousands of customers, using SmugMug as their platform. I seriously doubt that your paying customer cares who hosts your photos so long as you have a great product and have distinguished yourself from the crowd.
Yes, that would be ideal. I'll keep an eye open for rainbows and unicorn poop, which I hear are vital ingredients for an ideal world. But in the mean time please keep us updated with respect to the progress you are making with the JS implementation.
I think that you will find that your customer base is a lot less irritated with a 'longish' wait then they are with a lack of communication and documentation.
Since Baldy and Sheaf are active in this thread, I'm hoping that one or both could answer a few questions.
1) Is it true that all lowercase URLs (at least the part after the domain name) will no longer be valid? So www.mysite.com\myphotos will not be a valid URL - only www.mysite.com\Myphotos? It is really hard for me to believe that Smugmug is willing to break potentially thousands of existing links due to a lazy, poorly thought out decision.
2) The idea of the site being rewritten from the ground up sounds like it's going to make updates/enhancements a lot easier on your side. I'm wondering if the shopping cart was included in this total rewrite or if it's still the old code, making updates/enhancements as difficult as before?
3) It doesn't seem like anything has changed with the cart/coupons/packages - is this the case?
Thank you.
Mike
1) Yes, no longer valid
2) Don't know. It doesn't look like its changed but presumably its had to integrate with a new site infrastructure
3) Correct, nothing has changed wrt functionality on cart/coupon/packages
We're active in a lot of threads, but can't respond to everything.
1) Yes. We need to reserve the space for special pages like /browse, /date/, /keyword/, etc. Some of our URL structures also depend on a lowercase first letter. We did our best to preserve older links, so if there is a problem with any I would love to see specific examples.
2) Not yet.
3) There were a few changes to packages updated as part of this, but the changes happened a month or so ago. For example, the interface for filling a package used to have a terrible filmstrip-style thing at the bottom to choose photos. Now people can simply click to choose photos.
We recognize that these tools are important to people running their businesses off of SmugMug, but we haven't yet made significant improvements to them.
I don't have specific examples of broken links, but I saw a thread about this. Can't find it at the moment. I help manage a site for a high school track/cross country team (we have not converted, so this isn't a direct issue for us yet.) It has been a common thing to tell someone "photos will be at oursite.com slash mason5k". Or the URL could be typed by someone to be emailed or texted. There are many possibilities for this to be an issue.
I don't see a case where you'd ever need mysite.com/browse or mysite.com/date, but if you say it's possible I'm sure it is. It just seems like reserving your keywords - preventing sub categories or galleries from being called "browse" or "date" would be easier than breaking all urls that are entered with a lowercase first letter.
I guess time will tell how much of an issue this is going to be.
I haven't seen the new package fulfillment - I stopped using packages because of the terrible filmstrip-style thing. This is good news.
Yeah - these tools are more important to me than having the latest and greatest site layouts, but it sounds like I'm in the minority here.
Thanks again for taking the time to respond.
Except that we don't know what structures we will need in the future. For example, we now use /organize and /customize. We have a few more in planning, but we don't know what we'll need in a few years. The potential collisions in the future can be avoided by restricting the case of the first letter.
I'm sure it's too late now, but could you trigger on all uppercase? So /ORGANIZE and /CUSTOMIZE would be reserved, but all lowercase - the case that most people will naturally use when they type in a URL - would still be available.
Frankly, I'd rather take the risk of you breaking a link in the future by adding a new keyword that just so happens to be a name of a sub category or gallery or whatever that I've created. Has anyone ever named a gallery "organize"?
Another option would have been to tag all of your keywords with a prefix - sm_organize, sm_date, etc. Then have a rule saying that users can't create any object starting with sm_.
I'm sorry for being critical, but this just doesn't seem to be very well thought out. Using case as a differentiator is seldom a good idea.
The only thing I feel that's responsible to say is we have to continually pay attention to security, more with each passing year.
We met again this morning on the JavaScript question because we continue to work on it, but it looks very much like if we do implement it, and we're trying, it will only run on custom domains. Is that a deal-killer for anyone?
I suppose that depends on how quickly you roll out the functionality that people without a custom domain have lost in the new version. The ball's in your court.
Only problem with that is, I keep seeing my username.smugmug.com address showing up from time to time instead of automatically changing to my custom domain. Used to be if someone typed username.smugmug.com it would automatically change to customdomain.com. Doesn't seem to do that anymore...
PS - I don't want javascript, I just want Statcounter to work
Jason Scott Photography | Blog | FB | Twitter | Google+ | Tumblr | Instagram | YouTube
Whereas I won't presume to speak for the masses, I think that is a fair compromise. My guess is that most of the folks interested in JS customizations already have custom domains anyway.
Hmmmm, I will look into that. For as long as I remember, bonocorephotography.smugmug.com always went to that URL, not my custom domain...but I could be wrong.
Facebook
Google+
Twitter
Photo Blog
I have a custom domain, so it won't affect me if it's like that.
Of course, the only reason I need JS back is to have my Adsense ad back on my page. I don't even need scripting, and it's ludicrous that I'm being stopped, for security reasons, from using the single biggest CPC network known to man... lol. I know a lot of people would abhor the thought of an Adsense ad on their page... but I was making good money from it... far more than my yearly subscription cost. This needs to be allowed again soon, it's really not OK to just take away a major source of income.
If I remember correctly, it was a javascript hack. And a handy one.
re: limiting javascript to custom domains, on a personal level that would suit me nicely. I would have thought though it might make more sense to limit it to an account level (either Power or Portfolio I guess)
Security-wise I'm not sure how a custom domain would make any difference, or necessarily correlate to a higher level of coding experience. It might however, arguably make Smugmug less liable for the content displayed.
Perfect... at least for me it is perfect. Custom domain it is...
So it's the right thing to do to make that functionality built-in not just from a security perspective, but also for the masses. We're working on them and many of them shouldn't take a long time because they're much easier than adding JavaScript, for example, which is a big undertaking.
Hmm, you might be right about that...
Jason Scott Photography | Blog | FB | Twitter | Google+ | Tumblr | Instagram | YouTube
I just looked all through my old customizations though (I emailed them to myself before I started playing around w/the new smugmug), and I don't see anything like that in there...
Jason Scott Photography | Blog | FB | Twitter | Google+ | Tumblr | Instagram | YouTube
Mr. MacAskill - I do understand your reservation about javascript, believe me, I do. Please, begging you, just glance at my website (please disregard photography there:(, look at it from the website design point of view). Can you allow rules-based template that can mimic some of it? Then I do not need javascript. Go to About page, see how the button's text changing based on the status of the page? can you create a rule-based button customization like that? Then javascript can be, perhaps, omitted. But the thing is.. other people have different things they implemented with javascript... different functionality... (please, don't call these functionality "hacks").
very old thread on the matter:
http://www.dgrin.com/showthread.php?t=44777
and related feature request:
http://feedback.smugmug.com/forums/17723-smugmug/suggestions/1958095-301-redirect-smugmug-domains-to-custom-domains
I love the all lowercase aesthetic and have it printed on business cards among other places too. Would hate for those not to work.