Fields not showing after updating

[George]

Hello –

I just updated to v4.4.2. Prior to updating, my form worked great. Now, I can only see the tabs, and none of the fields appear. Additionally, when I create/edit/view an item, I keep getting the “This took forever!” message. This didn’t happen before I updated to this version.

Do you know what the issue could be?

Thanks.

Attachments:

1. 

   form.png
   

[Alexander Bautz]

I have had some reports of this related to using an older version of jQuery. Could you try bringing up the developer console by hitting F12 > Console and post any error messages you see there?

If you find any error messages I’ll do my best to get it sorted.

PS: I’m not sure this will make any difference, but please try replacing the “loader” folder with this updated version (see readme in the zip).

It’s getting late her in Norway so I’ll not be able to respond until tomorrow so I’ll suggest you roll beck to the previous version for now.

Alexander

[George]

The updated loader file worked. The only issue I’m having now is that I’m still getting the “This took forever!” message.

[Kasey]

We had some users that were having the same issue. Their default jquery version was 1.7.2. The attached updated loader resolved the issue for them. Thank you!

[George]

Here’s a screenshot of the error messages.

Attachments:

1. 

   Console.png
   

[Alexander Bautz]

This is most likely the jQuery incompatibility issue I mentioned. You can check which version of jQuery you are using by bringing up the developer console by hitting F12 > Console and type this:

jQuery.fn.jquery

My guess is that you have v1.7x or 1.8x.

I will add a fix for this issue in the next release (hopefully right over the weekend), but if you are able to update the local jQuery version to 1.12.4 (get it here) it will fix your problems.

If you cannot replace the the local jQuery version “globally”, you can try to edit the file “/SPJS/DFFS/loader/DFFS_loader.html” and add this line at the very top of the file:

<script src="https://ajax.googleapis.com/ajax/libs/jquery/1.12.4/jquery.min.js"></script>

Alexander

[George]

I added that line to the top of the file and that worked. Thank you for your help!

[Alexander Bautz]

Thank you for the feedback, I’m glad it worked out.

Alexander

[Colin]

We ran into issues with the latest version as well. We ended up reverting to restore functionality to our users. The issue we discovered before reverting was that bracket references (ex. {id}) were returning HTML span tags that included the expected value. The HTML qoutes caused early termination of DFFS functions and downstream issues from there. Do you suspect our issues are caused by the same jQuery version mismatch? When we upgrade we archive the entire DFFS folder from our site root and load in the the latest folders/files from the zip.

SharePoint 2013 On-Prem – JSLink

[Alexander Bautz]

Hi,
Regarding the HTML output – this is not a jQuery version issue, but a bug with how I have implemented the “live update” of changed values in headings and tooltips when referring a field from the list.

Could you tell me where you used the {id} reference and it came out as HTML so I can look into it?

Alexander

[Colin]

Hi Alexander,

Thank you for the quick response.

The reference was used in Tabs in a “Add HTML section” within “Visible fields and headings”.

Colin

[Alexander Bautz]

I tested and cannot get it to fail. Could you possibly post the entire HTML section contents so I can try to recreate it?

Alexander

[Colin]

Images attached.

Attachments:

1. 

   dffs2.png
   

[Colin]

Other image attached.

Attachments:

1. 

   dffs1.png
   

[Colin]

Here is the function:

function myOpenInDlgFunc(url){OpenPopUpPage(url,function(result){if(result === 1){
// dialog is closed with OK
}else{
// dialog is closed with X or cancel
}});}

[Colin]

HTML for one of the sections (scrubbed URL):

<div style=”padding: 10px 10px; margin-left: 80px “;><input type=”button” value=”View Documents” onclick= myOpenInDlgFunc(‘https://abc.com/Effort/Forms/AllItems.aspx?FilterField1=Effort_x003a_ID&FilterValue1={ID}’) ;return false;”></div>

[Alexander Bautz]

I see – I simply didn’t think of a scenario where you used the value as a parameter in a function call. I’ll rethink the approach I used to have the value updated when field value is changed. The obvious fix would be to change how this is handled when using the {ID} parameter as this is static, but if one wanted to use the value from another field in the same way it wouldn’t work.

My first thought is to use this format for a “static” value:

{ID}

and this for a “live” one (which is intended for use in a display mode and not including as a parameter in a function call:

{{ID}}

I’ll look into it and fix it in the next release.

Sorry for the inconvenience, and thank’s for the input.

Best regards,
Alexander

[Colin]

Hi Alexander,

Thanks for looking into this so quickly.

I for one think the {{}} option would be best as it preserves the {} for backwards compatibility, and allows for an update that does not require any changes to configuration.

If there ends up being a beta for the next release please let me know. We are eager to get the latest update in place as it resolves the e-mail ID issue that we identified.

Once again thank you for your great support and software!

Colin

[Alexander Bautz]

Hi Colin,
I’m sorry, but I completely forgot to add this to he last release. I’ll get it fixed later tonight.

Best regards,
Alexander

[Alexander Bautz]

I have now updated the files – see change log: https://spjsblog.com/dffs/dffs-change-log/

Please let me know how this works out.

Best regards,
Alexander

[Colin]

Hi Alexander,

I forgot to circle back with you on this one. The changes worked perfectly. We are good to go now.

Much appreciated,
Colin

[Alexander Bautz]

Thanks for the update.

Alexander

[Author]

Posts