Forum Replies Created
-
Posts
-
Yeah, I’m on the latest version of DFFS (April 2025). I don’t get any errors in the console. The document upload popup, when trying to load a file says “Something Went Wrong.” Underneath it says “File Not Found.”
I’ll see if I can shoot over some screen shots via email.Apologies on second bullet. Was meant to say…
— A button called “Initiate Attachments” is selected. This creates the folder/subfolders structure, uses the vlookup as the parent folder temporarily until the user saves on the main list. Updates to the custom ID created on main list.I’m having a similar issue and on the latest version of DFFS classic. Worked fine until migrating to SharePoint SE. I get “File Does Not Exist” or “File Not Found” error. You may recall helping me on this setup via another thread I posted few years back, but here’s the breakdown:
— New Form opens, user selects “attachment” tab.
— A button called “Initiate Attachments” is selected. This creates the folder/subfolders structure uses the vlookup as the parent folder and updates to the custom ID created in the main list.
— One subfolder: “Resulting Data” is where files are loaded.
— Once the folder structure completes the vlookup table is visible with the “Add Attachment” button.
— Selecting that button opens pop up window to upload file.
— I add file, select save, get the mentioned error and file isn’t saved to the “Resulting Data” subfolder of doc library.
— Also occurs on the Edit form, though the folder structures and naming conventions are created with no issues. Even pre-SE upgrade folders no longer works.In debugging, because of the space in “Resulting Data,” vlookup was creating an additional subfolder, encoding it “Resulting Data” and “Resulting%20Data” subfolders.
It looks like it could be something within spjs.verify. However, I tested it creating folders/subfolders with no spaces still errors.Hey Alex, thanks for the information. I ended up uninstalling all from the subsite and reinstalled on the parent. That fixed some of the oddities with updating DFFS and all the lists recognizing the correct one.
The save issue was due to the very old version of DFFS still lingering on the form pages. Also, the new version of DFFS Code CEWP was placed above the form webpart instead of underneath it due to the zone location of the form Webpart showing a large number such as 15. Removing the old and adjusting the webpart location and zones fixed it.
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.
