Centralized JavaScript Management

  1. Greg Bellucci

    Plugin and theme developers (including myself) often include "common" JavaScript framework code they use with their plugin or theme. For example, prototype.js is a popular JavaScript framework that is often included either in the plugin admin code, the end-user's page or in a user's theme. If you are using multiple plugins (and who isn't) that make use of these "commonly included" scripts you'll often find that the JavaScript framework is included multiple times. More often than not, these scripts are different versions and that can lead to some very weird and ugly problems with page behavior.

    The following is a programming paradigm suggestion that could be implemented very easily. A set of core Word Press function calls could be developed for managing any arbitrary set of "commonly" included "things" - in this case, java scripts but it doesn't have to be limited to just one type of "include". Only two function calls are necessary: register_script() and is_script_registered().

    register_script() would be used by plugin authors to "register" the name of a script they intend to include in the output code. Function arguments would include the name of the script (for example: prototype.js or jquery.js), the major release number, and minor release number. Word Press would only be responsible for adding this information to a table. (Script path information is not necessary.)

    is_script_registered() would be used by plugin authors to determine (at the time the plugin is initialized) if a script has already been registered by a previously initialized plugin or by the theme. If the script (along with the same major/minor release information) is present then the script would not need to be included. The presumption here is that the plugin or theme that registered the script would include it.

    If the script is not in the table, the plugin can safely register the script and include it in the output. The return from this function would be NULL if the script in question was not registered OR it would return the script name, major release and minor release (in the form: "script name", major release number, minor release number). Returning the script details would give the plugin an opportunity to examine the version information to determine if it should continue.

    "But my plugin won't work if the version I want to register is newer than a previously registered script with the same name".

    This is where the "fun" begins in software development - working out the issues. This proposal is based on a “first-come-first-serve” concept. At the very least, a plugin that is dependent upon a script version can be a "Good Samaritan" and disable itself, output something intelligent to the screen or place a breadcrumb comment in the output HTML.

    I didn't intend to work out all the issues and conflicts here but I did want to put this idea out there. I can’t be the only one that has encountered this problem. For example, Alex King wrote a nice little plugin called "Share This". The plugin includes "prototype.js". Prototype.js is already included by the K2 theme. Because there was a conflict in versions, I had to comment out the "include" statement in the "Share This" plugin to get things working properly with my K2 theme. If you are not a developer then these kinds of issues can turn you off to plugins, themes or even Word Press.

    As an alternative, perhaps plugins shouldn’t include a script that the user could easily get from its publisher. Just direct the user to get the script and advise them as to where to put it.

    Alternative 2: Maybe there should just be a “standard” JavaScript include directory in the Word Press directory structure. Just as there is a plugin directory. The wp-includes/js directory already contains prototype.js and scriptaculous.js. Perhaps plugin and theme developers should include the versions provided.

    Just a thought....

    Posted: 11 years ago #
  2. m0n5t3r


    what's wrong with wp_register_script and friends (wp-includes/script-loader.php)?

    Posted: 11 years ago #
  3. Greg Bellucci

    Well? I completely missed the introduction of the script loader code. It must have been added in the 2.1 release. Thanks very much mon5t3r for the heads-up. I will take a look at it... actually, I think I'll take a harder look at *all* of it (again). If the script loader can be used to prevent multiple inclusions, I think everyone developing a plugin or theme that includes the common framework scripts should be using it.

    Thanks again.

    Posted: 11 years ago #
  4. mozey

    i KIND of see where your getting at!, But i think this is a symptom of a bigger issue!.

    Posted: 11 years ago #
  5. maesterkinoc


    hmm I think it well would be a good idea to have like plugins who have java scripts with them sort send all the java script to one source or one place, sometimes when you use a combination of different plugins you get so much java script in your mark up and it just gets messy (though it is valid)

    Posted: 11 years ago #
  6. vipersdream

    So how does this work exactly? I am having some javascript conflicts (functions working and then not working when I install a plugin with javascripts.) Is there any guide out there on how to make this work?

    Posted: 10 years ago #

RSS feed for this topic

Topic Closed

This topic has been closed to new replies.

  • Rating

    36 Votes
  • Status

    This idea has been implemented