Support » Plugin: Flying Pages by WP Speed Matters » Uncaught SyntaxError after activating first time

  • Resolved lydenyardley

    (@lydenyardley)


    Hello,

    I love the idea of combining the best of both worlds with your plugin, but so far I’ve been unsuccessful in getting it to work.

    I installed, activated and checked it, and there appeared to be no speed increase.

    I opened up the console in Chrome DevTools and saw two errors:

    Uncaught SyntaxError: Identifier 'observer' has already been declared
        at flying-pages.min.js?ver=2.0.8:1

    &

    Uncaught ReferenceError: flyingPages is not defined
        at (index):31

    Any idea what’s going wrong here?

    The page I need help with: [log in to see the link]

Viewing 15 replies - 1 through 15 (of 18 total)
  • Plugin Author Gijo Varghese

    (@gijo)

    @lydenyardley Thanks for reporting the issue

    After analyzing your site, I found a code that conflicts with Flying Pages. The code :

    <script>/* from https://usefulangle.com/post/108/javascript-detecting-element-gets-fixed-in-css-position-sticky */
    var observer = new IntersectionObserver(function(entries) {
    	// no intersection with screen
    	if(entries[0].intersectionRatio === 0)
    		document.querySelector("header").classList.add("scrolled");
    	// fully intersects with screen
    	else if(entries[0].intersectionRatio === 1)
    		document.querySelector("header").classList.remove("scrolled");
    }, { threshold: [0,1] });
    
    observer.observe(document.querySelector("#scroll-detector"));</script>

    The error is because observer is already declared. You can fix it by renaming a variable. Here is the updated code if you want:

    <script>/* from https://usefulangle.com/post/108/javascript-detecting-element-gets-fixed-in-css-position-sticky */
    var scrollObserver = new IntersectionObserver(function(entries) {
    	// no intersection with screen
    	if(entries[0].intersectionRatio === 0)
    		document.querySelector("header").classList.add("scrolled");
    	// fully intersects with screen
    	else if(entries[0].intersectionRatio === 1)
    		document.querySelector("header").classList.remove("scrolled");
    }, { threshold: [0,1] });
    
    scrollObserver.observe(document.querySelector("#scroll-detector"));</script>

    Pls try it and let me know

    • This reply was modified 2 months, 2 weeks ago by Gijo Varghese.
    Plugin Author Gijo Varghese

    (@gijo)

    I’ve also renamed the observer variable in Flying Pages to prevent conflicts with others. Just update to v2.0.9

    Hey Gijo, why aren’t you using an IFFE to remove any conflicts at all. Shouldn’t be using global space anyways?

    Plugin Author Gijo Varghese

    (@gijo)

    @pcfreak30 initially it was like that. But Swift Performance adds a try-catch (when you combine scripts) around our lib and function which removes the scopes and causes errors. That’s why I had to go in this way

    IMHO, I think that should be something Swift Performance should be solving as the workaround by you I think will cause more problems in the long run.

    Plugin Author Gijo Varghese

    (@gijo)

    @pcfreak30 I’ll definitely consider this. Will also contact Swift Performance guys if there is a proper way to solve this

    Besides if they did that, how are things in webpack and es6 stuff handled?

    Plugin Author Gijo Varghese

    (@gijo)

    @pcfreak30 I didn’t get. Do you mean browser support?

    No, the fact webpack/es6 stuff is bundling a ton of anonymous functions and IFFE’s together, that the logic/heuristics Swift Performance use would wreak havoc.

    Plugin Author Gijo Varghese

    (@gijo)

    @pcfreak30 most of the plugins/scripts use a single js file or inline script. In the case of Flying Pages, we’ve both to get it to work. Something like this:

    
    <script src="/flying-pages.min.js"></script>
    <script>flyingPages({...options})</script>
    

    If we add a try-catch or IIFE inside flying-pages.min.js, then it won’t be able to access beneath it

    You missed my point. I am saying the fact that a lot of applications/scripts use ES6 code which is basically webpack. So if they are doing this to your code, they would likely nuke any bundled js module or application, custom or public. So overall they are doing something that’s a bad idea from what I know so far.

    Plugin Author Gijo Varghese

    (@gijo)

    @pcfreak30 Got it.

    I just talked to Swift Performance guys. They’re removing try-catch! The update will be released probably tomorrow 🙂

    Hi @gijo

    Thanks so much for digging into this and providing various responses and effort to resolve. I implemented the observer tweak you provided, and updated your plugin successfully.

    The console log errors have now gone away, but how can I verify that the plugin is preloading the pages behind links? In my eyeball testing, I can’t notice much difference… and can’t see anything happening in DevTools. But I may simply not be looking in the right places…?

    What do you think?

    Plugin Author Gijo Varghese

    (@gijo)

    @lydenyardley Can you share the url of your site so that I can check?

    Sure – same is in my OP – https://yardley.me

Viewing 15 replies - 1 through 15 (of 18 total)
  • You must be logged in to reply to this topic.