Eulogio, can you share any more information about the way you’re loading jSignature into Skuid? Is there a ‘format’ parameter jSignature needs? If so, where’s that coming from?

---

ON the skuid releases page, there is no install link for 11.1.1

---

There was a SFDC bug that caused significant problems with 11.1.1.   We removed the package until SFDC fixes the problem on their end.  More information about the issue can be found here:  https://community.skuid.com/t/challenge-with-11-1-1-version

We are targeting releasing an updated package today… 

---

I have the jSignature package stored as a zipped static resource in Salesforce. I initialize my signature components on pageload via a component snippet and call my jSignature methods here. I was never using a ‘format’ parameter before, not sure what parameter the error message is referring to.

For some additional context, here are some screenshots of the error I’m seeing and what the debug console shows for those initial 2 errors:

---

Hi Eulogio, 

Since this error message is being thrown by jSignature, have you looked for any further information on what the error means? A bit of Googling leads me to believe that jSignature isn’t getting the data in the right format (see here for example, and the best answer there provides a link to a lot more detail). If the data is in the wrong format, (if the above link is relevant: base 64 vs base 30, for example), then the next question is, where is jSignature getting its data from, and what has changed? 

---

I’m feeding jSignature data from SF records which store my signatures. jSignature hasn’t been updated in about 5 years and the data I’m using in my model hasn’t changed in a few years either, so I don’t think it’s any updates that I’ve done that is causing problems.

The errors popping up here are also popping up in other Skuid pages I had built at least a year ago:

---

Eulogio,

I understand that there haven’t been changes to jSignature or the model data. When we run into inter-operability issues like this between different packages & plugins, it can be tricky to find exactly where the pieces are failing to integrate. 

I’m thinking that perhaps jSignature was looking for a Salesforce field that’s no longer loading before pageload. If your jSignature component is loading on pageload, but the data that’s providing the signature itself is being loaded client-side, then the component may be looking for the signature before its model has loaded. Can you check any relevant models to see if they’re being loaded client-side?

If so, one test you can try if you’re comfortable with a bit of console scripting is to run a command to re-render your custom component once the page has been completely loaded. To do this, find out your custom component’s unique Id, then enter the command skuid.$C(‘your-component-id-here’).render() into your browser console to force it to render. If the issue is that the model data isn’t ready in time for the component, then trying this should let the component render successfully.

Edit: If you find that the model data is loading too late, then try setting the model so it does NOT load client side. 

---

Thanks for the explanation Mark, the context was really helpful. I’m not loading any models client-side, and was unable to get the component to render using the command you provided.

Do you have any other advice on debugging this problem? I appreciate all the help you’ve provided thus far, but I also understand how difficult something like this is to fix from afar and certainly don’t want you spending too much time on this if I can do any of this myself.

---

Are you seeing the error message in pages that don’t use jSignature? 

In a situation where I can’t figure out exactly which component, model, or snippet is causing the error: (involves editing the page’s XML)

• Clone the page


• Open the XML editor for the page


• Comment out all snippets, save changes, and load a preview of the page. 


• If the error is gone, then remove your comment tags from the snippet XML, and instead comment out one snippet at a time. 


• Reload the page preview after each snippet has been commented out. 


• Does the error still happen? If it doesn’t, then the snippet you just commented out is causing the error, and you’ll need to debug that snippet. In this case, where do you see rsomething].records in the snippet? Whatever that Wsomething] is, it’s not being defined at the time the snippet is running.

The issue could be unrelated to snippets. If that’s the case, I’d take a similar approach, but instead, I’d comment out one model at a time, and reload the page to see if removing that model causes the error to go away. If that also fails, I would then try the same process on the page’s components. The goal is to find the piece of the page that’s causing the issue, then look for anything unusual about it. 

We call this the ‘brute force’ method, and it’s slow-going, but it’s very helpful when you’re not sure where to start. 

One other important thing to mention is a difference between pre 10.0 versions of skuid. In versions prior to 10.0, “null” was returned more liberally for several APIs—even being returned for properties that were not set. By standard conventions, undefined should have been returned for these unset properties. This behavior has been corrected.
If your code explicitly checks for the null value on undefined properties, you’ll need to update it accordingly.

This is explained more clearly in this document, and the suggested approach is included as well:
https://docs.skuid.com/v10.0.0/en/release-notes.html#undefined-vs-null

I have a feeling some code on your page is checking whether something is null. In newer versions of Skuid, that check should also look for whether the thing is undefined. I’ve had good luck using the ‘falsy’ check explained in the link above.

---