Tony

This has been completed.

This has been completed.

They are much smaller because on a reseller plan you can create many cPanel accounts which added much more load than a single shared hosting account. Along with that reseller accounts have overselling enabled so you could allocate 30GB of space on a 3GB plan as long as you're under the 3GB. So basically this is all due to other costs outside the space and bandwidth portion of the account.

/usr/bin/wget and /usr/local/bin/wget you just do not have access to the them. You'll need to make a ticket.

They are http redirects not CNAME based. So if you need a CNAME one you'll need to make a ticket since cPanel as of the version we run does not allow cPanel users to modify the dns zone.

When I checked last night there was no user associated with the database. I spoke with the technician who handled your ticket and they noticed the same thing and added the user to the database.

Did you make sure to give the user access to the database through cPanel? That's usually what people forget to do.

The mysql hostname should be localhost. For the database info it's whatever you called it in cPanel and it lists them with their full names as well. So if you put wordpress it would be lewislev_wordpress for example.

We will be updating the Mercury server kernel to the latest version on Friday January 15th between 8:00am CST and 11:00am CST. We estimate this will result in about 10 minutes of down time while the server reboots. Keeping kernels up to data is a necessary step in order to stay on top of performance improvements as well as have the latest security fixes. Date: 01/15/2010 Start time (CST): 8:00am End time (CST): 11:00am Duration: 3 hours Estimated Down Time: 10 minutes

We will be updating the Mars server kernel to the latest version on Friday January 15th between 8:00am CST and 11:00am CST. We estimate this will result in about 10 minutes of down time while the server reboots. Keeping kernels up to data is a necessary step in order to stay on top of performance improvements as well as have the latest security fixes. Date: 01/15/2010 Start time (CST): 8:00am End time (CST): 11:00am Duration: 3 hours Estimated Down Time: 10 minutes

We will be updating the Skyline server kernel to the latest version on Friday January 15th between 8:00am CST and 11:00am CST. We estimate this will result in about 10 minutes of down time while the server reboots. Keeping kernels up to data is a necessary step in order to stay on top of performance improvements as well as have the latest security fixes. Date: 01/15/2010 Start time (CST): 8:00am End time (CST): 11:00am Duration: 3 hours Estimated Down Time: 10 minutes

We will be updating the Saturn server kernel to the latest version on Friday January 15th between 8:00am CST and 11:00am CST. We estimate this will result in about 10 minutes of down time while the server reboots. Keeping kernels up to data is a necessary step in order to stay on top of performance improvements as well as have the latest security fixes. Date: 01/15/2010 Start time (CST): 8:00am End time (CST): 11:00am Duration: 3 hours Estimated Down Time: 10 minutes

We will be updating the Titan server kernel to the latest version on Friday January 15th between 6:00am PST and 9:00am PST. We estimate this will result in about 10 minutes of down time while the server reboots. Keeping kernels up to data is a necessary step in order to stay on top of performance improvements as well as have the latest security fixes. Date: 01/15/2010 Start time (PST): 6:00am End time (PST): 9:00am Duration: 3 hours Estimated Down Time: 10 minutes

We will be updating the Venus server kernel to the latest version on Friday January 15th between 9:00am EST and 12:00pm EST. We estimate this will result in about 10 minutes of down time while the server reboots. Keeping kernels up to data is a necessary step in order to stay on top of performance improvements as well as have the latest security fixes. Date: 01/15/2010 Start time (EST): 9:00am End time (EST): 12:00pm Duration: 3 hours Estimated Down Time: 10 minutes

We will be updating the Jupiter server kernel to the latest version on Friday January 15th between 9:00am EST and 12:00pm EST. We estimate this will result in about 10 minutes of down time while the server reboots. Keeping kernels up to data is a necessary step in order to stay on top of performance improvements as well as have the latest security fixes. Date: 01/15/2010 Start time (EST): 9:00am End time (EST): 12:00pm Duration: 3 hours Estimated Down Time: 10 minutes

We will be updating the Neptune server kernel to the latest version on Friday January 15th between 9:00am EST and 12:00pm EST. We estimate this will result in about 10 minutes of down time while the server reboots. Keeping kernels up to data is a necessary step in order to stay on top of performance improvements as well as have the latest security fixes. Date: 01/15/2010 Start time (EST): 9:00am End time (EST): 12:00pm Duration: 3 hours Estimated Down Time: 10 minutes

You can upload your own copy of wordpress it does not matter that it's part of fantastico. In fact these days fantastico's usefulness for wordpress is gone as wordpress has it's own built in updater anyways.

I would advise you make a ticket so we can see why it does not like the domain.

The blog post you mention does not talk about replication of the database data strictly the files that are on FTP. In order to copy the .frm, .myd and .myi files you need to shutoff both ends. Your development server gets shutoff you then shutoff production to copy the new files over. This is why backup systems when dealing with mysql need to flush everything otherwise it's highly likely the db files are corrupt. So when you're dealing with a production system it would be causing down time every time you want to restore that data or take the data off of it for development systems. So I don't think what you're wishing to do is a standard practice at all. What is standard is dumping the database once in a while to the development side to have real production data. As far as each user having their own MySQL instance the overhead would be astronomical. Say we had 500 users on a single server that's 500 separate mysql instances. None of which can be binded to localhost they would need to be binded some other way. I've never seen this done in the shared hosting world. Closest you get is users purchasing their own mysql server essentially and they connect to it remotely. So the host offers for $30/month a mini MySQL which is sitting on a OpenVZ virtual machine or Xen or something. How we do our production vs development is somewhat similar to the blog post you mentioned. We use mercurial to do our version control. Anyone working on the site either makes a dev environment on their system or they using our staging system. We keep a schema.sql file below the public root that we update once in a while for anyone doing development so there is some production data. The person makes the changes tests it locally and does however many revisions. Then once they believe it's ready they push it back out. On our production side we have system in place to checkout the code from mercurial.

That's not possible if you wanted your own mysql server you'd need a virtual private server. As I said what you're wishing to do is not even something you should be doing to begin with. Copying the data files there is no guarantee it's all there if mysql is running. The same with copying them into the actual folder where they are on the new system. You have many risks of corruption in there. That also does not take into accountant if the versions are different the problems that could cause. This is why you also export them as a file using mysqldump then import them back in running the sql queries from the actual file. So either by uploading it in phpmyadmin it from ssh doing mysql -u username -p database

The direct databases files you cannot access as they are owned by the mysql user not you. How you import them is dump the current contents using mysqldump or phpmyadmin has a tool to do it. Then login to cPanel go to phpmyadmin and then you can import the .sql file. This is far better than uploading the actual db files if that was possible. Uploading different files while mysql is running can produce unpredictable results. Also you uploading the files if your mysql server was running it might not have all the data in the files yet (might still be in strictly memory not written to disk).

It should not as I do not believe search engines are IP based on their rankings. Cannot guarantee I'm right though since no one actually knows 100%

According to the wordpress bug tracker it was one of the things fixed: http://core.trac.wordpress.org/ticket/11499 So no idea why you're having issues with it unless it's something specific to what the plugin you use is doing.

My version is silent so no output that's the difference. As for the error from the post above this was a reported issue with wordpress 2.9 (fixed in 2.9.1) and is caused because there is a bug in PHP before PHP 5.2.12

I'd leave the email blank unless you want output. As for the cron command itself: curl --silent --compressed http://example.com/wp-cron.php You can set it every minute or 5 it does not matter. It's bandwidth usage is negligible I imagine. It won't run things more often or anything like that since it has it's own internal timers for the tasks it's running.