TweezerMan

The server address is only supposed to be used while your domain propogates (initial setup of your account). It is against TCH policy to direct traffic through the server domain name in any way. You must have all traffic go through the domain name that you have established with your account.

CPanel has to have enough disk space on your account to create the full .tar.gz backup file before it can send it to you through your browser. If there is not enough space on your account to store the file, you won't be able to create, let alone download, a backup. Now the problems make sense! CPanel starts building the backup file, but when your account runs out of disk space, the backup is abruptly halted with the backup file only partially constructed. This is why only some directories are present in the archive file and why WinRAR complains about 'unexpected end of archive''. You would have the same problem - CPanel has to be able to create the full backup before it can FTP the .tar.gz file to a remote FTP server.

With the .htaccess file as you currently have it, you're trying to get the server to parse an .html page twice - once for PHP and once for SSI, and I believe the server will only parse a file once. From the Apache server documentation: Since .html files are associated with PHP as the handler (SSI is associated as a MIME-type), PHP will get to parse the .html page and it will not be parsed for SSI. If a page is being parsed by PHP, you don't really need to use SSI as PHP has equivalent commands built into it. For example, instead of this SSI command: ><!--#include virtual="http://exocet.digitalpalatte.com/ikonboard/iB_html/non-cgi/ssi/newsdata.txt" --> ...you can use this PHP command instead: ><?php include 'http://exocet.digitalpalatte.com/ikonboard/iB_html/non-cgi/ssi/newsdata.txt'; ?> Hope this helps...

Welcome to the forums, Tom! Since your script appears to be a short one, you might try opening the file in CPanel's File Manager, copy and paste your script code into the editor, save the file, then try the script again in your browser and see if that fixes your problem. If it does, I suspect that the script did not upload properly to the server.

This is what you would need to do (I'm assuming you're still using MT 3.121): 1) In Weblog Config / Preferences, check the box labelled 'Require Name and Email Address Information', then click the 'Save Changes' button at the bottom of the page. This is what will require your commenters to submit an e-mail address. 2) In your Individual Entry Archive template, find the MTCommentAuthorLink tag and change it to the following: ><$MTCommentAuthorLink show_email="0"$> This is what will suppress the display of commenters' e-mail addresses. 3) Rebuild your Individual Entry Archive pages to update them on the server.

Welcome to the forums, Stan!

Yes, the URL would be as you describe it, and no, you don't need to do anything to enable the shared SSL on your server before you can use it.

Welcome to the forums, puffer_archer! When you dump your database, you should try to get the dump as a compressed file (.gz). This should reduce the file size by 80-90%, turning your 30MB database into a 3-5MB dump file.

Those statements are the same outside of a function, but not within one: I'm glad to hear you finally got it working!

I'd recommend upgrading to MT 3.2 (see my response below). There is no way for you to submit IP addresses that you think should be blocked - the block list is updated in other ways. MT 3.2 does do a better job of handling spam comments and trackbacks. MT 3.2 features a new 'junk' folder for both comments and trackbacks, and a scoring system for determining whether a comment or trackback should be 'junked'. The SpamLookup plugin that is packaged with MT 3.2 is much improved over the version that is available for download - it's configuration options are integrated into MT 3.2's 'Plugins' page and it has been updated to make use of MT 3.2's junk scoring system. If you do upgrade to MT 3.2, you should remove the existing version of SpamLookup you have installed so it won't conflict with the new version packaged with MT 3.2. SpamLookup (either version) does not send out notifications on its own. If you've disabled e-mail notifications and are still receiving them, there's something else wrong in your MT install.

Welcome to the forums, Calvin! Maybe Calvin meant 'shopping cart'?

I believe the server would need to be running an NcFTPd FTP server in order to use NcFTP commands. As far as I know, TCH servers run ProFTPd for the FTP server.

To my knowledge, TCH currently has no plans to upgrade to MySQL 4.1, let alone MySQL 5.0. For the same reasons as recently noted in the PHP5 topic, there's simply too great a chance of breaking customer scripts that are working now under MySQL 4.0.

Welcome to the forums, rockinbassman!

What you're encountering is a variable scoping issue, which isn't something specific to javascript (it can occur in C, PHP, perl, etc.). The variables 'count' and 'delay' are defined as parameters passed to the 'newsbar' function': >function newsbar(count, delay) These variables exist only within the function 'newsbar' code - javascript code outside of function 'newsbar' cannot see these variables. Near the end of the 'newsbar' code, the function calls setTimeout to schedule another run of the function: >news=setTimeout("newsbar(count, delay)", delay); Basically, the "newsbar(count, delay)" is stored as text, and the 'newsbar' function code continues to execute (and eventually exits). When the 'delay' interval has passed (5 seconds in this case), the browser retrieves the text set with setTimeout and evaluates it. The function 'newsbar' can be found easily enough, but the variables 'count' and 'delay' at this point do not exist, because the 'newsbar' function finished executing a little less than 5 seconds ago. >myCmd = 'newsbar(' + count + ', ' + delay + ')'; news = setTimeout(myCmd, delay); The first line in the above code constructs the string that will be set in the setTimeout function call in the second line. The 'count' and 'delay' variables are evaluated while they are still in scope and accessible. Instead of setting "newsbar(count, delay)" to be called 5 seconds later, this code would set something like "newsbar(1, 5000)". Since there are no variables in this function call, there won't be any problems with variables not being defined and accessible due to scoping. I'm not sure why you have a for loop in the 'newsbar' function. From what I can tell, it does not appear to be necessary: >function newsbar(count, delay) { var newsitem = new Array(); newsitem[0] = "some news"; newsitem[1] = "more news"; document.newsform.newsinput.value=newsitem[count]; count++; if(count>=newsitem.length) { count = 0; } myCmd = 'newsbar(' + count + ', ' + delay + ')'; news = setTimeout(myCmd, delay); } The two lines of code you added to the script should have a ';' at the end of each line. Not having them could account for the text not changing when you tested the script. I tested the above code in both IE and Firefox, and it seems to work okay for me. Hope this helps...

I've never run a forum on my site, so I'm not familiar with the Attachment mod you mentioned, but I'll go ahead and make some observations anyway... Unless you have a need to allow .zip files to be uploaded, I would be concerned about allowing people to upload them as they can contain files of any extension within them. Beyond that, restricting uploads only to known image file extensions is a good step. A good approach to securing a site is to deny permission for everything by default, then explicitly grant permission for the few things you want to allow. If the attachments directory is within your public_html directory, yes, it can be accessed from a browser. The index.php does not deny access to the directory - what it does is prevent someone from listing the directory in their browser. If someone knows a file name in that directory, that file can be accessed directly in a browser. To prevent this, you could set up an .htaccess file in that directory: >Order Deny,Allow Deny from all Then the files could only be accessed from a script and not directly from a browser. I don't know enough about your site or your forum software to judge whether its security is acceptable or not. Also, security is always a trade-off - you have to judge for yourself whether a particular risk is worth the effort of defending against or not. The only truly secure site is one that is not on the internet - but such a site would not be of much use to you or your visitors. Part of your job as site owner is to choose a balance between what you will allow visitors to do on your site and what they will not be allowed to do in the interest of security because it could be abused by a malicious visitor. It does sound like you're heading in the right direction though.

Welcome to the forums, Sam! When specifying the upload_max_filesize and post_max_size limits, they should be specified as '100M' instead of '100MB'. ('M' is the proper PHP shorthand notation for 'megabytes').

Generally, PHP scripts will require setting a directory with 0777 permissions because *you* will create the directory, so it will be owned by you, but the PHP script needs to create or modify files in that directory (which could be something as innocent as a configuration file). If you own a directory, the only way you can allow a PHP script permission to create and modify files in a directory that the user 'nobody' does not own is for you to set the directory permissions to 0777. Allowing anonymous, untrusted users to upload anything to your account is a huge security risk. If you must allow them, restrict the extensions of files that they can upload (such as .jpg and .gif for pictures). If they can upload .html and .php files, you're just asking for your site to be hacked. If your site accepts form data submitted from anonymous, untrusted users, make sure your code properly filters and escapes all fields that are submitted, so arbitrary commands and data cannot be injected into your script. If you can, you should set up a separate directory for anonymous uploads that is not under your public_html directory where you can review what has been uploaded before allowing it onto your site. If you're careless with your FTP account names and passwords, malicious code can be uploaded to your site via FTP as well. Make sure you've installed the latest releases of popular scripts such as phpBB or phpNuke, so you have the latest security updates. Hackers frequently target insecure installations of various forum scripts, exploiting known security holes. You should understand that the primary security risk of setting file and directory permissions to 0777 is that anyone with an account on the same server you're on theoretically can access those files and directories. However, TCH does a good job of screening customers, and if one of them does decide to do something malicious, they are quickly tracked down and their account is terminated. Having a script on your account that allows anonymous, untrusted users to upload content to a directory that has 0777 permissions opens up that directory to not just other TCH customers on your server, but to anyone on the internet. Personally, I consider this an unacceptable risk and I won't run any scripts on my site that allow anonymous, untrusted users to upload content to my site. Of the scripts you list, I do run a Coppermine photo gallery. I did not want any Coppermine directories or files to have 0777 permissions, so I modified Coppermine to run as a CGI - meaning it runs under my user ID instead of as 'nobody', and I no longer need to have any directory with 0777 permissions. I don't allow anonymous users upload anything at all. This is by no means a complete list - security is more of a continuing process than an end result.

Welcome to the forums, dharmistha!

You might take a look at the forum topic "Cronjob Of Cpanel Backup".

It sounds like your backup file may be getting corrupted when you download it. If I remember correctly, the CPanel backup should be a .tar.gz file, which WinRAR should not have any trouble reading. Rather than downloading the backup file from your browser / CPanel, you might want to try logging into your account with an FTP program and use it to download the backup file. (Make sure to use BINARY mode to download the file!.) The backup file (.tar.gz extension) is a compressed format, so it is not unreasonable for a backup file that is 80-120MB in size to contain 800MB in actual uncompressed files. Text files (such as .php, .html, .cgi, etc.) compress very well (often 80-90%). JPG images do not compress well, as this image data is already compressed, but unless you have a photo gallery type web site, JPGs will not usually take up a significant portion of the disk space used on your web site. Hope this helps...

Welcome to the forums, songbirdie!

Welcome to the forums, tintin!

The path to the file name should start with '/home/cpanelName' (where cpanelName is the username you use to log into your CPanel). The '/home/cpanelName' directory is the top most directory that you can view in your account (via FTP or CPanel's File Manager). Your web site's 'public_html' directory is actually '/home/cpanelName/public_html'.

This subject has been beaten to death in a number of other forum threads. TCH currently has no plans to upgrade its servers from PHP4 to PHP5. TCH has thousands of customers who are happily running PHP scripts with PHP4, and there is a not-insignificant chance that many of these scripts could be broken if the servers were suddenly upgraded to PHP5. Talk about a support nightmare! The current release of PHP4 is 4.4.0. (I know this because I installed it on my PC yesterday.) The next previous release is 4.3.11. Being only 1 release behind the current one, I wouldn't say that the PHP installed on TCH's servers is "pretty old".