DFFS Install to Form – “URL is not for this web”

[Jonathan Stamper]

Alex, been a long time and I hope you’re doing well. I’m having an issue that may correlate to the dreaded “&” on our subsite not being encoded correctly to %26 on my browser. DFFS works fine on other lists, but when I try to install it to a new list on that subsite, I don’t get a button but instead get “URL is not for this web.” I notice, that if I switch the site base url out of the subsite with the “&” to the parent site, I don’t have issues installing to a list. As a heads up, we have recently updated to a new version of SP SE but only using Classic pages, but I don’t think that’s an issue. I wanted to get your take and see if you have any suggestions. I’m currently Classic DFFS from 8/12/2024.

Attachments:

1. 

   subsite-with-.png
   

2. 

   Another-subsite-same-parent-but-no-in-name.png
   

[Alexander Bautz]

Hi,

I’m not able to recreate this issue. Can you email me some screenshots of the URL when you get this error message so I can try to recreate it?

Also include the browser you are using.

Alexander

[Jonathan Stamper]

I sent an email your way.

[Jonathan Stamper]

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.

[Alexander Bautz]

Did you try my suggested solution (installing DFFS in the subsite and installing it from there)?

Alexander

[Jonathan Stamper]

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.

[Jonathan Stamper]

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 😂.

[Alexander Bautz]

OK, one option is to manually add the Content Editor Web Parts that loads DFFS to the forms (NewForm, DispForm and EditForm). Just open the form and edit the page and insert a CEWP above and one below and refer a working list to copy the Content Link URL. Set both the webparts as Hidden.

This will “install” DFFS without using the DFFS Installer.

Alexander

[Jonathan Stamper]

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/

[Author]

Posts