Michael Boyle wrote:
No I understand. What does that hostheader do, if anything, in the web.config file? And short of putting it all in an iFrame or something crazy, any way to get the url to remain in their address bar without dotnetnuke even though it's in a DNN directory?
OK - I think you're misunderstanding what has been said - it looks like it's been setup as a 'virtual directory' rather than a website. By default if you set something up as a virtual directory environment, it has a prefix in the url - nothing to do with dotnetnuke - it could be anything - it's when it was setup either you or some automated process has set the prefix to be dotnetnuke.
When we develop locally- eg.. on our servers in our office, we setup a portal using 'virtual directory' and then when it is uploaded to the servers, we put directly into the root of the website and it's setup as a 'website' not a 'virtual directory'. It depends how some hosting providers setup and offer their services and once click installs.
So when we setup in a dev environment to create sites in this fashion, we use IP addresses and a dev prefix. ... eg.. 192.168.0.30/dnn or 192.168.0.30/xd as an example. We then, when finished with the site, zip it up, upload to the wwwroot directory on the server. And, in IIS, it's setup as as a website, not a virtual directory, so when we refresh the website it will show the full domain without the /xd or /dnn prefix.
Of course when you want to do all this you need to make sure the portal alias has got the full url path in there as well.
It sounds like all that's been done is a site has been setup with auto publish, it uses virtual directory options, which may or may not be in your control so when done, you were none the wiser.
Back in the olden days - DNN 2, there were issues with building in 'virtual directory' instance and then uploading to 'full path' or 'website' instance when the urls didn't work as expected, but this has long since been fixed.
I think, for you to rectify this what you need to do is put in the portal alias, the domain without the dotnetnuke, then, download the portal via ftp and if you were to log in you should see a wwwroot/dotnetnuke/ folder - where all the files are, they need to be moved to the wwwroot folder to display without the dotnetnuke prefix. FTP the files back up there and then try the full url without dotnetnuke prefix, if it works, then log in and REMOVE the dotnetnuke alias from the Portal Alias section, and delete the files in the dotnetnuke folder.
It's about shuffling these files around and if it's all too difficult, you might get your hosting provider to do this for you if they are nice.
So, hope this works for you - iframe is not the solution, moving the files to the correct location is.
Nina Meiers