TweezerMan

Welcome to the forums, milleniumgoddess!

Welcome to the forums, FSUGAL!

Welcome to the forums, Serge! Line 23 is giving you an error because you're trying to use object methods (indicated by the '->') instead of calling the regular PHP MySQL functions to run (and fetch) your query. That line should be coded as follows: >$result = mysql_query($query, $handle); You'll also run into the same problem with the next line (line 24). It should be coded as follows: >while ($story = mysql_fetch_assoc($result))

You can PM me with details on how I can look at the code.

If you remove this from your mt.cfg file, MT will use Berkeley DB as the database driver instead of MySQL, and will try to access a different database stored as files on your server, rather than the database on the MySQL server. That sounds like you're trying to run MT-Medic while you have the above database options disabled / removed from your mt.cfg file. Previously, you said this DBUser worked without errors from the MySQL server: >DBUser newsbeak But now you've gone back to trying to use this DBUser, which never worked: >DBUser beak If you want to use MySQL for your MT database, you need to leave the database options in place in your mt.cfg file. You need to configure mt.cfg to use a MySQL username (DBUser) that has access to the MySQL database on your server. *Then* you can look at whatever error messages are still occurring and figure out how to address them, but it won't involve messing around with the database settings once you get valid ones working.

TCH-Thomas is using regular HTML tags in his icon code instead of BBCode tags. In your case, it would look something like this: ><a href="callto://cajunman4life"><img src="http://www.skypepresence.com/callbutton/cajunman4life.gif" border="0"></a>

Welcome to the forums, Pablo!

That error message indicates that mt-load.cgi has already been run once. Is this a new installation of MT, or are you trying to get into an existing one? If this is a new install of MT, and logging in with Melody/Nelson does not work, you'd need to delete (drop) all of the tables in the newsbeak_com database, re-run mt-load.cgi, then log in with Melody/Nelson. If this is an exisiting installation (there's weblog data already entered that you want to keep), then you'd need to install the MTMedic tool that Marie linked to, and use to reset the password in the database.

I think the Authenticated Users section of AWStats is showing any user that attempts to access a page requiring authentication, and records whatever text is entered in the username box. It looks to me like a dumb bot tried to hit one of your authenticated pages, and entered the URL it's spamming in the username field. It would not have gained access, and since there was only one attempt, it is not something that I would be particularly concerned about.

Did you run mt-load.cgi first, and if so, are you logging in with the default username/password of 'Melody' and 'Nelson' (both are case-sensitive)?

Scratch that last post...I did some further checking of the domain name, and it does not appear to be resolving properly. You should submit a ticket to the Help Desk and have them investigate this issue for you.

From what I can tell, that error probably occurred because your domain name had not fully propagated yet. You might give it a try again and see if it works now.

Welcome to the forums, Mike!

You might try changing the database user name in your mt.cfg file so it is prefixed with your domain name like your database name is: >DBUser newsbeak_com_beak

Welcome to the forums, Dori!

On the server, you should check your database in the Database Manager and make sure that 1) a database user 'beak' exists, and 2) the database user 'beak' has permission to access the 'newsbeak_com_blog' database. Normally, you would need to 'add' the user to the database to give the user access permissions as a separate step after you have created the database user. Another possible cause of this error is that the password (the one for the database user 'beak') is not specified correctly in the mt-db-pass.cgi file.

It appears that Dreamweaver uses a configuration file that specifies what file extensions are uploaded to the server in ASCII mode: I guess you'd need to edit the FTPExtensionMap.txt file and add 'cfg' (or possibly '.cfg') to the file, and specify 'ASCII' as the transfer mode to have DreamWeaver upload the mt.cfg file properly.

The mt-check.cgi script is not that helpful, as the problems are either in the mt.cfg or the MySQL database, neither of which are examined by mt-check.cgi. I'm seeing a number of issues with your mt.cfg file: 1) The mt.cfg file was not uploaded to the server in ASCII mode, so MT will not be able to read the mt.cfg file correctly. MT will not see any of your mt.cfg settings and will try to run with just the pre-programmed system default settings. After editing the mt.cfg file on your local PC, you need to make sure your FTP program uploads the mt.cfg file to the server in ASCII mode. 2) There are two sets of database configuration settings in mt.cfg, both commented out: a) At line 35 in mt.cfg: ># ObjectDriver DBI::mysql # Database newsbeak_com_blog # DBUser beak #DBHost localhost b) At line 507 in mt.cfg (at the end of the file): ># ObjectDriver DBI::mysql # Database newsbeak_com_blog # DBUser shanda # DBHost localhost There should only be one set of database settings in the mt.cfg file. I'd recommend deleting the settings added at the end of the mt.cfg file. In order for MT to recognize any setting in the mt.cfg file, it must be uncommented (any "#" at the beginning of the line needs to be removed). The database settings ObjectDriver, Database, and DBUser need to be uncommented, and should look like the following (using the settings at line 35 as an example): >ObjectDriver DBI::mysql Database newsbeak_com_blog DBUser beak #DBHost localhost 3) The CGIPath setting in mt.cfg is not correct. >CGIPath http://WWW.newsbeak.COM/mt/ URLs are case-sensitive - a URL such as this will usually cause problems. I'd suggest changing this setting to the following: >CGIPath http://www.newsbeak.com/mt/ 4) mt.cfg file should be protected from viewing in a browser. Anyone can view your mt.cfg file (as I did) if they know the URL to your mt.cfg file. Since MT is not installed in a cgi-bin directory, you should protect your mt.cfg file from being viewed in a browser by adding the following to the .htaccess file in your /mt directory: >Options All -Indexes <Files mt.cfg> <Limit GET> deny from all </Limit> </Files> Hope this helps...

If I understand the messages correctly, the script is stopping because the DB_File perl module is not installed on your server. Assuming this is the case, you'd need to submit a ticket to the Help Desk and ask them to install it for you.

The behavior of PHP scripts on the server has not changed. I'd suspect that your file and directory permissions were somehow changed from what they were 6 weeks ago.

As Mambo is a PHP script, it runs as the user 'nobody'. In order for it to create and delete files in a directory (one that you own), the directory permissions must be set to 0777, and file permissions on a file that you own must be 0666 in order to modify the file. 0775 directory permissions and 0644 file permissions would not be sufficient to allow Mambo to create/modify/delete files.

Apparently, sqlconnect() is a function defined in some other PHP file. I imagine the script code is probably using an include() or require() so it can access the functions in it, but something isn't right in the script code that specifies the path to that file. Without being able to look at the source code or trace the code execution, I don't have any way to tell you exactly what's wrong or how to fix it. By the way, welcome to the forums, rolloff!

You can't call a PHP script from a cron job with parameters such as '?op=cron' tacked on the end of the file name. The responder.php script would need to modified so the script can receive the parameter when it is called like this in the cron job: >php -q /home/denverc/public_html/mailer/admin/responder.php op=cron You might take a look at this code I wrote for someone else experiencing this problem with another script. Your script could require additional code though, depending on how the script is written.

Honestly, I would not. The bot has already wasted a bunch of bandwidth on your site, it is not a well-behaved bot, and they've had months to fix problems with the bot and apparently have not done so. I wouldn't give them a second chance or the benefit of doubt, but you can make your own decision.

Make sure the script's permissions are set to 0755. If that does not appear to be the problem, check the "Error Log" in your CPanel and see if an error message was recorded there.