Add a PayPal shopping cart to your SmugMug galleries

thenickdude

I have created an extension for Google Chrome which allows you to add PayPal "buy now" and "add to cart" buttons to a gallery full of photos at once. This works by automatically adding customised PayPal code to the captions of the photos you select, which causes those buttons to appear underneath your photos.

This extension is currently in Beta, so please take care to test it out on a couple of photos first before you apply it to an entire gallery!

You can find out more about this feature and download this extension on my website here:

http://www.sherlockphotography.org/Customisations/PayPal

Here's an example of the buttons in use, try adding a couple of photos to your cart!

http://www.sherlockphotography.org/Customisations/PayPal/Example-cart-gallery

(but don't check out, as my photos aren't for sale )

This extension is open source under the MIT License, you can read the sourcecode here:

https://github.com/Sherlock-Photography/smugmug-chrome-ext

TalkieT

Ohhh, so for a big gallery with hundreds of images, it has to create the individual code for each image? It's an innovative idea, and well done for thinking outside the square - but does this inflate the page sizes much?

Any other downsides (apart from no captions - or garbage in the captions at least)

Cheers - N

thenickdude

No, there's no significant impact to page sizes - SmugMug uses compression when it sends its responses, and since the code is highly repetitive, it compresses down to virtually nothing.

Apart from the text from the PayPal button appearing in captions in some places where it shouldn't, there are a couple of downsides:

- Since it's applied per-photo, if you add more photos to the gallery later, you need to go in and add PayPal buttons to those new images
- If you edit a photo's caption, this change won't be reflected in the name that appears in the PayPal cart, until you re-apply the PayPal button

However, I think this is the best we're gonna get, because I doubt that SmugMug will add support for the old-style customisation within the next year.

TalkieT

Unfortunately I agree... Smugmug have utterly clammed up about Javascript and Paypal support in the last month or so. It's clear they are ignoring it and hoping it goes away.

Well done on coming up with what you have... Great lateral thinking.

Cheers - N

David-Stallard

Thanks for the hard work.

I will keep pestering smug to implement it in their standard cart as it's such a simple thing for them to do - I mean if zenfolio can add it overnight when they were asked it's obvious their just being 'petty'.

I will try to look at your set up again when I get a sec but having to redo buttons etc when photo's are added or removed is a bit out of my time scale.

I will for now have to rely on the customers sending me emails with their requests grrrrr

.DAVID.

thenickdude

I'm pretty sure that the time spent adding buttons for new photos will be worth it. It only takes a couple of clicks if the whole gallery uses the same PayPal button. Your customers will probably buy more photos if the checkout process is more convenient for them.

By no means could SmugMug integrate a PayPal option into their current cart system overnight. I've actually built a PayPal cart integration for my own (non-SmugMug) site. It'd probably take a several developer-months to achieve, plus the time taken for the design, testing, documentation, and support training.

TalkieT

Lamah wrote: »

[snip]
By no means could SmugMug integrate a PayPal option into their current cart system overnight. I've actually built a PayPal cart integration for my own site. It'd probably take a several developer-months to achieve, plus the time taken for the design, testing, documentation, and support training.

You're right, but they COULD re-enable JS overnight, given that some customers do have access to it now - there's clearly a per user flag for stripping JS or not. Probably wouldn't even take until overnight...

Cheers - N

thenickdude

Yeah, they could ignore the security holes they decided to fix with New SmugMug, and enable JavaScript overnight. They won't, though. Developers sleep poorly when they're aware that any of their customers could add JavaScript to their sites that can automatically trash the SmugMug site of anyone who visits who is logged in.

TalkieT

I still have JS since I'm on the old platform. Just sayin. Reminds me of having to turn off your phones on flights - Sure there might be a theoretical danger, but no-one has ever proved it in controlled circumstances and if there was a clear and present danger, do you really think they'd rely on the honour system for people to turn them off?

They are actually saying that a bottle of water is more dangerous than leaving your cellphone on.

If JS is that dangerous, why leave it alone for legacy users during such an extended transition ?

Cheers - N

thenickdude

I suspect that it wouldn't be a good idea to add a proof of concept to my site, so you're just going to have to trust me on that one.

JavaScript is still allowed on legacy because they could never turn that off without breaking more sites than a hacker would using bad custom JS. The switch to New SmugMug provided the first good opportunity to close this hole.

araknee

Thanks for this - Lamah, I used JS on the old site and was wondering how to add paypal.
I owrked through your instructions and had no hickups.
The add to cart button does not show in the gallery.
Do I need to migrated to the new site or will it show in the preview mode?

Cheers, Rod

thenickdude

Hmmm, when you use the regular SmugMug tools to make changes to captions in the preview, do they show up?

araknee

I added the code to the caption manually and the button does not show but the drop down box does.

I just added < html > tags to the info in the caption and the button show up on the legacy site but not the new site.

http://galleries.noendeng.com/Roller-derby-fotos/Open-Season-2013/13-03-09-Open-Season-Rnd-1-1/28411813_LBXG3c#!i=2411834426&k=h3zgKPM


Update - redid the code for the paypal buttons and will add to gallery images manually for now.

Thanks

thenickdude

Nevermind, and don't bother, SmugMug have decided that they'd rather block PayPal buttons on photos for us now.

araknee

Lamah wrote: »

Nevermind, and don't bother, SmugMug have decided that they'd rather block PayPal buttons on photos for us now.

So I will probabley loose the buttons that I have now?

I entered these manually but have not tried without the < HTML > tags

only problem now is the file name is not showing.

thenickdude

Most likely yes, from what I hear SmugMug are going to remove those.

Can you post the PayPal code you were entering into the extension that didn't work? You weren't enclosing the code in more HTML code of your own were you?

brandofamily

Lamah wrote: »

Nevermind, and don't bother, SmugMug have decided that they'd rather block PayPal buttons on photos for us now.

Are you serious? SM intentionally blocked the code you wrote?

thenickdude

Yup. I have a workaround in mind but I suspect they will block that too.

I think we'll hear a rep chime in shortly about how they're not against the idea of PayPal but they want to "do it right". Then all they need to do is wait a couple of years until everybody who needs PayPal leaves SmugMug, then they can forget about implementing it.

brandofamily

Lamah wrote: »

Yup. I have a workaround in mind but I suspect they will block that too.

I think we'll hear a rep chime in shortly about how they're not against the idea of PayPal but they want to "do it right". Then all they need to do is wait a couple of years until everybody who needs PayPal leaves SmugMug, then they can forget about implementing it.

Have you contacted them directly about this?

thenickdude

Didn't need to, they contacted me first to let me know. Doesn't look like the block is in effect just yet, but it's planned.

brandofamily

Lamah wrote: »

Didn't need to, they contacted me first to let me know. Doesn't look like the block is in effect just yet, but it's planned.

What's the BS reason.... oh, they can't get their cut if we can use paypal and self fulfill orders...

TalkieT

Wow... Can't say I'm surprised, but this is a low, dirty move that goes against all their stated reasons for opposing Paypal...

Come on Smugmug, stop being such underhanded, secretive ..

You know what? I give up, I can't comment on this effectively and stay on the right side of any personal good taste filters.

Smugmug, I'm really disappointed in you, again.

Cheers - N

AdamNP

Just adding my feelings. Although I have no interest personally in using Paypal or self fulfillment, I do have interest in other needed additions. And I've had just about enough. SM is just being dirty now. Why should we expect anything to ever be done properly? Where are you Baldy? What are you letting happen to your company? A lot of comments are needed on a lot of threads, and soon.

It's amazing how a company that I used to praise to everyone can so completely reverse their image so quickly. And you know what the saddest part is? The new SM is awesome in most ways, and far superior to legacy. Unforunately, that doesn't really matter if you systematically ignore and anger customers.

Baldy

Lamah wrote: »

Yup. I have a workaround in mind but I suspect they will block that too.

Hey Lamah,

You are a seriously talented guy who is doing some amazing stuff on SmugMug, which everyone loves. And I know you must've done some serious work on this, only to have us cut you off. If that happened to me, I'd be deflated too.

I know this looks like we're trying to kill self-fulfillment but it's really not about that. Brian mentioned in his email to you that we made a decision to eliminate HTML forms but he didn't explain why. But you're so knowledgeable about security I'm sure you'll immediately know why.

Someone else said they were bummed that we hide behind the need to do it right and really we must be covering up a selfish motive. But since we launched we've added a number of things like Wufoo forms, stat counter, Vimeo app, plus both Google Calendar and AdSense are in test (AdSense is a pain to test so it will probably take longer than Google Calendar).

The heroes have received many angry emails about AdSense since launch and I think the anger comes from imagining that we don't want ads on the site or we want a cut of the action. Actually, we just want to be more secure and to make the solution available to more people like it will be if it's built in. Our solution is not going to give us a cut.

Internally, we know there will be many threads like this where it's not responsible to go into details about security, but the right thing to do for everyone, including the most angry people, is to take reasonable steps towards better security. Some day the flames will be much hotter if we don't.

TalkieT

Chris, how on earth did you come in here and post a reply without mentioning what your plans are for allowing paypal and self fulfillment.

Come on... Since the initial flurry of posts (including the ones insisting that Paypal still worked and provided it was done just with HTML it would be ok), there has been DEAFENING SILENCE on this topic.

Yes, you owed Lamah an apology for changing the rules after he developed a very clever workaround within what the rules were at the time, but you still owe your existing customers an honest evaluation of the intent and likely timeframes to support custom Javascript (or at least Paypal and Self Fulfillment)

How about answering the clear intent of this post, instead of ignoring it, or talking around the question?

Cheers - N

yaypie

Hi guys. I'm one of the evil jerks at SmugMug who wants to ruin all that's good in the world. Except, actually, that's not what's going on here. Let me try to explain, because I think this is pretty important (and I hope you'll agree).

When we first saw Lamah's PayPal shopping cart trick, our reaction was, "Wow, that's really cool!" Followed shortly thereafter by, "Wait...if a *good* person can do that, what could an *evil* person do with the same power?" Which, incidentally, has been our reaction to several of Lamah's awesome hacks.

Lamah is a clever guy, and we also think he's pretty trustworthy. But there are some people out there who are almost as clever as Lamah, but not nearly as trustworthy. SmugMug has always been about giving people powerful customization tools, and that means letting you get your hands dirty with HTML and CSS (and, in legacy SmugMug, even JavaScript). This is great, but it opens up a lot of avenues for bad people to potentially do bad things, and the last thing we want is for someone to do bad things to our customers, so we have to be pretty careful.

The issue in this case is that we're allowing custom HTML forms in image captions and gallery descriptions. Lamah used this in a good way, to provide PayPal integration. We definitely don't mind that -- we want you guys to be able to do cool stuff!

But in order to implement a PayPal "Add to cart" button, you have to use a element, which submits a form to PayPal's site. When we started thinking about this, it occurred to us that a malicious person could cause a form to be submitted to a fake site that just *looks* like PayPal. If they could trick a SmugMug user into entering their PayPal username and password on that site, then they could potentially gain access to that user's PayPal account and steal money. This is calling phishing, and it's one of the primary avenues through which no-good rotten scumbags commit identity theft on the web.

This got us thinking about other ways a no-good rotten scumbag might phish SmugMug users, and we realized we needed to make some changes to keep everyone safe and secure.

The last thing we want to do is take valuable functionality away from our users, so we had a pretty extensive internal debate about the best way to deal with this. On the one hand, we want to keep everyone safe. On the other hand, we want SmugMug to be highly customizable, and we didn't want to have to tell Lamah that we were going to break his clever PayPal trick.

In the end, we came up with a plan that involves what we think is a necessary compromise. Since this involves the security of the site and our users, I won't go into detail until we've implemented it, but one aspect of it is that we plan to stop allowing elements in image captions and gallery descriptions.

Brian, our director of engineering, reached out to Lamah to give him an early heads up since we felt bad that we hadn't thought of this stuff until he had already devoted time and effort to working on this, and we didn't want to waste any more of his time.

We tried really hard to come up with a good way to be safe about this without breaking Lamah's PayPal code, but the truth is that anything we let the good guys do, the bad guys can do too. In the end, we made the hard decision that keeping our users safe was the most important thing.

It's not fun making decisions like this, especially without asking for feedback from the community, but as Baldy said above, when it comes to security issues, it's sometimes a Catch-22. We believe that most of our users are wonderful, lovely people with the best intentions, but we can't ignore the possibility that there may also be people out there whose intentions are less honorable, and we don't want to give them a heads up about potential security issues they could exploit.

I hope this at least clarifies some of the reasoning behind our thinking. Once we get some of these changes implemented, I'll be more than happy to go into the nitty gritty details for anyone who's interested.

TalkieT

Thanks for the detailed reply, and yes, it makes sense, but it totally destroys the story we've been fed about Javascript EVER potentially coming back.

Based on your logic, if something CAN POSSIBLY be used for evil, you WILL NOT allow it on the site. In the context of your post, we're NEVER getting Javascript back. Am I right?

I really, really, REALLY want an official answer to this query - it's not a rhetorical question.

Cheers - Neil G

thenickdude

yaypie wrote: »

it occurred to us that a malicious person could cause a form to be submitted to a fake site that just *looks* like PayPal. If they could trick a SmugMug user into entering their PayPal username and password on that site, then they could potentially gain access to that user's PayPal account and steal money.

Literally the same risk applies to any off-site link. There's nothing stopping anyone from adding a PayPal "buy now" button to their SmugMug page which is actually a link (<a> element) to a website they control, with or without using a <form> element. I can think of additional security risks of allowing form elements, but this isn't one of them.

Also, if <form> elements are a concern, why not also block them in HTML Content Blocks?

yaypie

TalkieT wrote: »

Based on your logic, if something CAN POSSIBLY be used for evil, you WILL NOT allow it on the site. In the context of your post, we're NEVER getting Javascript back. Am I right?

Security is all about tradeoffs. The most secure website in the world is a blank white page with no features, but who would want to use that website? As with everything we do, we want to find the right balance of security and features that will please the most people and keep the most people safe.

While there are some things we will never compromise on, such as how we store passwords, or how we handle payment information, there are other cases where we believe there's a sweet spot, and that's what we're aiming for.

When it comes to JavaScript, the main issue is one of trust. If we can trust someone not to be evil, then we can allow that person to host custom JavaScript on SmugMug. But how do we decide who to trust? Do we trust everyone by default unless they do something bad? Do we trust no one by default unless they first prove themselves to be good? Or do we aim for a middle ground?

We want to find the sweet spot. Sometimes that can be really, really hard, and we know that if we make promises and then end up having to break them, people will be upset (and rightly so!). For that reason, we try not to make promises unless we know we can keep them. Sometimes this means we have to keep quiet about things we're not ready to talk about yet, but one thing I can promise you is that we're working incredibly hard on this stuff every day, and our primary metric for success is whether we make our users happy.

yaypie

Lamah wrote: »

I can think of additional security risks of allowing form elements, but this isn't one of them.

I can think of additional security risks too, but the last thing I'm gonna do is list them all here before fixing them.

thenickdude

Okay, well in that case I'll modify this extension so that it no longer uses elements, and everybody wins...