Currently we are subscribed to GoDaddy for their dedicated server lease, and now we are considering just purchasing our own server and just moving off of GoDaddy.
I have no idea how to put all of my source code from one server to another and also move the database and other files. Please explain what process has to be followed for this.
Also wanted to ask if their would be any changed for the third party tools i have used in my application?
To migrate my web application from one server to another I would do following :
Make a list of all transferable which would be:
Latest and running Source code on the server (ideally located in wwwroot)
database back up files (usually .mdb or .bak)
Copy source code and database back up to targeted server. Obviously depending upon type of the server you may need to set up the site in IIS and and point it to new directory
Restore database backup on database server
edit web.config to point to new database server and credentials.
Another important tip: If you have kept domain name with GoDaddy and only changing hosting server you may also need to change namedserver of you domain, without which you will not be able to point your domain to new hosting provider!
You may not succeed on the very first attempt of copying your stuffs to target server. It's always better to maintain back up so that you can copy files again and again in case something goes wrong on the new server.
As long as third party charges are concerned please check with your service providers they may be able to guide you best. For above simple stuff you do not need to worry about license stuff.
All the best!
Ok so I have a number of CMSs and eCommerce applications, that require the correct URL (otherwise the links will not work). Of course in my development server, the domain name cannot be the same as the production server... do you guys just do an edit/replace on all files and edit the mysql entries before pushing the development to production server environment? Or is there a better way to do this?
You could just place everything in a directory with a random hex or other valid characters as the name like:
yourdomain.com/XHTEDD12222-112KJK
You might also want to include an entry in your robots.txt file to exclude this directory. This isn't 100% safe, and it is best to use a local server or access the site via IPv6. IPv6 is suggested over IPv4 for security with crawlers. Anything you put up publicly isn't exactly safe.
Once you change the name with one of the above options, you could just refactor your project with the name change. If you go with IP and or local server, you can refactor to that number and it should still work.
You may also look into editing host files to achieve a similar workaround without redirecting DNS servers to point at your development server, but this is OS dependent. Comment your OS and I might be able to help with that.
Lastly, for security, you could include a PHP wrapper for all of your pages that look for a specific IP address in $_SERVER['REMOTE_ADDR'] global variable, but this could get really complicated to implement and I'm unaware of any currently available components that do this.
I have a wordpress mu-site. I need to set up a test-version of it so that the client can run test on the changes we make, test the plugins with new updates etc.
Anybody who has worked with wordpress know it's a bit off a hassle to move between servers and/or domain-names, due to the absolute paths used. Does anybody have a good solution how to create a stage-enviorment of wordpress?
Here's how I do it + some adjustments I want to make:
Two WP installs on identical environments - dev & production
They each have their own FQDN
Version control (SVN in this case) to handle merges from dev to production
When merging, I don't ever merge database changes. I only merge code, and modify any of the domain specific things during the merge (which really should only be in the DB.)
Recreate any DB changes needed during deployment
There are other ways to do it, but they often require changing the hosts file or access to internal systems. So if you want to be able to show an external client a site, then those methods aren't likely to work.
I also sometimes copy the DB back from production to dev, and just do a find & replace for the FQDN.
You can also dev locally and use the above listed method for staging only.
I have about 5 sites where till date all development changes have happened directly on the live server, where the change would be made on a test file first and if ok, would replace it with the original file.
However, I can't really continue with this approach now because the site has become quite complex and testing changes usually involves changes to DB as well. I will also be having some outsourced developers working on the site. So now need to figure out how to set up an environment such that the dev. team can make changes to a test environment running perhaps on the same server, as a subdomain on the main domain perhaps, but not sure how to go about it.
Our sites are hosted on a single dedicated server with WHM/Cpanel setup. Now,
a) how do I go about creating a staging environment where they have access to the latest files and a db copy of the live db?
b) how do I track what all files they've changed/updated, so that I can then copy them to the live server and upload?
Is there some other approach I can/should consider? Am not really sure how to go about this.
I work on quite a few DotNetNuke sites, and occasionally (I haven't figured out the common factor yet), when I use the Database Publishing Wizard from Microsoft to create scripts for the site I've created on my Dev server, after running the scripts at the host (usually GoDaddy.com), and uploading the site files, I get an error... I'm 99.9% sure that it's not file related, so not sure where to begin in the DB. Unfortunately with DotNetNuke you don't get the YSOD, but a generic error, with no real way to find the actual exception that has occured.
I'm just curious if anyone has had similar deployment issues using the Database Publishing Wizard, and if so, how they overcame them? I own the RedGate toolset, but some hosts like GoDaddy don't allow you to direct connect to their servers...
The Database Publishing Wizard's generated scripts usually need to be tweaked since it sometimes gets the order wrong of table/procedure creation when dealing with constraints. What I do is first backup the database, then run the script, and if I get an error, I move that query to the end of the script. Continue restoring the database and running the script until it works.
There are two areas that I would look at -
Are you running in the dbo schema and was your scripted database
using dbo?
Are you using an objectqualifier in either your dev or your
production environment? (look at your sqldataprovider configuration
settings)
You should be able to expose the underlying error message by setting the following in the web.config:
customErrors mode="Off"
Could you elaborate on "and uploading the site files"? New instance of DNN? updating an existing site? upgrading DNN version? If upgrade or update -- what files are you adding/overwriting?
Also, when using GoDaddy, can you check to verify that the web site's identity (network service or asp.net machine account depending on your IIS version) has sufficient permissions to the website's file system? It should have modify permissions and these may need to be reapplied if you are overwriting files.
IIS6 (XP, Server 2000, 2003) = ASP.Net Machine Account
IIS7 (Vista, Server 2008) = Network Service
Test your generated scripts on a new local database (using the free SQL Express product or the full meal deal). If it runs fine locally, then you can be confident that it will run elsewhere, all things being equal.
If it bombs when you run it locally, use the process of elimination and work your way through the script execution to find the offending code.
My hunch is that the order of scripts could be off. I think I've had that happen before with the database publishing wizard.
Just read your follow up. In every case that I've had your problem, it was always something to do with the connection string in web.config. Even after hours of staring at it, it was always a connection string issue in web.config. Get up, take a walk and then come back.
If you are getting one of DNN's error pages, there is a chance it may have logged the error to the eventlog table.
Depending on exactly what is happening and what DNN is showing you you might be able to manually look inside the EventLog table, pull out the XML data stored there, and parse it to find the stack trace and detailed information regarding the specific error at hand.
I have found however though that I get MUCH better overall experiences with deployments using backups and restores of my database, that way I am 100% sure that all objects moved correctly, and honestly it works better in my experience.
With GoDaddy I know another MAJOR common issue is incorrect file permissions, preventing DNN from modifying the web.config and other files that it needs to do.