inline javascript can it go in a file?

  • Resolved Jon Scaife

    (@jonscaife)


    4 years, 6 months ago

    Hi

    I notice that the plugin puts quite a lot of javascript into the page footer inside a script tag. If possible I would prefer to have this in a dedicated file. At the moment I have had to allow inline scripts in my content security policy to allow this. It also means it increases the size of every page that is loaded. Is it possible to move this script into a .js file rather than having it inlined?
    Thanks

Viewing 13 replies - 1 through 13 (of 13 total)
  • Plugin Author Hector Cabrera

    (@hcabrera)

    Hi @jonscaife,

    Yes, that’s needed for a few things but it might be possible to move that into a JS file.

    The plugin also outputs some inline JS on the <head> section of your website though. That one is unavoidable and can’t be moved into a JS file so I’m not sure if WPP will ever be able to comply with your No Inline JS policy.

    Thread Starter Jon Scaife

    (@jonscaife)

    Hi Hector

    Thanks for replying so swiftly. The less the better, so this is a great start. Would it be possible to update the plugin to make this change? – I imagine if I adjust my local copy myself it myself it will just get over-written at the next update?

    With regard to the short piece of javascript in the header – it looks like this just sets some variables. Would it not be possible to do this as JSON data that is then parsed by the javascript in the .js file? That would then avoid any inline javascripts – which is useful with the growing prevalence of “content security policy”.

    Cheers

    Plugin Author Hector Cabrera

    (@hcabrera)

    Would it be possible to update the plugin to make this change?

    Yep, it’s doable but not a high priority right now so I wouldn’t hold my breath.

    I imagine if I adjust my local copy myself it myself it will just get over-written at the next update?

    Correct. When WordPress updates stuff (parent themes, plugins, and core files) it basically replaces all files & folders with the news ones. All of the modified files will revert back to “stock.” The only exception to the rule would be child themes and that’s precisely because child themes never get automatically updated by WordPress.

    Alternatively, you can also just fork the plugin, rename it and change it however you see fit. That way you won’t have to worry about official updates overwriting your modifications.

    Would it not be possible to do this as JSON data that is then parsed by the javascript in the .js file?

    Off the top of my head: browsers caching the json file for longer than 24 hours will affect WPP’s ability to track visits reliably. If it turns out that you’re also using a caching/file minification plugin then we’re adding another layer of complexity, making debugging slightly more difficult.

    This would also introduce a new file for the browser to load on each page load which may have an impact -if only minor- on page loading times. Users obssessed over getting good PageSpeed Insights/GTMetrix scores certainly wouldn’t appreciate this.

    Seeing that this would cause more headaches than benefits I honestly doubt I’ll ever implement this.

    Finding a good balance between performance, reliability and security isn’t a simple thing, is it? ??

    Thread Starter Jon Scaife

    (@jonscaife)

    Hi Hector

    Thanks for providing more information on this. I think I should split my reply into 2 parts…

    1. The JS in the header – this seems to be just variables, which are presumably read and used by the JS loaded elsewhere (be that in a file or inline in the footer). Couldn’t those variables be specific as JSON variables – still inline but just not in a javascript tag – as described here -> https://itnext.io/inline-data-with-a-content-security-policy-ab30dde2feb3

    2. The JS in the footer – presumably this could just be moved into a JS file and loaded from that instead of being inlined? Doing so would be much better for SEO and page loading speed – an extra external file is always preferable to inline script because the file can be cached and so is only loaded once, whereas inline script has to be transfered with every different page loaded. The file wouldn’t have to be loaded on every page load – once it is cached by the browser it would be there and available. Unless I’m mistaken it looks like the bit of code that varies is the part in the header, not the part in the footer? If that is the case then users obsessed with good pagespeed insight / GTMetrix scores would much prefer it be in an external file than it be inlined, especially if the external file is properly queued using the wordpress script enqueue system. Enqueued external JS files can easily be concatenated and served as a single JS file for the site which is only loaded once and can even be pushed with HTTP2. None of these sorts of optimisations are easily available with inline JS.

    I assume the JS somehow pings the server to tell it there has been a visit, and what page the visit was to? Surely it can still do that without being loaded from the server each time?

    Whilst I absolutely agree finding the balance between performance, reliability and security isn’t easy, I think in this instance both of my suggestions would improve security and performance with no downsides. I appreciate that they are not a priority though so I will investigate implementing them myself. If I am able to do so successfully would you be interested in implementing them in an official release?

    Plugin Author Hector Cabrera

    (@hcabrera)

    Couldn’t those variables be specific as JSON variables – still inline but just not in a javascript tag

    Not sure if it’s doable (WPP uses the official APIs to output these variables, not sure if these functions can be modified via hooks or something) but it’s interesting and worth exploring so thanks for sharing.

    The JS in the footer – presumably this could just be moved into a JS file and loaded from that instead of being inlined?

    Yep, it can be done. This was mentioned on my previous comment, sorry if it wasn’t obvious but this is what I was referring to.

    I assume the JS somehow pings the server to tell it there has been a visit, and what page the visit was to? Surely it can still do that without being loaded from the server each time?

    The one on the header section of the page does, and needs a valid security token each time in order to be able to updates the views count of the current page. Said token expires every 24 hours or so, hence the reason why this part needs to stay somewhat dynamic.

    The one on the footer -from memory, not near a PC now- won’t likely change so it can be moved into a JS file.

    If I am able to do so successfully would you be interested in implementing them in an official release?

    Absolutely!

    Plugin Author Hector Cabrera

    (@hcabrera)

    Update: since I couldn’t stop thinking about it and had nothing better to do, I went ahead and implemented the inline JSON script tag on my local version of the plugin following your recommendation and had no issues with it. Everything still works. Had to resort to a bit of a “hacky” approach though but it works.

    I’m a bit torn though because while implementing this change would be great for CSP I’m also a bit worried about compatibility with future versions of WordPress: the WP team may change some stuff internally which could possibly result in breaking the “hack” completely, forcing Future Me to revert back to the regular JS version.

    I’ll give this some more thought (and testing, and research) and decide later what to do next.

    Thread Starter Jon Scaife

    (@jonscaife)

    Hi Hector
    That’s fantastic. I really appreciate you looking at this. Perhaps a way around the concern about wordpress changes would be to have code for both ways of doing things in the plugin, and to have an option – which defaults to the current method, but allows a site operator to use the JSON method if they want. Could even be a filter rather than a GUI option to discourage casual users from potentially breaking things. The default would then always work, but users would have the option to tinker if they wanted.
    Anyway, whatever you decide I appreciate your efforts and thoughts on this.

    Plugin Author Hector Cabrera

    (@hcabrera)

    Hey @jonscaife,

    I’ve managed to remove every single inline script tag from the plugin (at least the ones from the front-end side of things) and everything -apparently- seems to be working normally.

    Can’t share anything yet though, all of this has been done on my local environment and work + life have kept me from resuming plugin development work in the past couple of weeks. I’m merely posting this update here in case you (and anyone else reading this) were wondering about it.

    Thread Starter Jon Scaife

    (@jonscaife)

    Hi Hector

    that’s brilliant news. Thanks for the update. I completely understand the work + life thing, I’ve been too busy to look at it myself so just grateful you’ve got as far as you have. I look forward to another update when time permits.
    Cheers

    Plugin Author Hector Cabrera

    (@hcabrera)

    Hi @jonscaife,

    So yesterday I had a day off and used it to do some more testing and fixing. Pushed these changes (and some others) to WPP’s Github repository in case you’re curious / want to test them out.

    Thread Starter Jon Scaife

    (@jonscaife)

    Hi Hector, that’s great, yes, I will give them a test, thanks!

    Thread Starter Jon Scaife

    (@jonscaife)

    Hi Hector

    The version from GitHub works fantastically. With it my site is faster AND I can use a strict CSP. It still seems to function fully as before. Thank you very much. I hope these changes make it into the next full release. ??

    Plugin Author Hector Cabrera

    (@hcabrera)

    Awesome, thanks for the update Jon! These changes are already part of the main codebase so they’re not going anywhere (unless something catastrophic happens haha). I will release WPP 5.2 soon, so thank you for testing and for your suggestions!

Viewing 13 replies - 1 through 13 (of 13 total)
  • The topic ‘inline javascript can it go in a file?’ is closed to new replies.

Tags