Home › Forums › Classic DFFS › Javascript error in spjs-vLookup_frontend
- This topic has 5 replies, 2 voices, and was last updated 4 years, 5 months ago by Alexander Bautz.
-
AuthorPosts
-
-
June 12, 2020 at 00:49 #30614
I have installed onto an on-premise SharePoint 2010 environment.
I have updated the installer file to reference the local copy of jQuery.
(Question: why is there a local copy of JQuery added into the plugins, yet the installer files and elsewhere then link to Google’s hosted jQuery? Doesn’t this load up the library twice? Is there a reason and is it related to my issue below?)When I first installed everything for some reason it didn’t pick up my site name and the DFFS links on every list I added did not include the site prefix. I briefly just edited each link and got things working to a degree.
I have DFFS installed in /SPJS/DFFS from the main site and my dffs_folder_location is set to “current”.
I then decided to start again and re-uploaded the latest DFFS version (I was on 4.4.4.32 and switched to 4.4.5.0). I also totally removed all code for my lists and re-installed the admin page. This resolved the issue of not recognising the site.
However, I am now getting an error in the vLookup plugin code. (sorry, not permitted to upload screen caps)
uncaught TypeError: cannot read property 'indexOf' of undefined at HTMLTableRowElement.eval (eval at ..... /SPJS/DFFS/spjs-vLookup_frontend.js:NaN), ...:1:11233)
This causes forms not to load.
I created a new empty list with no vLookup and the issue was still there as soon as I added DFFS forms to it. The issue occurs regardless of library version.
I have isolated the issue to the vLookup code by commenting out reference to the vLookup plugin in the loader.
Questions:
1. Is this a problem with the vLookup plugin or is this part of my botched initial setup?
2. Is there a way to clean out any configuration apart from through the DFFS Installer Admin page?
3. What is the correct set-up of JQuery for on-premise? Why the external library link when you link to local copies elsewhere, yet the on-premise workaround is to link to the local copy? -
June 12, 2020 at 08:12 #30616
Hi,
I don’t currently have a SharePoint 2010 environment available for testing so I cannot reproduce this issue.Regarding the vLookup error: If you are not already using Google Chrome, please test it again in this browser and click the link to the right of the error message (1:11233 and then click { } in the bottom left corner to “pretty print” the minified code to see where in the code this error originates from.
Regarding the jQuery library: This is linked from code.jquery.com in the Installer_CEWP_code.html to ensure the installer works without the need to edit the file to change the link to the local /SPJS/DFFS/plugins folder in case it is not installed in the root of the site collection.
When you install, it links to /SPJS/DFFS/plugins/jquery.js and this is the version that is used in the “frontend”.
The DFFS configuration is stored in a list in the current site named SPJSDynamicFormsForSharePoint so in addition to the “Delete” button in the DFFS configuration for a specific form you can remove the config by deleting the item in this list.
If you don’t want to use the the external jQuery file in the installer you can edit the Installer_CEWP_code.html and change the link to jquery as noted in the comment in the top of the file.
Alexander
-
June 15, 2020 at 01:04 #30659
Alexander,
Firstly, thanks for explaining the jquery setup and assuring me I’ve done the right thing there.
I wasn’t aware of that pretty print trick. Using that I was able to isolate the issue.
It related to the creation of an attachments row for list attachments. Even though I turned off attachments to my lists, for some reason this row gets created in the form, being part of ‘spjs_formtable_row’ but not having a ‘fieldinternalname’ attribute, and it’s this which causes the error.
The code:
jQspjs(".spjs_formtable_row").each(function(i, a) { var b = jQspjs(a).attr("fieldinternalname"); if (b.indexOf('vLookup') === 0) { ...
The error line was the third line above. I was able to fix the code by inserting
a check at the start of the if condition for the fieldinternalname attribute so that it is nowif (a.hasAttribute('fieldinternalname') && b.indexOf('vLookup') === 0) {
Thanks for your prompt reply.
-
June 15, 2020 at 21:16 #30674
I wasn’t aware of this bug – and cannot reproduce it either, what version of DFFS are you running?
Alexander
-
June 16, 2020 at 01:16 #30680
Alexander,
I’m running the very latest version as stated above, 4.4.5.0. I cannot be sure if it’s a SharePoint 2010 thing only but it creates a row for list attachments without the “fieldInternalName”. I applied a pretty benign fix that says only look for “fieldInternalName” starting with “vLookup” where there exists an attribute called “fieldInternalName”.
I’m hoping that you apply the patch even if you can’t reproduce it (based on the logic above) because trying to fix the minimised file is difficult and I don’t want my code to blow up if the library is updated in future. I’m holding off fixing the minimised file until you confirm a fix or not.
Chris.
-
June 16, 2020 at 09:58 #30684
Ah, sorry – I forgot you already had mentioned the version. I think this must be a SP 2010 issue. I’ll address this missing attribute in the next version – hopefully during this week.
Alexander
-
-
-
AuthorPosts
- You must be logged in to reply to this topic.