WordPress.org

1. frontdesk
   Member
   Posted 2 years ago #

   I created a web contact WP template that uses a separate javascript file for form field validation routines.

   Since the javascript was only to be used on that single contact form (it is invoked via the form's SUBMIT event) I did not want to put the SCRIPT statement in my header.php file, so I tried placing the script file at the top of my contact form's BODY section...

   <script type="text/javascript" src="<?php bloginfo('template_directory'); ?>/scripts/wcontact-form.js"></script>

   ...and that worked very well EXCEPT that I noticed that if I ever made a change to the external .js file then some caching would occur and WordPress? would still be invoking an older version of the external .js file.

   I then verified that caching was occurring by inserting a time-of-day string at the end of my script statement, as follows...

   <script type="text/javascript" src="<?php bloginfo('template_directory'); ?>/scripts/wcontact-form.js?<?php echo time(); ?>"></script>

   ...and that got around the caching issue, but for some reason it caused my external javascript validation routines to no longer work properly, so I abandoned that route and did not examine further because I then read about wp_enqueue.

   According to the documentation I should be using the wp_enqueue_script function, so I then tried adding the following to the top of my contact form template...
   

   <?php
   $js_loc = get_bloginfo('template_directory')."/scripts/wcontact-form.js";
   wp_enqueue_script('wcontact-form', $js_loc);
   ?>

   ...but a subsequent test of my contact form showed that my form validation routines are now never invoked.

   How should I add an external javascript file reference to a single WP template - and one that avoids caching issues.

   BTW I have no caching plugins installed.

2. Otto
   Tech Ninja
   Posted 2 years ago #

   You should do it in the header.php file, before the call to wp_head();.

   Like this:

   if (is_page('my-contact-form')) { // change this to detect your page by slug or id
   
   $js_loc = get_bloginfo('template_directory')."/scripts/wcontact-form.js";
   wp_enqueue_script('wcontact-form', $js_loc, false, '1.0');
   }

   Every time you update the script, change the version number there (the '1.0') to a newer version. This version number is specifically there just for cache-busting.

3. frontdesk
   Member
   Posted 2 years ago #

   Thank you, Otto42. That "is_page" code snippet seems to work - although I could not test the versioning you mentioned because I don't know how to indicate a (source code) version inside my external .js file.

   In your snippet, though, you indicated to use '1.0' to reference the initial version of my external .js file. My current external .js file has no explicit version number indicated within it, so I am guessing it defaults to '1.0' and thus it matches the '1.0' in my wp_enqueue_script statement.

   However, I am unsure of the syntax within my external .js file to explicitly indicate a (source code) version number. Thus, if I subsequently make a (source code) change to my .js file code then do you know the syntax for tagging that .js file as version '1.1', for example?

   I am uncertain because whenever I googled on "javascript" and "version" it always referred to the system-wide version of the javascript libraries and not the source code version of some user javascript code.

   Do you know what explicit versioning syntax I use within my external .js (i.e., source code version) so that I can match it up with the version in my wp_enqueue_script statement?

4. Otto
   Tech Ninja
   Posted 2 years ago #

   I think you're not quite understanding me here.

   The actual version number is irrelevant. Whether there's a version in the JS file or not is also irrelevant.

   Make up a version number and use it in the wp_enqueue_script call where I indicated. When you change the script, change that version number in that call.

   What you change it to doesn't matter. What format you use doesn't matter. As long as the version changes, the script will get reloaded instead of loaded from the browser cache.

5. RockyMtnHi
   Member
   Posted 2 years ago #

   Note that while loading any javascript, whether included as a .js file, embedded in an included .php file or inline javascript code stops all other content from loading while the javascript is loading. If your javascript is lengthy then it can be a problem, both for usability as well as SEO - especially considering the Google Caffeine algorithm coming out after the holidays.

   More on the importance of page load times and how to speed them up:
   [link moderated]

6. frontdesk
   Member
   Posted 2 years ago #

   NOW I get it. You're saying that the use of "ver" in the wp_enqueue_script function is non-conventional in that it does not get matched with an explicit "ver" counterpart on the .js file.

   Seems like better nomenclature could be used rather than twisting the otherwise intuitive use of "ver". Maybe even a dashboard panel function where you see all elements that are currently being cached and can simply push a "reset cache" button for one or more elements currently residing in cache.

   Plus, with the existing implementation you now have the tail wagging the dog in that if I change an external javascript file I have to worry about tracking down all references to it in my source code (sure, any reference to an external .js file should - according to good practice - probably be limited to a single piece of source code, but that is not always the case).

   But, that's out of my purview anyway and I'm just happy to finally "get it".

   And thanks to RockMtnHi for the update on SEO implications.

Topic Closed

This topic has been closed to new replies.