TweezerMan

I'm not sure what you set as the page to be displayed when a 404 error occurs, but it should not include your domain name. From the Apache documentation on the ErrorDocument directive: Your .htaccess file should have something like the following: >ErrorDocument 404 /custom404.html mod_rewrite directives could also cause this issue (I believe), depending on how you set it up (if you're using mod_rewrite at all).

The only reason you wouldn't be able to change the permissions on a file or folder is if you do not own it. Files and folders created by a PHP script are owned by the user 'nobody'. You can't use your FTP program or the CPanel File Manager (which run under your user ID) to change the permissions on files or folders created by a PHP script. When a directory owned by 'nobody' has its permissions set to 0755, only the user 'nobody' has write permissions in the directory. This would prevent your FTP program and CPanel's File Manager (again, which run under your user ID) from creating any new files at all in this directory. That's because you're using a PHP script to perform the upload, which runs as the user 'nobody'. The user 'nobody' has write permissions in the directory, so the script is able to upload the file into this directory.

It is not totally secure. That's why the recommended 'best practice' is to store sensitive data such as usernames and passwords in a separate file not within the web server's document root directory (stored outside of the /public_html directory). If everything is configured correctly, it is relatively secure. If there is a mistake in configuration though, your code could inadvertantly end up being viewable to anyone who browses to it.

Were you thinking of Nvu, Steve?

Welcome to the forums, hyukta!

Welcome to the forums, Heidi!

If you're referring to the list of dates under the 'Archives' heading, yes, you can removed the code if you don't want it to display. I believe this is the code you'd need to remove: > <MainOrArchivePage> <h2 class="sidebar-title">Archives</h2> <ul class="archive-list"> <BloggerArchives> <li><a href="<$BlogArchiveURL$>"><$BlogArchiveName$></a></li> </BloggerArchives> <ArchivePage><li><a href="<$BlogURL$>">Current Posts</a></li></ArchivePage> </ul> </MainOrArchivePage> No, removing this code just removes the list from the page. It would not affect your posts at all. Blogger is pretty limited in functionality. As far as I know, the only way to alter the order of posts is to change to post dates.

Welcome to the forums, xXAlmightyBobXx!

Since the forum moderators here do not have access to the servers or your account, your best bet would be to submit a ticket to the Help Desk and have them take a look at it for you.

What determines the relative security or insecurity of of your database connection info (primarily the MySQL database username and password) is the permissions on the file they are stored in. If the file has read permissions set for 'world' (the last digit when permissions are described numerically), the data can be read by anyone else on the server. If the file does not have read permissions set for 'world', then the file can only be read by you (and the 'root' superuser). If you choose to store your database connection info in a separate file, that file should have only 0600 permissions (read + write permissions for you only) to protect it from being read by someone else on your server. A perl CGI script will not magically protect database connection info hard-coded into the script, if the permissions on the script are not set strictly enough. Most people set permissions on perl CGI scripts to 0755 (read + write + execute permissions for you; read + execute permissions for everyone else). Since everyone has read permissions on the script, another user on your server could use a script to open your CGI script as a regular file and obtain your database connection info. To protect your CGI script from being read by another user's script, the permissions on the CGI script should be set to 0700 (read + write + execute permissions for you only). Because of the way the web server runs CGI scripts, it will still be able to execute your script when it is called in a browser. Then no other users on the server would be capable of reading your script and obtaining your database username and password. Side note: PHP scripts can also be set up to run as CGI scripts. There is some sacrifice in speed, and there are some environmental differences that sometimes need to be taken into account. But a PHP CGI script does run under your user ID, so you don't have to set file and directory permissions wide open to everyone else on your server. Hope this helps...

Welcome to the forums, controller 7!

Welcome to the forums, spongie93!

Welcome to the forums, frano!

I don't use dynamic publishing (and have never used it), but from what I understand, the biggest advantages of dynamic publishing are reduced rebuild times and faster posting of comments and trackback pings (depending on which templates you enable dynamic publishing for). If you haven't already, I believe you need to get an updated version of MT-Blogroll that works with MT 3.2.

Welcome to the forums, MissZoot!

Welcome to the forums, jmack772003!

Welcome to the forums, Chuck!

Go here, and click on the "Submit a Ticket" link. (The link to the Help Desk is also at the top of every page in the forum.)

You have to submit a ticket to the Help Desk in order to have your AWStats manually updated.

If you mean explain how to upgrade your forum step by step, you might take a look at the installation instructions (which also covers upgrading) in the User Guide on the phpBB web site.

Welcome to the forums, MathsIsFun!

Just a guess here, but I think the error message is an indication that your query did not execute successfully. Your code as you have it does not check the result of each interaction with the MySQL server to make sure each action completed successfully before continuing on to the next step. For example, you could test the result of your query operation like this: >$result = mysql_query($query, $handle); if (!$result) { die('Query error: ' . mysql_error()); } Ideally, you'd test your $handle variable to make sure you have a valid MySQL link before you run any queries with it: >$handle = db_connect(); if (!$handle) { die('Could not connect: ' . mysql_error()); } It's hard to tell since you're including code for the db_connect() function, but you may need to select a database to work with before running any queries as well: >$db_selected = mysql_select_db('foo', $handle); if (!$db_selected) { die ('Could not select database foo: ' . mysql_error()); } (...where 'foo' is the actual name of your database.) With this extra error detection, the script will give a better error message as to what is wrong, and it will not continue to run past an error where it would be meaningless to do so anyway. Hope this helps...

MT 3.2 has been released today! Read the announcement at the Six Apart web site for a full run down of the many new features and improvements. I participated in the beta testing of MT 3.2 - this is an upgrade that is well worth getting!

I don't believe you would be able to use Apache::Resource on TCH servers. The directives to implement it have to be placed in the server config file (httpd.conf), which users don't have access to. I'm not well-versed enough in Perl to know if there is a suitable alternative that users could implement within their own accounts. My suggestions would be: 1) If you're writing your own script, write it and test it so that it does not use excessive resources. 2) If you're using someone else's script and excessive resource usage is an issue with that script, I'd recommend looking for another script.

Welcome to the forums, qman! Yes, localhost is the proper value for host. Enclosing it in single quotes is recommended ('localhost'), although enclosing it in double quotes shouldn't cause any issues. Part of your problem is that you're trying to enclose the controluser and controlpass values with a double quote on the left and 2 single quotes on the right (which can be seen above). Unless you're installing phpMyAdmin on a dedicated server, I don't believe you can use the controluser and controlpass settings. Instead, you'd set the MySQL user and password here: >$cfg['Servers'][$i]['user'] = 'xusername'; // MySQL user $cfg['Servers'][$i]['password'] = 'password'; // MySQL password (only needed // with 'config' auth_type) I'm not sure if you're aware of this, but TCH accounts already have phpMyAdmin installed on them. You can access it by logging into your CPanel, clicking on the "MySQL Databases" icon, then scroll down to the very bottom of the page and click on the 'phpMyAdmin' link. Hope this helps...