We developed a DNN website for a client on our server and have moved it to the clients server. We got it running using a local IP address  but noticed broken links and digging into it further we found the content editor used absolute links instead of relative links, don't like that much but its a different issue. I changed all the links to relative and everything looked good. They established an external IP address for us and when I accessed the site using it none of the content changes showed. Going back and using the local address showed that it still looked good. When we go live there will be the final URL. I need all these URL's to update the same content. I looked at the alias in the admin settings and it listed all the URL's for each page in the old beta site and then the two IP addresses for the new server without any page references? What is it doing? How can I get it to behave the same no matter the URL. This is a very large site with lots of users so I can't wait to go live to fix the content. Alsp when is the content stored in the database? I looked at the contentitems table but it only seems to have the title info in it. Where is the actual content stored?

I hear you...  I see/hear the same complaint throughout these forums but I don't think the fix is on anyone's radar screen.  Most users are comfortable knowing how things work, however quirky we may think...

Try (from host) a Portal Export [with content], then import it to another site/portal [during portal creation via host or via Site Wizard later from Site Admin].  That was suggested to me early on and it is a great tool to explore.  You will see much content gets 're-addressed' to the new portal, but you will find many hyperlinks and image links do not.  They, and uploaded 'files', remain pointed to at their old locations...  You may discover a 'custom' portal export/import module/version might ease your worries.

All module content does get stored in the db but finding it w/o a good map is tough sometimes.  Specifics might help someone help.

After trying many things, I always take the step to go live and online with a "NewTestDomain" (throw-away) domain and instance, test it and then when it is ready point my preferred domain to it rather than moving everything to the preferred domain; as long as NewTestDomain/dnn and YourDomain stay accessible all the links will still work... ., albeit not how you might want... THEN I reconstruct (restore db, import exported portals, etc) the original instance as my back-up, clean it up, and make it ready to be pointed to (again) in a heartbeat.  With Domain Forwarding, Portal Aliases, and, in dire straits, a simple html redirect, you can switch where a domain points a lot faster than actually moving one.

Don't be too hard on DNN for doing things their way.  I've backed up, packed up, moved and restored DNN sites and they work.  You can spend a lot of time cleaning up a working site and nobody notices...

The 'propagating aliases' is a bug recently introduced , I though fixed in 5.6.2.

If DNN is not root, but in a folder (like HostDomain/dotnetnuke), I have found it necessary to add MyNewDomain.com and MyNewDomain.com/dotnetnuke as aliases to get it to work fully/properly.

I am a (very happy) user, not a guru.  The above is empirical not gospel.

Wait long enough and somebody who really knows what is going on will drop by...

Bob Hanson,
User

How many 'old' portal alias entries?  Did you add them all?  There was a bug reported in 5.6.0 (I recall...) where dozens of 'bogus' portal aliases got automatically added that caused flaky things to occur.  Deleted them is all it took to fix. [Fixed in 5.6.2.]  You might delete any portal alias you didn't add yourself, or that you don't understand.

http://www.dotnetnuke.com/Resources/F...

I'm not a programmer, but in lay terms here's what I've come up with to describe what goes on...

Your DNN install is in a folder of your hostdomain.  Let's call it hostdomain/dnndir.  You can always get there by navigating to hostdomain/dnndir.  Hostdomain/dnndir is a 'default' alias for portal0 [I think it should never be changed...]

In your hostdomain/dnndir folder is a default.aspx file.  Whenever you 'land' there, and that file runs [no higher priority file exists], it looks at your 'ticket' and decodes the incoming target address, [say MyDomain.com] and scans all the portal alias tables looking for a match.  If it finds a match [MyDomain.com is an alias for a portal] it sends you to that portal.  It essentially reassigns all of your page.aspx  'url requests' to MyDomain.com/dnndir/Page.aspx [or should].  What I have found is that for all pages to get served to MyDomain.com requests, I must ALSO add MyDomain.com/dnndir as a portal alias. [maybe you can look at the default.aspx and default.aspx.vb code and see what it really does...]

Sounds like your client is placing an unreasonable, burdensome and doomed-to-failure restriction on you.  I would suggest a self-preservation alternative; spend a hundred bucks and put the site up on a 3rd party host you can control, and then copy and migrate later point to their servers, after a suitable test...  If they fire you, they can always take the keys and change the passwords at the 3rd party hoster...  

Bob