• Resolved hommealone

    (@hommealone)


    I have a file (custom.js) which I enqueue with a version number made from the file timestamp. It normally looks like this:
    <script src='https://coherencecollaborative.com/cc/wp-content/themes/insite-starter/inc/assets/js/custom.js?ver=1623097470' id='insite-starter-custom-js-js' data-script-handle='insite-starter-custom-js'></script>
    The version number normally forces browsers to refresh that file whenever (but only) when the file is changed.

    WP Optimize seems to be stripping out the version number all together.

    I’ve excluded that file from minification like this:
    */wp-content/themes/insite-starter/inc/assets/js/custom.js*
    (I’ve tried with and without the trailing asterisk.)

    But the timestamp version number still gets stripped out.

    I do the same thing with the theme’s main CSS file. I’ve excluded that file too, and the version number is not stripped from the css file:
    <link rel='stylesheet' id='insite-starter-style-css' href='https://coherencecollaborative.com/cc/wp-content/themes/insite-starter/style.css?ver=1624646169' media='all' />

    (The website is installed in a sub-directory ( /cc/ ) but displayed in the root. That’s why I’m using the leading asterisk in those exclusion rules.)

    Is there any way to stop WP Optimize from stripping that version number from the js file? Am I doing something wrong?

    If it is not possible to keep the timestamp/version number, and I still want to be sure that the file is not cached after it has been edited, am I better off not excluding the file, and (manually?) clearing the minify cache whenever I edit it?

    Any advice appreciated! Thanks.

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

Viewing 10 replies - 1 through 10 (of 10 total)
  • @hommealone Could you please remove the leading asterisk from the file path when you add the file path to exclude list and check if it helps to fix the issue?

    Plugin Author David Anderson

    (@davidanderson)

    What leads you to the conclusion that WP-Optimize does this? There’s no feature related to that that I can think of. Does it stop happening if you de-activate WP-Optimize?

    Thread Starter hommealone

    (@hommealone)

    Thank you both for your quick responses – much appreciated!

    @bornforphp – I removed the leading asterisk, and then cleared all caches. The version number is still being removed. I’ve now tried every variations of leading- and trailing-asterisks, and no asterisks, but the version parameter is always removed.

    @davidanderson – The version parameter is present when the WP Optimize plugin is de-activated. I also have the setting selected to “Disable minify for logged in users”, and the cache setting de-selected for “Serve cached pages to logged in visitors.” So when the plugin is active and I am logged in, and when I view the page source, the version parameter is there.

    Perhaps worthwhile restating: our main CSS stylesheet also uses the same kind of file timestamp/version parameter. I have excluded that CSS file from minification too, and the version parameter DOES show in the “view source” page code for the CSS file. Curious, right?

    (BTW, all CSS and JS resources are enqueued according to WP standards, including some – jQuery, Bootstrap, Font Awesome, Typekit – that are loaded from CDNs.)

    What other troubleshooting steps might I try?

    @hommealone Could you please try to uncheck the option “Enable merging of JS files” from WP-Optimize > Minify > JS and check if it helps to fix the issue?

    Thread Starter hommealone

    (@hommealone)

    @bornforphp Thanks for the suggestion. I’ve done that, and it didn’t fix the issue. Any other suggestions?

    @hommealone

    Have you performed a conflict test yet?

    If not – first, please make a full site backup.

    Then, temporarily revert your theme back to the default WordPress theme (Twenty20) and see if the problem continues. If it is gone, the theme you were using is the cause.

    If the issue is still there, try deactivating all plugins except for WP-Optimize and see if it is resolved.

    If so, reactivate each plugin one at a time until you find the culprit. You can check for the issue between activating each plugin, so you can see which one is causing problems.

    Please let us know your findings.

    Thread Starter hommealone

    (@hommealone)

    @bornforphp Thanks for this suggestion, and for sticking with this thread. The “conflict test” approach seems to be the fallback for plugin authors when they run out of other suggestions – no offense meant! (insert smiley wink here)

    This is a great approach for people who have a staging environment for testing, but lot’s of people (the vast majority of websites, I’d guess?) have only a live site, making this approach difficult. And for many, you can’t simply switch themes like trying on a different jacket. A lot of functionality is built into the theme.

    Are you suggesting that I disable first the theme, then the plugins – one by one – and test at each step? That would also require clearing all of the caches between each test step as well, right? Wow!

    I’ve been using this plugin on most of my new sites, where I once would have used WP Super Cache or W3 Total Cache, and enjoying it. But it might be easier for me to simply try a different caching plugin now, instead of the “conflict test” approach.

    With all that I have detailed earlier in this thread, it seems clear to me that the problem comes, somehow, from WP Optimize, conflict or not. Isn’t it better to have a plugin that simply doesn’t conflict with other plugins or themes wherever possible?

    Before that…

    This is how I enqueue the script that’s losing its version parameter. Anything here that seems troublesome?

    
    /* load our theme's custom.js file with a file timestamp to update it whenever it changes */
    wp_enqueue_script( 'insite-starter-custom-js', get_template_directory_uri() . '/inc/assets/js/custom.js', array('jquery'), filemtime(get_template_directory().'/inc/assets/js/custom.js'), true );
    

    (Again, this DOES work with our main CSS file, which is enqueued the same way. The CSS file does not lose its version parameter. I don’t understand how it could work with one file, but not the other.)

    @hommealone I’ll check this issue with our development team and update you, as this is the first case we have encountered in past years.

    Thread Starter hommealone

    (@hommealone)

    I’ve marked this thread as still unresolved. The version number is still being removed from the script, and your development team has not updated me.

    @hommealone We will update you as soon as we hear back from our development team

Viewing 10 replies - 1 through 10 (of 10 total)
  • The topic ‘stop removing version’ is closed to new replies.