TweezerMan

Welcome to the forums, Evan!

Welcome to the forums, tdsphot!

Welcome to the forums, Kempo!

Welcome to the forums, windmill74!

I don't know why you weren't seeing the warning messages before, but unless your script or configuration specifically addresses the issue, you should be seeing them like you are now. If you don't want to see the messages, you'd need to do something to suppress them (there's a number of ways to do this).

Welcome to the forums, huzursuz!

I thought it was because the timezone was being adjusted for local Italy time, which is GMT+1. gmdate() wouldn't have been any help for that.

We3lcome to the forums, Mr. Coot!

Welcome to the forums, Jack!

Welcome to the forums, Barb!

Keep in mind this is just my personal opinion (based on experience): The OmniExplorer bot is a bad bot, and you should not implictly trust or believe what is on the OmniExplorer web site about that bot. 1) The OmniExplorer bot has been reported to not obey robots.txt files. 2) The OmniExplorer bot has been seen using a much larger range of IP addresses than what is reported on the OmniExplorer web site. 3) The OmniExplorer bot is known to rapdily consume excessive bandwidth. 4) Any bot that misbehaves so badly should have been immediately terminated, rather than allowed to run wild on the internet. I have blocked the OmniExplorer bot in my robots.txt file, but since I don't trust the OmniExplorer bot to obey it, I've also blocked it both by user agent and by IP addresses in my .htaccess file: ># Bad bot - OmniExplorer SetEnvIfNoCase User-Agent "^OmniExplorer" bad_bot deny from 64.62.175.133 deny from 64.62.175.134 deny from 64.71.131.110 deny from 64.71.131.114 deny from 64.71.131.117 deny from 64.71.131.121 deny from 65.19.134.7 # Block 65.19.150.192 - 65.19.150.255 (64 IPs) - OmniExplorer bot deny from 65.19.150.192/26 # Block 65.19.169.192 - 65.19.169.255 (64 IPs) - OmniExplorer bot deny from 65.19.169.192/26 deny from env=bad_bot I don't know if the IP address list is complete - it's what I compiled a while back from my own server logs and possibly some other internet sources. TCH forum member annie also has an entry on her Spamhuntress wiki about the OmniExplorer bot. Hope this helps...

Welcome to the forums, Fred!

TCH-Don is correct about the download vs. upload speeds - and this applies to dial-up connections as well. My DSL service has a maximum download speed of 3.0Mbps (3000kbps), but only 128 kbps maximum upload speed. I can download files on my DSL connection up to 20 times faster than I can upload them. A dial-up user with a 56K modem and connection can download at a max speed of 56 kbps, but the max upload speed is only 33.6kbps (60% of the 56kbps upload speed). FTP upload/download of large files: Based on what you've described, it sounds like your connection is being disconnected after a 5 minute timeout (the 30-50MB is what you can typically upload in 5 minutes over a DSL connection). The timeout period is (I think) the time limit for issuing a command to the FTP server that establishes a new data connection. You'd need to do something with the FTP server while your large file is uploading (no less than once every 5 minutes) that will create another data connection, such as upload/download a file, or retrieve a directory listing. FileZilla has a 'keep alive' feature, but I don't believe it would keep you from being timed out, as I don't think the commands it issues ('PWD', 'REST 0', 'TYPE A', or 'TYPE I') create new FTP data connections, and there does not appear to be any way to modify the list of commands it issues. There is also this note in the FileZilla documentation: If the 'no-transfer timeouts' is interpreted to mean 'no *new* transfer timeouts', then FileZilla's 'Keep Alive' feature indeed would not stop you from being timed out during a large file upload or download. With FileZilla, you'd need to manually upload/download some small file on your server, or list the files in some directory at least once every 5 minutes while your file is uploading so the FTP server doesn't time out your connection. Another option is to use another FTP program where you can configure the FTP commands used to 'Keep Alive' an FTP connection. I use SmartFTP, which does allow this. The only other option I can think of would be to submit a ticket to the Help Desk and ask if the timeout period can be increased. But I don't know how willing they would be to do that. Hope this helps...

Welcome to the forums, Bryan!

Good luck, Michelle, and congratulations, Bill!!

Welcome to the forums, newsbeak! TCH-Don's correct - many hosts require you to add your CPanel username plus an underscore ("_") to the Database and DBUser parameters in your mt.cfg file. Another common cause of this error is to not remove the literal text 'database_password' from the mt-db-pass.cgi file - your password is the only text that should be in the file.

For a directory owned by 'nobody' where the permissions not set to 0777 (such as 0755), you would not be able to create or delete files and subdirectories in that directory from your FTP program or CPanel. If a file is owned by 'nobody' and its permissions are not set to 0777 (such as 0644), you would not be able to edit the file except via a PHP script. You would also not be able to change the permissions on a file or directory owned by 'nobody' using your FTP program or CPanel, as you have to own the file or directory in order to change its permissions. Again, you'd have to use a PHP script to change permissions on a file or directory owned by 'nobody', or submit a ticket to the Help Desk (who can change the owner and permissions on any file as the 'root' superuser).

I'm currently seeing your main index page - is it because you fixed the problem, or you removed the referer script again until you figure out what the problem is?

I almost forgot - you can work around this issue if you'd rather not spend time on trying to figure it out and resolve it. In mt/lib/MT/Template/Context.pm (3.121 version), scroll down to line 1565, where you should see the following code (line 1565 is the second line below): > if ($c->id && !$args->{no_redirect}) { return sprintf(qq(<a target="_blank" title="%s" href="%s%s?__mode=red;id=%d">%s</a>), $url, $cgi_path, $comment_script, $c->id, $name); Change the ';' to '&': > return sprintf(qq(<a target="_blank" title="%s" href="%s%s?__mode=red&id=%d">%s</a>), Save the file, re-upload Context.pm to the server (in ASCII mode), then rebuild at least your Individual Entry Archives so the commenter links will be updated.

I've looked at the site - the HTML code for link appears to be correct. As near as I can tell, something on the server is objecting to something specific in those comment links. As you know, this URL currently displays a '403 Forbidden' error page: >http://www.eatitandloveit.com/cgi-bin/mt/mt-comments.cgi?__mode=red;id=81 However, if the ';' in the link between the '__mode=red' and 'id=81' is changed to an '&': >http://www.eatitandloveit.com/cgi-bin/mt/mt-comments.cgi?__mode=red&id=81 ...the link works properly and the user is redirected to the correct page. I've tested comments links with the ';' in my own MT installations and they work properly, so it doesn't appear to me to be a problem with the link itself. Do you have anything in your .htaccess files that restrict access to files in any way? When a user browses to one of the comment links like the above, the server will read the .htaccess files in your /public_html, /public_html/cgi-bin, and /public_html/cgi-bin/mt directories in figuring out what should and shouldn't be allowed, so you'd need to look at all of them. Another possibility is that something has been added to the mod_security configuration for your server, and your commenter links are getting inadvertantly blocked by it. If this is the case, you'd need to submit a ticket to the Help Desk and ask them to investigate it.

You can use mkdir('/pathname'); to create the directory, and chmod('/pathname', 0777); to set its permissions. The directory will be owned by the user 'nobody' instead of you though, since PHP scripts run as that user.

Glad to hear that it's finally working!

Welcome to the forums, Juri!

I think what could be wrong would depend on how the 'deleteable' database came into being. If you did not create it, I'd suggest submitting a ticket to the Help Desk.

I created my own test database and tried importing a tab delimited file with a script and queries pretty much as you have. The 2nd query (the 'LOAD DATA INFILE' one) would trigger an error, but the first one did not. I added '. mysql_error()' to the die messages for each query, and discovered the 2nd query was failing with an "Access denied" message. In order to execute a 'LOAD DATA INFILE' query to read a file on the server, the MySQL user must have the MySQL 'FILE' privilege. It would appear that granting a MySQL user 'ALL' privileges in phpMyAdmin does not include the 'FILE' privilege. There is a way around this, however. When you import a file that is on your local computer, phpMyAdmin is executing a 'LOAD DATA LOCAL INFILE' query. The 'LOCAL' keyword tells the MySQL server that it needs to get the file from the client computer (your PC in this case - local to you) instead of the MySQL server. Executing a 'LOAD DATA LOCAL INFILE' query does not require the MySQL 'FILE' privilege. Your script can take advantage of this by running a 'LOAD DATA LOCAL INFILE' query instead of 'LOAD DATA INFILE'. The MySQL server still thinks it needs to get the file from the 'client' computer, but in this case, your script running on the server *is* the client, and you can specify a server path to the file anyway without having to have the MySQL 'FILE' privilege. I was able to successfully import a tab delimited file with this query: >$sql2 = "LOAD DATA LOCAL INFILE '/home/my_host/public_html/folder/test.txt' INTO TABLE sometable FIELDS TERMINATED BY '\\t' LINES TERMINATED BY '\\r\\n' IGNORE 1 LINES"; Whether or not you need '\\r\\n' or '\\n' for 'LINES TERMINATED BY' would depend on how your files are being created and uploaded to the server. Try '\\r\\n' first, and if the data didn't import correctly, then try '\\n'. Hope this helps...