Incompatible with Page scroll to id

berchca
(@berchca)

11 years, 2 months ago

I don’t know if this is a priority or not, but I’ve been struggling for a bit to get Sticky Menu to work with the ‘Page scroll to id’ plugin. The problem was that once that menu started to stick, the menu highlighting disappeared.

The trouble seemed to be that Page Scroll was only highlighting items on the original menu, not the clone (Dynamic Mode did not help). I did a workaround by inserting the clone before the original (changed jp-sticky-anything.js ln 92, switched insertAfter to insertBefore), but I was wondering if there was a more elegant solution (and/or one that I wouldn’t have to re-institute every time the plugin was updated).

Thanks,
Brett

https://wordpress.org/plugins/sticky-menu-or-anything-on-scroll/

Viewing 13 replies - 1 through 13 (of 13 total)

Senff – a11n
(@senff)

11 years, 2 months ago

I’ve seen this issue before — but I can’t immediately recall if there was a solution for this (in some cases, turning on Dynamic Mode would help…but as you say, that doesn’t solve it for you).

I’ll look into it to see if there is a solution that will help, but in the meantime it’s indeed a good idea to change what you changed.

Of course, this is not a bug in either this plugin or the Page Scroll To ID plugin — it’s simply the result of both plugins using different methods that conflict with eachother.

Thread Starter berchca
(@berchca)

11 years, 2 months ago

No, not a bug, certainly. Just one of the unfortunate aspects about having a completely open platform like WordPress (IMHO). Just wanted to make sure my solution was okay, or find out if you had a different recommendation.

Thank you for the plug-in, by the way. It’s fantastic.

-Brett

Thread Starter berchca
(@berchca)

11 years, 2 months ago

Hey Mark,

Just wanted to follow up: my earlier solution proved to be buggy, so I dug a little deeper. Apparently clone() can cause trouble with divs that have ID tags (which mine does, and that’s what I use to specify it in Sticky Menu’s settings). What I ended up doing was modding your code to swap the ID tag between the ‘original’ and ‘clone’ divs as each was displayed/hidden.

It wasn’t anything particularly clever, but let me know if you want the details.

– Brett

Senff – a11n
(@senff)

11 years, 2 months ago

Hey @berchca,

You are right — issues can arise when another script/function uses specific IDs to do something.

Unfortunately, I kinda “have” to clone the entire item, including the ID of it. It’s invalid HTML (since every item on a page has to have a unique ID) but it’s the only way to ensure that the cloned item has the exact same styles and properties of the original item.

And yes, unfortunately that causes some issues like the one you experienced.

If your solution works for you, then great! However keep in mind that it may be overwritten whenever there’s an update to the plugin!

Thread Starter berchca
(@berchca)

11 years, 2 months ago

Hey Mark,

I certainly wasn’t trying to imply I felt there was anything wrong with using clone(); it looks to be the right call for the job. All I did was change the div id when ‘clone’ is spawned, as with the other attributes you change, ala:
$(‘.original’).clone().insertBefore($(‘.original’)).addClass(‘cloned’).css…….removeClass(‘original’).attr(‘id’, ‘non’).hide();

and then flip-flop the ID as the div is shown and hidden.

Anyway, didn’t know if you’d be interested. And thanks for the reminder about having my mod overwritten (I did take the precaution to change the version number on the modified to 100.2, so that should cover it for a few months, anyway).

Thanks again for the plugin,
Brett

Senff – a11n
(@senff)

11 years, 2 months ago

I think you might be on to something 🙂

To flipflop the ID between the original and the clone might work for you, but I can’t directly change that in the plugin, because for some themes the ID determines the element’s dimensions, and those shouldn’t be changed, especially not for the original element.

But….

To ensure there will never be two items with the same ID, it might be a good idea to have a clone that will only be generated when it’s needed (when it’s past the so-called scrollpoint) and then actually remove the original element. However, since that’s the whole idea this plugin is based on (original element is still there, just invisible, in order to make sure it’s not taken out of the flow), it needs to be replaced by another new element that just has the same dimensions. Some “placeholder” element.

Then when the original is needed again, the element needs to be generated again….but this could pose a problem if the element is complex (nested divs, ULs, LIs, etc.)

This sounds like a possible solution in theory, but there will definitely be issues in practice (performance is just one issue that I’m worried about). It’s also a very big change that will need lots and lots of testing. And then even some more testing. I’m also a little bit worried to make such big changes to a plugin that works for 99% of the users — “if it ain’t REALLY broke, don’t fix it“, so to speak. I’ll aim for 100%, but these changes would be significant enough to risk that things would go down to 95% (so to speak), so….. It’s something I’d like to try for version 2.0.

Not sure when, but I’ll definitely try and think what’s the best course of action. Having said that, changing “insertAfter” to “insertBefore” worked for you, didn’t it? I should prioritize testing that first, to see if that change wouldn’t result in other issues. That’s a smaller change that I could look into first.

Thread Starter berchca
(@berchca)

11 years, 2 months ago

Hey Mark,

To start with, yes, I admit I have an extremely myopic point of view on this, having only tried this plugin with the one theme (Gravit), and really only encountering the problem when I started running it in parallel with the Page Scroll to Id plugin. That said, if you happened to have a set of themes you test with, I’d be happy to run through them myself, just for the sake of curiosity.

I definitely hear you about how if it’s working for most people, so why get too hung up on the fringe cases (we’re always the worst, aren’t we?)

Anyway, I had initially thought that by switching the code to insertBefore I had solved my problem, because the highlighting function of Page Scroll was acting on the first version of the menu, visible or not. But then I discovered that the menu highlighting would stutter when scrolling near the top, which I discovered was because menu items would be highlighted on one copy of the menu, and then, by the time the item was changing, the other menu was in effect. But, yes, it did work better.

Incidentally, when I first started to think about fixing my own problem, I was wondering if I could create a placeholder of the same dimensions. I was dubious, though, that such a solution wouldn’t require all sorts of cross-browser exceptions. Perhaps that situation isn’t so bad these days?

I would think that removing the original element is just a long way around to simply skipping the clone altogether and modifying the properties of the original div when you reach the end of the scrollpoint. Am I wrong? I had seen this in a another floating menu plugin (which didn’t work very well, and I don’t remember which one it was now).

If I can be any help, just let me know,
Brett

mantella
(@mantella)

11 years, 1 month ago

Let me know if you find a good solution for this. I’m having the exact same problem. Trying to use Sticky Menu along with Easy Smooth Scroll Links. Odd thing is that it worked for an hour or so last night when I installed both plugins. Looked fantastic. Tried it again this morning and it’s broken.

If I’m at the top of the page (using original nav bar I assume) then the smooth scroll works. Once I’m further down on the page (using clone) the links just pop to the anchor points, old-school style.
Any help is appreciated.
Here’s the page I’m referring to:

http://www.moltenaura.com/our-glass/

Senff – a11n
(@senff)

11 years, 1 month ago

@mantella: there is a known conflict issue with Easy Smooth Scroll Links plugin. Someone else who had the same problem reached out to the author of that plugin, but we haven’t heard back yet. See this other thread for details: https://wordpress.org/support/topic/another-plugin-doesnt-work-with-this-plugin

Although, there may be some other things going on with your site; for example, this page doesn’t look very well: https://moltenaura.com/our-glass/
May have to do with the https connection (as opposed to http)

Thread Starter berchca
(@berchca)

11 years, 1 month ago

@mantella: I did fix my conflict, though I’m using Page Scroll to ID instead of Easy Smooth Scroll. I didn’t do a very comprehensive fix, but if your Sticky Element is an anchor tag (hash prefix), then my fix might work for you.

The thing is, I didn’t see that your menu was sticking at all. Is that part working?

Senff – a11n
(@senff)

11 years, 1 month ago

@berchca : from what I can see, the item that’s sticky is #glassbar. It’s sticky, and it actually works right now because (I believe) Page Scroll to ID is now implemented on http://www.moltenaura.com/our-glass/

I should put this in the FAQ…

Thread Starter berchca
(@berchca)

11 years, 1 month ago

@mark: Yeah, seems to work great. My fix was about getting the menu highlighting to work correctly, which, now that I see this page in action, doesn’t seem to be a factor here.

mantella
(@mantella)

11 years, 1 month ago

ok, yeah I was still messing with that page this afternoon. I actually disabled the Easy Smooth Scroll and installed the one you mentioned (Page Scroll to ID) which seems to work!

Thanks for the reply.

Viewing 13 replies - 1 through 13 (of 13 total)

The topic ‘Incompatible with Page scroll to id’ is closed to new replies.