Buy Button Missing

RogersDA

The Buy Button is broken (as I first mentioned here: http://www.dgrin.com/showthread.php?t=161100).

See Gabriel's workaround: http://www.dgrin.com/showthread.php?t=161055

Also, I took advantage of the SmugMug's customization and added a specific jQuery script that worked quite well to scale the background image. See here: http://www.dgrin.com/showthread.php?t=158935

Today, however, I have no Buy Button. It disappeared right after the latest release (events, packages, etc.). If I remove the script the Buy button shows, but it will be to the right of the View Cart Button (it used to be to the left of the View Cart Button).

So I want to keep the scalable background, but it appears I need some timer hack to keep it from running until SmugMug creates the Buy Button. That does not seem logical. See here: http://www.dgrin.com/showthread.php?t=161318

I have no idea how many people have customized their site and just do not realize that their Buy Button is missing.

jfriend

I just want to add to this that recent changes to the buy button for packages have really messed up our ability to customize the page. First of all, existing scripts people had to customize the buy button (that fired on YE.onDOMReady) are no longer working. Secondly, a completely unrelated script that changes the page background and fires in onDOMReady seems to break the buy button.

So all of a sudden the buy button has become uncustomizable using normal scripting techniques and other page customizations seem to break the buy button. Woah. Everything suddenly got fragile for the buy button. I hope Smugmug doesn't want this to be the case and the way the buy button works can be rethought to make it less brittle and to make normal customization techniques work again.

FYI, if you're delaying the creation of the buy button until after onDOMReady in order to gather some info about packages, how about creating the buy button as you normally would and then dynamically adding the package menu item later when you have the appropriate packages information. Then, all existing scripts that modify the buy button could continue to work.

Also, us JS customizers really need a universal event that we can subscribe to that indicates to our own scripts that Smugmug is done with all page creation logic, including all the JS that is now used to create page elements. I've been asking for this for years because as it is now, we're relying on perilous timing to make some of the customizations work. It used to be that onDOMReady generally worked, but now even that doesn't work in some cases.

Also, any time you dynamically create page elements with your own JS via some page level event, we need an event when they are done being created. For example, there is NO reliable way to use JS to modify the lightbox without doing some serious hacking (replacing your functions with our own so we can see when they are called).

A simple event that you fire when you're done creating the lightbox page elements would make this trivial for us to use JS to customize. As another example, the new thumbnail view creates and loads thumbnails automatically as the page is scrolled. If one was trying to modify those with JS after they were loaded, you would need an event in order to be able to do so. As another example, the photoInfo box is dynamically created when the viewer first requests to see it, yet there is no known even that we can hook so we could modify it via JS if required. This has been hacked by replacing one of your JS functions, but you can imagine how much of a hack that is and how brittle it is.

As time passes, it looks like there will be more and more of these dynamically created page elements. Please think of your customizers and take the 15 minutes that it takes to add and document an event after these elements are created. Since YUI has such a nice event sub-system, I suspect you could even do this quite elegantly. Ideally you would integrate all events into the same system (including things like onPhotoShow) rather than makes one-offs for every new event.

docwalker

Thanks guys. I will make sure that the team sees your comments.

--Doc

RogersDA

docwalker wrote:

Thanks guys. I will make sure that the team sees your comments.

--Doc

earear

jfriend

jfriend wrote:

As time passes, it looks like there will be more and more of these dynamically created page elements. Please think of your customizers and take the 15 minutes that it takes to add and document an event after these elements are created. Since YUI has such a nice event sub-system, I suspect you could even do this quite elegantly. Ideally you would integrate all events into the same system (including things like onPhotoShow) rather than makes one-offs for every new event.

Here's yet another thread where there's a customization that can't be solved in a robust way because the photobar is created dynamically on demand, but there are no events to hook so we can know when it is created so there's no stable way to modify it with JS. Again, what we need is for every dynamically created page object (that can't be hooked with onDOMReady or onContentReady) to have an event we can register for when it is created so we have an opportunity to modify it with our own JS.

You will note in the referenced thread that the total HACK way of solving this involves replacing your existing JS functions that create the photobar with our own as a hack means of knowing when it gets created. This is a horrendous hack and should be avoided because it can very easily break going forward and can very easily be done wrong. A simple event that our JS can register for (just like onPhotoShow.subscribe) for every single dynamically created object is all we need to make this non-brittle and easily doable. It would take a few minutes of JS for you to add the event.

Andy

jfriend wrote:

Here's yet another thread where there's a customization that can't be solved in a robust way because the photobar is created dynamically on demand, but there are no events to hook so we can know when it is created so there's no stable way to modify it with JS. Again, what we need is for every dynamically created page object (that can't be hooked with onDOMReady or onContentReady) to have an event we can register for when it is created so we have an opportunity to modify it with our own JS.

You will not in the referenced thread that the total HACK way of solving this involves replacing your existing JS functions that create the photobar with our own as a hack means of knowing when it gets created. This is a horrendous hack and should be avoided because it can very easily break going forward and can very easily be done wrong. A simple event that our JS can register for (just like onPhotoShow.subscribe) for every single dynamically created object is all we need to make this non-brittle and easily doable. It would take a few minutes of JS for you to add the event.

Can't make any promised, John - but I made sure the sorcerers saw this post. Thanks!

jfriend

Andy wrote:

Can't make any promised, John - but I made sure the sorcerers saw this post. Thanks!

Thanks. The alternative is unsolvable customization questions or dangerous JS hacks that can break or cause instability or periodic polling that can degrade performance.

It feels like there are more and more changes that are not customization friendly when it would really be easy to keep things customizable: (divs and spans with no classes or IDs, dynamically created objects with no creation events, things that used to work with onDOMReady that don't any more, etc...). It's probably just new developers who aren't quite tuned in to the small things that keep the site customization friendly, but I'd sure hate to see Smugmug drift away from being so customizable just because new folks weren't aware of the small things that could keep it so.

The frustrating thing is that these are very little things that it takes to keep the site customization friendly. Add an event here and there when things are dynamically created or modified. Make sure all divs and spans have CSS addressable identifiers, etc...

RogersDA

I will add that this is somewhat more important than my simple missing buy button. As a whole this means that elements that could be styled by the users can't be. And the end result is that a lot of sites get the same look for a lot of features. Quite contrapositive to SmugMug's goal of individual customization.

RogersDA

News? Updates? Anything?

Andy

RogersDA wrote:

News? Updates? Anything?

are you missing the buy button if you remove the hack?

RogersDA

Andy wrote:

are you missing the buy button if you remove the hack?

If I recall the jQuery background script creates the scalable background. Working with Barb we found that removing that did cause the buy button to return.

I wouldn't consider it a hack as it really is just configuring a background image and not trying to alter any SmugMug-generated content. But - that's semantics - with the script there is no button, and John said that the DOM had no reference to it all. Without the script, there is a buy button. I like the script and would prefer to keep it if at all possible.

Andy

RogersDA wrote:

If I recall the jQuery background script creates the scalable background. Working with Barb we found that removing that did cause the buy button to return.

I wouldn't consider it a hack as it really is just configuring a background image and not trying to alter any SmugMug-generated content. But - that's semantics - with the script there is no button, and John said that the DOM had no reference to it all. Without the script, there is a buy button. I like the script and would prefer to keep it if at all possible.

I really don't know what to say - it sure seems like something in your script is nuking it.

RogersDA

Andy wrote:

I really don't know what to say - it sure seems like something in your script is nuking it.

Well, I removed the jQuery. :cry That bums me that I can't get this one working w/ SmugMug.

RogersDA

RogersDA wrote:

Well, I removed the jQuery. :cry That bums me that I can't get this one working w/ SmugMug.

The sorcerers have fixed the problem. clap

Andy

RogersDA wrote:

The sorcerers have fixed the problem. clap

Yes, we changed up the RPC call - hope all is good!

go11photo

Phew

Andy wrote:

Yes, we changed up the RPC call - hope all is good!

Thanks! Just noticed this yesterday, and woke up this morning to a fix. Amen, because my workarounds were going to be messy.