DotNetNuke 5.06 Project Migration

Discussion in 'Third-party applications' started by Pyronaught, Dec 28, 2011.

  1. I have a site I developed in DNN Community Edition 5.06 and am trying to port it over to a site I just setup on Winhost. First I tried the DNN installer that Winhost does automatically, but it installed version 6 and I don't want to deal with trying to find out what isn't compatible in my 5.06 version. Not only that, it seems like it would be much more difficult to try and install all the modules and try to build the install up manually compared to just copying over all the files from my DNN folder on the dev server. So while the DNN 6 app was working after running the winhosot utility to install it, I deleted all the files from the dotnetnuke folder the installer created and then copied all the files over from my 5.02 installation. I kept the original dotnetnuke folder created by the Winhost installer because I figured it might have some necessary permissions or other settings created for it. I then made a backup of my local SQL database and restored it to the Winhost database. Lastly, I changed the web.config file to use the new database connection string.

    From what I've read on the net, that's about all I should have to do. I also created the portal alias that uses the Winhost path before backing up the local database and restoring it to the Winhost site. I don't have a real domain mapped to this site and am using the Secondary Web URL provided by Winhost as the portal alies and as the urls I enter in the browser.

    So now I can hit the default page of the DNN site no problem, but any link off that page gives me a 404 Resource Not Found error, which I assume means that there is something wrong with the file path and the page can't be found. I really don't understand much about the internals of DNN, as it appears to generate files on the fly rather than linking to physical files on the server. While the Default.aspx page physically exists in the root of the DNN folder, the Login.aspx file does not appear to exist ANYWHERE in the entire site so I really don't understand what exactly happens when the user clicks the Login button and DNN attempts to load that page. In the good old simple days it was easy to sort this kind of thing out, but I have no idea what is going on now with trying to load a page where the file does not even physically exist on the server!


    Any DNN guys know what could be causing what appears to be a file path problem?
     
    Last edited by a moderator: Oct 14, 2015
  2. Did you change the DNN config to use the alternate URL?
     
  3. The only place I could find to specify the URL was in the portal alias assignment section of the admin page. I can't access any of the admin pages in the live site due to the url problem making it impossible to get to them, but I added the secondary web url given by Winhost to the portal alias list from the localhost site prior to migrating the database. I didn't see any place in the web.config file to specify a root path or anything like that. Where in the DNN config would this URL be specified?

    I did find the post called "DotNetNuke: Installing in Subfolder, Access from Domain Root" and made those changes, which fixed an image reference problem I was having but didn't fix the 404 errors that occur on any page other than default.aspx.
     
    Last edited by a moderator: Oct 14, 2015
  4. OK, this took some digging but I figured out the problem. Apparently there's a bug in some of the version 5 releases of DNN where the URL rewriter doesn't work right when set to use human friendly urls (but only when the site is running on some port other than port 80). The solution is to go into the web.config file and find the following section and set the urlFormat value to "searchfriendly" instead of "humanfriendly"

    <providers>
    <clear />
    <add name="DNNFriendlyUrl" type="DotNetNuke.Services.Url.FriendlyUrl.DNNFriendlyUrlProvider, DotNetNuke.HttpModules" includePageName="true" regexMatch="[^a-zA-Z0-9 _-]" urlFormat="searchfriendly" />
    </providers>
     
  5. Nice find, thanks for posting the follow-up.
     

Share This Page