A Consistent JQuery reference library calls with a simple solution

  1. Nihad Nagi

    Eventhough I have been a Joomla user for over than 6 years, and i almost mastered the tool, but WP made it very easily for all Joomla and other CMS users to tradeoff the benefits and initiate the transformation to WordPress.
    The purpose of this request is to ensure that today's number one remains the same tomorrow, and we as analysts and developers maintain our acquired learning curve instead of starting a new curve tomorrow with another tool (hopefully wordpress). So, thanks to all the people behind wordpress and all senior developers and analysts forming the community that nourishes wordpress and its functionality.
    In this part of my message, I would like to outline one of the most functionality critical feature and that is JQuery libraries referencing, which causes a functionality breakdown of plugins calling conflicting referenced libraries, which to the normal end user is a complicated task to identify and eliminate the conflict in any theme's code.Each and every plugin can call whatever JQ script they want in despite of previous and latter calls to the same library.
    Consequently, and only because am truly fond of wordpress, I started to think of a remedy that allows the flexibility and rigidity of the code and references.My idea is very elementary but can serve as a blueprint for subsequent wordpress updates, and simply:
    Lets assume that we have only a set of global variables for all JQ referenced libraries in a form of an index (holding an array consisting of a boolean indicating whether a previous call was made to the specific library and a real number holding the version number in case the the boolean was true, and with every new referenced or an existing reference is made the index array is checked either to update the reference to a newer library version or ignore the call if its to an older version, please note, we are just talking about a set of indexed variable so it would not alter performance and will ensure the rigidity of the code,and slight modification to the plugin development guidelines, only an IF statement i believe. I hope i made my point clear but this problem is unavoidable with the increasing number of plugiins and our inevitable shift toward mobile platforms.
    My best regards,
    Nihad Nagi

    Posted: 7 years ago #
  2. Ian Dunn

  3. Nihad Nagi

    As you know iandun, the wp_enqueue script loads a script, but to make my idea clearer, lets assume the following your main menu or your header loads a library say version 1.7.1, and later on the page another loads the same library version 1.6.1, this means that the first library reference is gone and therefore, the initial call made is gone causing a code break.The description of the enqueue function from wordpress is "A safe way of adding javascripts to a WordPress generated page. Basically, include the script if it hasn't already been included, and load the one that WordPress ships.", note that "if it hasn't already been included,....". The remedy we do is a detailed script look-up and use the .noConflict function, is that a user friendly (normal user) procedure, bearing in mind, that one of wordpress main pros is ease of use to that normal user, beside even for a code experienced developer identifying the conflicting script in theme files and sometimes the loaded plugins, which normal user would start a trial and error procedure of activating and deactivating plugins, which, if you refer to forums is a very common issue for JQuery based library.

    Posted: 7 years ago #
  4. Ian Dunn


    I'm not sure I completely understand your description of the problem or your solution. Are you saying that you want to be able to run multiple instances of jQuery on the same page? For example, plugin X relies on v1.5 and plugin Y depends on v1.3, but neither of them is capable of using the latest version, so you want to have both v1.3 and v1.5 running at the same time, instead of both using a single copy?

    I can see how that would avoid some conflicts, but I don't think it's the best solution. It would mean visitors have to download two very large files and run them in memory, when only one should really be necessary. The proper solution would be for both plugin developers to make their plugins compatible with the latest version of jQuery.

    The core team has limited time and resources, and there are much bigger issues than this one that don't get done. I think in this case it's the responsibility of plugin developers to keep their plugins current, rather than making the core team clean up after ones that don't.

    Posted: 7 years ago #
  5. Nihad Nagi

    No, its the other way around, what i am suggesting will not cause functionality breakdowns because of multiple instances of libraries loaded and will boost performance as no multiple instances of the same library of different versions are loaded.
    So, I will make myself clearer by a more thorough description.

    The only conflict i faced, not only me, but so many people have complained regarding the malfunctioning of JQ effects like sliding or accordion effects for instance, check out the forums and you will get an idea of how this is causing an issue to many users.Lets go through a practical example of a problem i encountered, the header loaded a certain library say version 1.6.x for the sake of the menu, and later on the same page, another plugin , unregistered and registered and loaded say version 1.5.x, in this case its a forward incompatibility issue, if its the other way around there will be no problem because all libraries presents backward compatibility, so if the scenario was the other way around, there would have been no problem, but in the given scenario of the forward incompatibility the header wouldn't function as expected.This is one issue, the normal procedure would be using the .noConflict function but as you already know that would cause a poor page performance because of multiple instances redundant loading. The importance of the issue from my own perspective of course, is for now and the future. For now, because inexperienced users find themselves with one option if implementing what they want, and that's flash plugins, in respect to menus, widgets and most of UI effects, which is not as efficient as JQ, regarding performance, and let's not forget that performance affect your Quality score and your SEO efforts, and consequently your success, if you are targeting commercial success, and also note, that one of the main advantages of wordpress not only as a blogging tool but as a CMS as well, lies in its ease of use for the inexperienced user, and second, as we are moving to the mobile platform officially starting from the 4G, then JQ is our only option to deliver high quality and sophisticated content that's also lightweight. Now regarding my solution or proposal, is as follows:
    Lets assume we will develop a table or an index to be more specific of global variables to be accessible from anywhere within the code, this is only an index, an index of all available JQ libraries, so the first field of the index would be the name of the library, and the other two fields would be a boolean, and a version number as the third and last, so lets see an example of what i am suggesting, lets say that jquery menu library ver. 1.6.x calls to be registered, the globals are checked whether its been loaded before or not,as in this example, so the boolean variable. as in this scenario, would return false, so WP loads the library, and sets the global variable for this library in the index file to true and set the version number to 1.6.x, so in any subsequent calls to the same reference library, the version is intrigued and compared to the one in the index and that would be the 1.6.x, if it was an earlier version, the call would be ignored as the loaded library will present the backward compatibility with the earlier version, and if the call is to a more recent version say 1.7.x, then the current loaded library in memory is unregistered, and the new version is loaded and the index is updated with true,version 1.7.x.This will ensure that no library is ever loaded twice in the memory, therefore, no garbage collection needed because we are acting proactively by eliminating garbage or waste instead of re-actively collect the garbage, therefore, this will boost performance in load time, therefore, better seo and page rank, the targeted inexperienced users will not avoid or waste their time in trial and errors to fix whatever was dysfunctional by activating and deactivating new active plugins sacrificing a needed functionality, so to recap the pros:

    Maybe the proposed solution is not optimal, but from my perspective as a lead myself, is that simple but effective solution, that might not be final and can be optimized by various other input, but the baseline is that it can serve as a blueprint or a starting brainstorm idea that can be enhanced and optimized.

    One last point, your concern that the guidelines for the plugins should abide plugins developers, but we are concerned with the ends and not the means,lets walk in their shoes, as a plugin developer, i only care about the functionality of my plugin to my targeted segment, the platform performance is not their concern, or from their viewpoint is justified. What i am suggesting was based on a personal experience with JQ libraries and their conflicts, and me myself spent more a prosperous portion of time root causing the mishap, solved it in the development phase, in which your main concern is the functionality of your product, but in the deployment phase, where your concern is performance, you will discover that the quick fix applied in the development phase created a bigger problem later on the deployment phase. You might get the big picture if you are providing media rich content, go to "http://pingdom.com" to test your load time or choose any website you like, and you will see that the majority of the page size is redundant scripts. We counteract the performance issue with caching techniques and CDNs, its like saying "waste management" versus "garbage collection", the latter addresses how efficiently we collect the garbage, but the former addresses why was waste created in the first place, its the two schools versus each other, the proactive versus the reactive, and history in all fields revealed that the former and who ever followed it was the winner.
    But again, all of that is regarding performance and its counteract, but what about reliability and usability, and one other aspect is a strategic competitive advantage to tomorrow's computing:mobile computing, we might debate on this one, i agree but i guess we cant debate on the other two.

    And my proposed solution is very similar to the basic concept of caching.

    I am very grateful for your comment and your time, and forgive me on this one, i just agree with you that i wasn't descriptive on my former, so i hope i am on this one. Thanks Iandunn, and thanks to anyone who got the patience to be reading this line, and its and the community support that will make this wonderful platform sustain.Please don't hesitate to seek any further explanations i might not made clear.
    My best regards

    Posted: 7 years ago #
  6. Drew Jaynes

    As of a few releases ago, core enforces only enqueuing the bundled version of jQuery in the admin. To do so on the front-end would be taking a bit too much initiative in the realm of themes. So this has been partially implemented as far as core is willing to reach.

    Thank you for the suggestion.

    Posted: 3 years ago #

RSS feed for this topic


You must log in to post.

  • Rating

    4 Votes
  • Status

    This idea has been implemented