Forum Replies Created
-
Posts
-
I tried that. The special character interferes with an “under the hood” SP configuration preventing the site from recognizing web parts available in the web part gallery. When trying to add any web parts I get an error stating it has been deleted by someone from the web part gallery. As soon as I remove that special character, the subsite and web parts work as intended. It’s something with the upgrade and policies/limits associated with special characters that no longer retrofit to what was allowed in prior SP versions.
Read an article about it for doc libs
https://abhishekdhoriya.com/sharepoint-document-location-url-invalid-characters/Also, this site is currently using DFFS from 12+ yrs ago😝. Version 2, before there was a DFFS installer. The rules no longer work with SE, so I’m setting them up on the latest classic DFFS until we eventually migrate to modern pages…where I will look to migrate to modern DFFS 😂.
Yes, I tried that and it didn’t work. It wasn’t until I removed the “&” that I was able to add web parts again to the subsite and DFFS installed on both the subsite and from its parent site to the subsite. Because it’s an older site created during the 2010-2013 era, the use of the special character ported with no issue. I know the 2016 environment prior to the SE upgrade was iffy with it. SE appears to refuse it.
I think I found the issue, and it’s definitely that “&” not encoding in the url. With the upgrade to SE, the “&” breaks the sub-site’s ability to add web parts to any of its pages. This caused the issue we’re seeing with DFFS not being able to install to forms. Hoping no one would notice I removed it in the url and had no more issues…until I kept getting user emails saying the site was down 😛, so I changed it back which created the web parts issues again.
Hey sorry for the delay. I’m using the Dark Blue theme. Blue Accent and main color. Dev mode shows this – #182534
Attachments:
Got ya, I probably need to modify my logic a little to get it working. Cool, I’ll check it out more let know if I’m still hitting a snag.
Thank you so much for all the help.
Unfortunately, the browser is preventing the beforeunload to fire off from what I’m observing. All good though. Was more of a curiosity, esthetic than a need.
Ah dang, I think there may be a policy configuration on either the browser or SharePoint that prevents catching beforeunload. That’s alright. I was more interested in the logic and using as a nice to have anyway.
Awesome! Thank you so much!
I got the PreSaveItem to give the pop-up but I can’t seem to get it to continue down the normal presave function to do it’s normal processing, put the red text under the missing field value or complete the save when all data has been populated. I thought calling the presave in the PreSaveItem would suffice but it doesn’t seem to catch it.
You are the man thank you so much I will try that out and let you know.
One more question, do you know if it’s possible to prevent the user from refreshing or closing a form with a pop-up that lets them know they are about to close with unsaved changes?
Oops I needed to fix the size
Attachments:
Last update (ha-ha): For the numbers to stick I have to select at least 3 items in one session for it register in getFieldValue. Not sure what’s going on with that.
