Updating jQuery Version

OpenEMR Development
1

yehster wrote on Tuesday, October 04, 2011:

https://github.com/yehster/openemr/commit/a23f3e34e5410f4cdd61f3304b9e0900a8c3e699
https://github.com/yehster/openemr/commits/jqueryUpdate

I think we should start upgrading from the 1.2.2 version of jQuery.  I have a branch here which updates to 1.6.4 in what I think are 3 key locations, demographics.php (since there seem to be ajax issues) left_nav.php (since that’s a frequently used file) and the calendar.

Thought I’d get this started, but not sure how to proceed.  At the very least, if people want to try updating on their own systems this will get it started.  Not sure it’s the right time to do it for the 4.1 patch as this is kind of a big change.

2

bradymiller wrote on Wednesday, October 05, 2011:

Hi,
Committed this to sourceforge (master branch). Agree not to place in the 4.1 patch unless it both improves performance (especially the Patient Summary page) and it gets adequate time for testing.
thanks for the contribution,
-brady

3

mcaloon wrote on Wednesday, June 27, 2012:

Hello,
    I have been adding some new Jquery stuff for the UI on the external dataloads page that includes jquery-1.7.2.min.js and jquery-ui-1.8.21.custom.min.js as well. In doing this I snooped around and noticed we have a number of versions of jquery being used in a number of places in the tree. I agree with Brady that we need to ensure adequate test time if (when) we do anything. That being said Yester’s point about upgrading from the older version of jquery could actually be restated that we might want to migrate all the jquery code to a consistent version at some point. Although not right now as I don’t have the time to test everything :slight_smile:

Mac

There are a number of cases where individual js components are included in a variety of areas along with a couple of the ui libraries. But here are the main js library files and their checksums:

ec359c2c0c0a835c4987471a3e069df2 library/js/jquery121.js
b64321e413f516b5d547b882dac02682 library/js/jquery-1.2.2.min.js
bb381e2d19d8eace86b34d20759491a5 library/js/jquery.1.3.2.js
10092eee563dec2dca82b77d2cf5a1ae library/js/jquery-1.4.2.min.js
e4958bd2e32d9fcd6115a585ed17a9cc library/js/jquery-1.4.3.min.js
847945778a448af8cd0af49c4e69a6ee library/js/jquery-1.5.js
9118381924c51c89d9414a311ec9c97f library/js/jquery-1.6.4.min.js
b8d64d0bc142b3f670cc0611b0aebcae library/js/jquery-1.7.2.min.js
ec359c2c0c0a835c4987471a3e069df2 library/js/jquery.js
4bab8348a52d17428f684ad1ec3a427e library/js/datatables/media/js/jquery.js
4

sunsetsystems wrote on Wednesday, June 27, 2012:

I think best to include only the current jquery library, named just jquery.min.js (without the version number).  Whoever does that would of course need to do careful testing.

Rod
www.sunsetsystems.com

1 Like
5

mcaloon wrote on Wednesday, June 27, 2012:

a symlink from jquery.js to the named version file might be helpful for simple newbie review of where we’d be at…. agreed a substantial testing effort is required

6

mcaloon wrote on Wednesday, June 27, 2012:

just for grins, the main jquery.js file that is *everywhere* (as yehster had noted is 1.2.1) per the checksums listed above…

Mac

7

yehster wrote on Wednesday, June 27, 2012:

On my own system, I just deleted all of the old jQuery versions and turned them into symbolic links to 1.7.2. 

It won’t really constitute adequate testing, but I’ll keep an eye out for anything weird as a result.

8

mcaloon wrote on Wednesday, June 27, 2012:

Yeah, the references to older versions are sprinkled all over the place. As Rod suggests we could have all the php source refer to jquery.js and we can symlink to the one “production” version from there… that would help for future migration to new versions being done at the file system level…

Mac

9

yehster wrote on Wednesday, June 27, 2012:

There is also another copy in:

/library/js/jquery.treeview-1.4.1/lib/jquery.js
10

pfwilliams wrote on Thursday, July 18, 2013:

In addition, the following two files ought to be renamed (and references updated):
\library\custom_template\ckeditor_source\adapters\jquery.js
\library\custom_template\ckeditor\adapters\jquery.js

They are not versions of the standard jquery library. Instead, they are a few user-created custom functions. It appears current naming conventions would imply they be named something like:
\library\custom_template\ckeditor_source\adapters\jquery.CKEditor.js
\library\custom_template\ckeditor\adapters\jquery.CKEditor.min.js

11

mdsupport wrote on Thursday, July 18, 2013:

If it is a external project/package, it may be better to leave it untouched.

Is it possible to move these add-on packages in a separate directory? Currently library is a mix of openemr code and other packages like ckeditor, jquery while phpmyadmin is somewhere else.

If we want to use ckeditor internally, we do not want to invoke it from ‘custom_template’ which could have modified the code.