8.11 All Skuid Pages BLANK

Need urgent help on this one.

As of this morning, we were running 8.10 and all of our skuid pages were blank, but gave the error message that there was some problem with the skuidcore manifest files. But ALL skuid pages were blank, including the skuid settings, pagelist, and all builder pages, so I couldn’t do anything to fix it. I upgraded to 8.11, thinking that would fix the problem. Now, all of my pages are still blank, but there is no error message. There are no javascript errors in the console.

Help!?

The only thing that appears to be working on any skuid pages is the floating ‘edit page’ button on the right side.

Hey, Matt. If you would, grant us login access and we’ll take a look. Thanks!

Access granted. Thanks, team.

Do the Page__c records have data in the Layout__c fields?

Additionally, have you tried opening the pages in the XMl editor?

Here’s the link as you’re probably not easily to get to it right now.

/apex/skuid__PageXMLEdit?id=

Strange. I’ve got 8.10 right now without issue. What are the last few changes you’ve made?

Also, what instance are you on? Summer 16’ was released Saturday for NA6, NA8, NA9, NA28, NA29, NA31, NA7, NA17, NA18, NA22.

When I turn off the cache definition field for the skuidcore component pack (/setup/ui/listCustomSettingsData.apexp?id=a0h), I get this error:

1. An error occurred while attempting to load the “skuidcore” Component Pack. There may be an issue with the name or location of your Component Pack manifest files. Error: Unable to retrieve content of file

When I turn it back on, no error.

In either case, a blank page.

Messaged you on LinkedIn with my skype if you’d like to troubleshoot.

na10.

How can I tell if the layouts have data?

The skuid api works in the console.

Apparently the XML builder uses the skuidcore component pack, too, so:

open a Page__c record with url param “nooverride” to open in standard layout.

Thanks so much, Pat.

I have to run into the office to grab my computer. Working from home without my toolbox at the moment. If the skuid folks haven’t turned anything up by the time I get there, I’ll ping you. 
Thanks!

open a Page__c record with url param “nooverride” to open in standard layout.

Based on the errors, I don’t think the issue is that they are truly empty. Seems Static resource related.

Problem #1: Your skuid delivered component packs were disabled (Active was unchecked). However, that Page Problem you are seeing when you uncheck cache is the error you get when there is a problem loading the Static Resource behind the component. I’m still looking in to why it’s not loading, but that’s the issue: the skuidcore components aren’t loading.

Thanks, J. Anything I can do on my end?

As you can imagine, this is a fairly debilitating error.

I was on vacation Friday, so the last changes that were made were on Thursday. Users report that everything seemed to be working ok Friday. Suddenly, brokenness this morning.

I found what I think was the source of the problem.

I was messing around with Jitterbit last week to deploy/upsert skuid settings and component packs to other orgs from our dev org. It looks like over the weekend I had a query of component packs from our dev org scheduled, and a subsequent upsert. I intended the upsert to be to a sandbox, but apparently selected production instead. So, the upsert ran for all six component pack records on Sunday.

Not sure why an upsert of what should be identical records would cause this issue? I ran the upsert on the Name field, not the Id, so Ids shouldn’t have changed.

Also, I would think that updating skuid this morning would override any weirdness caused by upserting component pack records?

OK, I got the skuidcore Component Pack working (didn’t touch anything else), and I think your Jitterbit theory is probably the cause. It looks like some of the mappings in that Jitterbit job were wrong and the values were written to the wrong fields. For instance…

  • Builder Definition File was 1
  • Resource Namespace was skuid_runtime.json
  • Resource Name was skuid
  • Runtime Definition File was Desktop
You’ll need to review your other Component Packs to make sure that they are correct though. The reason that the Skuid install didn’t “fix” them is that we allow you to customize these values, and we wouldn’t want you to have to change them all every time you updated Skuid.

Thanks, J.

What craziness. Thanks for your help, community. You guys rock.