TCH-Rick

First of all, nice pages. I'm on cable as well and they load very quickly. That said, I do not know of any software to slow things down. Don't know that I've ever seen that question asked. One option I can think of is to get a free account with someone like NetZero to test with. They allow up to 4 hours of access, I believe. That would be enough to test things out as you are developing the pages. Maybe someone else will be able to help and I will look around and see if I find a program to do whatyou want.

I've transferred MT blogs different ways. You can install MT on the new account and then export the data from one and copy that file into a folder called import in your new MT directory. This way works best if you are wanting to move to a newer version of MT or redo your templates, etc. You can also copy the MT directory from the old site to the MT directory on the new site. Then you backup the MySQL db on the old site and restore it on the new one. You will have to add the user and password on the new site as well. Then you edit the mt.cfg file and it will work fine to reflect the new cgi directory and the new db names (which will change from user1_mtdatabase to user2_mtdatabase). This assumes you install MT into a directory outside your cgi-bin directory.

I've sent an email to our Lead Technician. He will be looking into it as soon as he gets the chance.

I've been doing a little experimenting with the :fail: and :blackhole: functions the last few days. There are some diiferences in the way they work and I would recommend using :blackhole: rather than :fail:. When an email is sent to an address that is set to :fail: no such address here it is blocked from going to your inbox and a message is sent to the party which sent the mail to let them know that there is no one at that address by that name. If the sending party is a legitimate address that's the end of it but still notice that there are two messages involved-- the original message to you and the message going back to the sender. A problem pops up when the sending party is a fake address. Now the incoming message is blocked and a message is sent back just as in the example above. The problem is the message going out cannot be delivered and stays in the mail queue to be tried again later and will be retried numerous times until it is deleted. If a message arrives to an account set to :blackhole: it is blocked from being delivered and deleted. No more action is taken. Only one message is involved and fewer resources are tied up. Multiply this by thousands of messages and it makes a difference.

I started to respond earlier but needed to do some checking. Here's the latest. Personally, I would recommend using a different script such as the one that was shared on the forum when the problem with formmail started a few weeks back. Formmail.cgi has been disabled on all the servers. We are willing to reenable it and will keep an eye on it but prefer to do it on as it is requested for different servers right now. Once we see that it is working correctly we can do it on all servers. We have just re-enabled formmail.cgi on server 24 so, Hockeycat, if you will try the form again and see what happens. I am not real familiar with FormMail's format but am not sure the action="http://hockeycat93.com/cgi-sys/FormMail.cgi" is the correct format or whether it should be action="/home/username/public_html/cgi-sys/FormMail.cgi" Perhaps someone who has used it more can help with this detail.

Leezard is right, you should check and be sure that the files didn't just get copied. You seem to understand that www is just a link to public_html and that the files aren't actually in two different folders but I have seen folks delete all the files in either public_html or www trying to save space and being surprised when they disappear from both (an thus not be visible on the internet.) There is also the possibility that cPanel is showing the disk usage incorrectly. Sometimes a change will register immediately, sometimes it will update overnight, and sometimes it will get "stuck" for days. The system itself still is registering the disk usage correctly but cPanel is not reading it correctly. This is a known bug that will hopefully get fixed soon. Let me know what server you are on (you can see this in cPanel at the top where it says "Welcome to Server##") and we can fix it if it is stuck.

Just to be sure I checked your MX record on the system and it is set just as your instructions said complete with the 0 entry. Everything looks in order.

Welcome aboard!

I have phpMychat on my site and use chat.**** to access it. It is handy when I need to chat with someone and they don't have one of the regular clients. It's pretty easy to set up and use.

I'm not real sure I understand your question. After you have uploaded your files you can view your site using http://ipaddress/~username You should make sure your nameservers are set to the ones given in your welcome email and once propagation is complete you can view your site using http://yourdomain The nameservers will do all the redirecting.

Try it now. HG just installed it on 26.

If it is on the same server there will be no problem with propagation since the IP address doesn't change. If it is on a different server then you don't have to worry about changing the nameservers but you will have to deal with propagation issues since the ip address will be different. Doesn't apply in this case because if you set up a new account in your reseller account it will be on the same server.

Make a full backup and download it to your computer using an ftp program before starting.

Movable Type has never been in the cPanel installs. It would be against the MT license. They don't allow autoinstalls since they will install it for a fee. I've have to check on Nuke. It is on some servers but not all.

I just put in /home/username/scriptdir/filename.php for the cron entry. Note that I installed the script below the /public_html directory so it is not easily visible on the web so you won't be able to run it manually. If it is in public_html you would use /home/user/public_html/scriptdir/filename.php. You would be able to run it manually. Not sure what would happen if you had it in a protected directory. A couple of trouble shooting tips: If it doesn't run check that the permissions allow executing and that the filename in the cron is right. If it returns an empty file then check that the directory you put in the script is where the file resides.

<resist>urge to make comment about old dogs and new tricks</resist> I did a little more testing and here is how I set my account up to send multiple db's. 1. I created an empty file in the directory I wanted to use and copied the script into it. I named this file send_mt.php. 2. I editted the file to the information about my Movable Type db. Set the email and other options, etc. 3. Created a Cron to run this script every other min. 4. Editted stupid typos and changed the permission of the file to 770 (after the first backup didn't get made.) 5. Got a good backup sent after repeating step 4 a time or two. (Really shouldn't watch TV while doing this) 6. Changed the cron to send once a day in the middle of the night. 7. Copied the seditted script to another empty file and named it send_forum.php. 8. Changed data about the database. 9. Copied cron statement from first one and did step 3. 10. Changed name of file in second cron to send_forum.php from send_mt.php after not receiving the backup when expected. 11. Changed cron to run once a day in the middle of the night after receiving backup file. 12. Got a cold beverage. Bottom line -- changing the names of the files and setting separate crons works and all files can be in the same directory.

That feature is not supported by cPanel.

Found this link on Google: Topsites.us Article

Glad all is working again. We offer a lot of options for support and each method has its strengths. This forum, for example is a great place for support of scripts, common configuration questions, "Can I do this" questions, etc. When these kinds of questions come to the Help Desk we refer them to the Help Pages or here. It's not because we don't want to help but rather that it takes a bit longer to get all the info needed and is better handled in an open forum where others can learn as well. I refer to the Help Pages frequently and paste paragraphs from there often into Help Desk tickets. And the IM options are great to get a quick answer or just ask what you should do. On the other hand, there are problems that require access to your account. Many times the solution is fairly simple but we need information you shouldn't be sharing here. That's why we'll recommend opening a ticket. I've seen problems mentioned on here that go on for hours and then we are able to solve it quickly once a ticket is opened. Mitch's article is a great outline of the types of support we offer. If you aren't sure which one to use just pick one and we'll refer you to the best place to get your problem solved. That's not passing the buck but pointing to where you can best find the answer. By the way, this is not directed solely at your post, Alan. I just thought it demonstrated well how the system works. Thanks, again.

Thanks for the info. I'll let you know if we need any more information as we look into it.

Have you tried using passive mode? I have used ftp on server 26 in the past frequently and never had any problems even when sending large backup files and such. My client is set to passive mode.

Great find, Jack. I downloaded and installed the script and tested it on my test account and it seems to work fine. It is fairly easy to set up (probably easier if you don't set it up at 2 in the morning) and runs fine using crontab. I set it up outside of my public_html directory and made the changes to the file as explained in the comments. I then set up a crontab to run it every day in the middle of the night and used /home/username/dbsender.php as the command. I set the permissions to 770. When the file runs and will use gzip to compress the file then send the file to you via email or ftp.

Thanks to everyone for logging in a registering to verify that the site is working. The problem appears to be due to propagation of the domain. The link to the site used the ip address method of access since the site was just set up. Clicking on the link to log in or register used the domain name. Thus those of us who can see the site were able to log in and see everything while T-4-L could see the pages using the ip address but was getting a blank screen when it went to a page using the domain. It should clear up in a few hours. 15 (oops....wrong thread! )

I got it. I'll look into it as soon as I can.

KW, Thanks for the DNSStuff site. Nice resources.