WebDev WaxLotus LLC

Hey,

Did you create the database it’s trying to use?

If you did, these were probably the steps you took, especially so if your host uses cPanel:

Take another look to see if you assigned/added the db user you created to the new database…

Dude, I don’t know how zeniph figured it out. I just use a bigger hammer or a louder speaker to fix things.

Looks awful

Here ya go, mate: http://www.getfirefox.net/

<snark>All fixed!</snark>

You’re so welcome.

MuSnake.

Fisherama, is that you soccio97 or is this a new person?

@soccio97: When you add content to your blog, posts, plugin settngs etc. all of that get stored in the database. So, all that content is still in the database backup file from your old host. Do you have that file? It may be a .sql or .gz or something else. If you have that, we can work on restoring the db.

As far as your themes and plugins, they are in that .tar
Do you have a compression program on your PC that can open (untar) .tar files? If not, try 7-zip You create a folder anywhere, your desktop for e.g for you to work in. Drop the tar file into that new folder. Then you right click on the .tar and uncompress it right there. You’ll end up with a copy of the file structure of your old host in that folder.
Then, you browse through that old setup to the wp-content folder where you’ll see the plugins and uploads and themes folders. Those are the files to FTP over to the new site. There’s no need to push ALL the files as most of them are already there, you’re only missing the ones you added to the original (core) files from WP.

Right, once those files are on your new server, you’re ready to start messing with the database.

First, you must figure out how to generate a backup file of that database using your godaddy account. I’m sure you’ll figure it out (or google to see if someone has a write up). Choose “data” and “structure” so that you have the database tables (the structure) and the content in them (the hello world post, your initial settings etc). The reason we keep a copy of this cherry install is in case things go badly later, you can delete the structure and content (drop tables) without having to delete the whole freakin’ database (drop database). If you drop the database, you have to recreate it as you did earlier, and paste the values into wp-config.php etc. PITA.

If you get to this stage, where you have a database backup of the cherry install, and, you have found the sql file from your old host (remember that it might be compressed so don’t only look for .sql) you could try to restore your database using that sql file from the old host.

Now this is where we have to check something. When the old db backup was made, did it include just the content or the table structure and content? It changes what we do next…

Depending on the options used to create the backup, your new server may recognize that that file was intended for use on a database called something else (the old host db name) and it will throw all of it’s toys out of the pram’. No problem. You cleanup, you take out the broccoli, and you try it again. This is what I mean…
Cleanup: If your old file creates the tables (it’s not just content), you want to start with a database empty of tables otherwise when you try to restore using the old script it will complain that tables already exists and the crying starts all over again. So if your script creates the structure (the tables) you drop all the tables (NOT THE DATABASE!) and redo the restore from the sql file. If it does not create the tables, the script assumes that all the tables exist in the exact same structure as before AND that the tables are empty of old data! In this case, where your script does not create the db structure, you must empty (sometimes called truncate) all the tables, not delete them, empty them, ready for your script to fill…

Fine, so how to check? Open the sql file with an editor and look for CREATE statements (the create table statements). IF you see DROP IF EXISTS before the create you don’t even have to empty the db of the tables. The script will do that for you! IF you just see INSERT INTO statements then you know that the script is expecting the table structure to already be in place…

Sounds fussy but it’s not.
Put your themes and templates back into the cherry file install.
Check your SQL to see what it’s going to do (oh, delete any USE DATABASE statements you see as they’ll just complicate things, especially since the database it’s telling the script to use doesn’t exist anymore…)

It’s on of two things. Creates tables (so you must give it a database with zero tables, drop tables) or it expects tables (so you must give it tables that have zero content, empty tables).

Once it goes through the script and says 432432 rows processed 0 errors. Go to your site, hit refresh, and send me lots of money.

Urrgh, I see you’re a content aggregator.

An example of the values are the ‘musnake_*****’ entries in the wp-config.php:

// ** MySQL settings ** //
define('DB_NAME', 'musnake_dbyaker');    // The name of the database
define('DB_USER', 'musnake_sysyaker');     // Your MySQL username
define('DB_PASSWORD', 'huiI7G76&8gG^(9t'); // ...and password
define('DB_HOST', 'localhost');    // 99% chance you won't need to change this value
define('DB_CHARSET', 'utf8');
define('DB_COLLATE', '');

I see from the web that GoDaddy offers a one-click install which results in yourDomain.org/wordpress/ which looks like what they did…

This is a link to a step-by-step process for installing on GoDaddy. Look closely at steps 8 and 9 before you start all over!

In the comments of that post is another, possibly better link for folks who have chosen a linux package with GoDaddy…

You’ll be a pro at this in no time. Relying on GoDaddy will yield frustration…

BTW, how much money are you losing?

Are you comfortable restoring backups?

If you can restore a database and a file backup, you can always blow away the upgrade disaster and restore the old site.

No doubt you’ll make backups of your database and your account files.

You mentioned hacked scripts. If you made changes to core files over the years you’ll lose them when you use the new file base… Whooami makes a good point about deleting not overwriting folders. Often, scripts aren’t called anymore because they’re obsolete so there’s no need to have them festering in your account… It can be tedious!

Hello Maheswaran,

So you’re developing locally and now want to move your development site to production. When you FTP’d the files to your prod’ server, did you edit the wp-config.php entries to specify your domain name as blog URL etc (instead of 127.0.0.1 for e.g)?

Are the PHP/mysql/etc versions the same between the two environments?
Did you check the file permissions after you FTP all of that to the prod’ server? Files 066, Dir 0744

You created the db’s first right via plesk? The files need the db to interact with so it makes sense that your dev db matches your prod db (internal settings/options are all setup for yourdomain.com etc)

Basically, are the two environments synchronized?