TweezerMan

Well, a dead battery would probably look the same as no battery, but I don't think what you've listed here is describing the CMOS battery. Because of what it's displayed with, I believe that diagnostic is checking for something like a laptop battery or a UPS - something that could power your computer if the AC power went out. After doing a quick search on the Everest forums, I believe this set of stats may indicate the status of your CMOS battery (sample stats taken from a forum post): If your system has a typical watch battery in it, it should be registering something around 3 volts. If it's dead, I would expect it to register something near 0 volts (a lot less than 3, anyway).

The domain name in a link is how your server (and account on that server) are located when someone clicks on that link. I don't see how you could avoid providing your domain name in a link to a file hosted on your account, other than by using a second domain and second account, placing your files there and provide the second domain name in your links. Tim's suggestion is a variation of that idea - the images are hosted on a non-TCH server (but they are on another domain).

I'm not sure if this would apply, but I've seen this kind of error on older computers where the CMOS battery has died. When the CMOS battery is dead, the CMOS loses any custom settings when the computer is powered off and default settings are used when the computer is powered back on. The mis-match between the default CMOS settings and hardware actually detected on boot is what usually triggers the error (such as installed RAM or disk drives). If your motherboard has a replaceable CMOS battery (mine uses a flat, circular watch battery), replacing the battery would fix the problem.

What is being asked for is possible through the use of mod_rewrite. This particular case is not strictly "URL masking", but mod_rewrite is a powerful tool that can put you in violation of TCH's Terms of Service and Acceptable Use Policy if not used wisely (as TCH-Andy mentions). If you're not sure a particular use of mod_rewrite is within the TOS and AUP, you should ask first. With that said, you would add the following to your .htaccess file in your public_html directory: >RewriteEngine on RewriteBase / RewriteRule ^sunrise$ photos/east_coast/november/124.jpg This will do exactly what you want - a person browses to www.example.com/sunrise, the web server displays the file at www.example.com/photos/east_coast/november/124.jpg, and www.example.com/sunrise remains in the browser's address bar. Hope this helps...

Tim is correct in saying that the problem is most likely due to a common mistake. Checking whether the MT files were uploaded in ASCII or binary: If you uploaded the .tar.gz file to your server, it should have been uploaded in binary mode. If you downloaded the MT archive to your machine (.tar.gz or .zip), unpacked it there, then uploaded the unpacked MT files to your server, they should have been uploaded in ASCII mode. Since all of your MT scripts appear to be generate a 500 error, I'd suggest focusing on the mt-check.cgi script first. The mt-check.cgi script does not call on any other MT files and is the one most likely to run successfully, even when there are problems with other MT files. Since that one does not run, that would suggest it is either a permissions problem, or the script was not uploaded to the server in ASCII mode.

I'm not a "tch tech", but I can help you figure out what's wrong. What page are you receiving the "internal server error" (500 error) on? (Also, the URL to your mt.cgi script would be helpful.) Is there any error message showing up in your CPanel error log? Are the permissions set correctly on the MT *.cgi scripts (0755)?

Not true, iframes between HTML and XHTML are identical. <{POST_SNAPBACK}> Bruce is indeed correct - iframe tags are allowed with any of the XHTML 1.0 DOCTYPEs (Transitional, Strict, and Frameset). I looked up and read the actual DTD specs - the iframe tag is listed in all of them. I believe you are encountering a bug in IE6. I loaded your page's HTML code into FrontPage locally on my machine and see the same identical behavior. The bug has something to do with the fact that your iframe is in a table cell and the fact that you are using a percentage for the height and width of the iframe. I believe the exact nature of the bug (from what little I've been able to find on the internet and from my testing here) is that when you specify the height and width of an iframe as a percentage, IE6 is unable to calculate what the height and width should be unless the height and width are explicitly specified in the iframe tag or its parent element (the containing td tag in this case). Since IE6 does not know what size the iframe should be, it doesn't draw one at all on the page. On the copy of your page I made within FrontPage, I removed the iframe (cut it out) and placed it after the closing /table tag on the page. The iframe displayed correctly there. I put the iframe tag back where it was, and changed the height and width on the iframe to pixel widths instead of 100%: ><iframe src="specials.htm" height="280" width="610" name="frame" scrolling="auto" frameborder="0" id="frame"> This also displays the iframe correctly. I changed the height and width on the iframe tag back to 100%, and specified an explict height and width on the containing td tag: ><td colspan="4" rowspan="15" bgcolor="#b8bcf8" height="280" width="610"><iframe src="specials.htm" height="100%" width="100%" name="frame" scrolling="auto" frameborder="0" id="frame"></iframe></td> This also displays the iframe correctly. Specifying height="100%" and width="100%" in the containing td tag does *not* work - the iframe is still not displayed. Strange bug. Hopefully, the info I've provided above will give you an acceptable way to work around it.

As noted in this post from a thread you've posted in today, it is apparently a known bug in MT 3.15 and the plugin patch provided by Six Apart. It is supposed to be fixed in the next release of MT (v3.16), but the release date is currently unknown.

I just looked at the Notifications page in mt.cgi - it appears to do the same thing as the form I mentioned. I'm not real familiar with the Notification functions in MT as I don't use them at all and have never used them. The way MT is set up, I believe that you'd have to send a notification e-mail to the list-serv. The MT code always sends a copy of the notification e-mail to the entry author, so the author can see what is being mailed out.

I'm not sure I am 100% clear on what you're trying to do, but there's some misunderstandings here I may be able to clear up. There is no such thing in MT as a "blog owner". Blogs are not owned by anyone. Authors in the MT system are granted permission to do various things with blogs, but no author is ever designated as "owner" of any blog (regardless whether that author created the blog or not). The entry notification that you see mailed out is the one that is mailed to the entry's author. When the entry notification e-mail is sent out, MT looks up the author for that entry, grabs the e-mail address stored for that author, and sticks that in both the "To:" and "From:" fields of the notification e-mail. If you want a notification to be sent elsewhere, I believe you need to subscribe the e-mail address to receive notifications. The process for doing so is documented in the Notifications section of the MT manual. You'll need to set up at least a temporary page with the subscription form to subscribe the e-mail address. After subscribing the e-mail address, you can delete the page if you don't want to keep it around. Once the e-mail address is subscribed, then after posting a new entry, you'll be able to send the notification by using the "Send a Notification" section at the bottom of the "Edit Entry" page. From what you've described, the patch is functioning exactly as it was designed to - to prevent someone from injecting addtional e-mail addresses into an e-mail being sent from the MT system. Hope this helps...

You can't use Directory or Location directives in an .htaccess file - Apache does not allow it. The help desk could put such a directive in the server's configuration file, but I'm not sure if they'd be willing to do that (my instinct says they would not).

Actually, you are only supposed to get an e-mail when there is a problem. When a script is run from cron, *any* output by the script is e-mailed to you. I suspect that somewhere in the script, a blank line is inadvertantly being output, resulting in the e-mail you're seeing every day from cron.

I think the banner looks nice on your site - I don't think that the physical dimensions are too large. In terms of bandwidth though, the image itself is about 50K - the image will definitely take some time to download for anyone viewing the site on a dial-up connection. Side-note: I still cannot see your background image in Firefox, and I'm not really sure why. The CSS code itself appears to be valid, because when I was testing your site's code in Front Page, I uploaded a copy of your image to my web site and changed the background URL to point at it, and it displayed correctly in both Internet Explorer and Firefox. The only thing I noticed that seemed odd about your site: When I first loaded the code for your web site into my local copy of Front Page and did a preview of the page, I was shown a login box, saying: ...with a Name and Password box, and an OK and Cancel button. It didn't matter if I clicked the OK or Cancel button (I always left the Name and Password boxes blank) - either way, the preview then displayed the copy of your web site. Maybe it's nothing - I don't know. I'm just at a loss at the moment to explain why your background won't display in Firefox (although I wonder if it's connected).

From what I can tell, you have two problems: 1) The background image file name has spaces in it. This prevents browsers such as Firefox from being able to load and display the image (although Internet Explorer does not appear to have this problem). I would suggest renaming your image file on the server from "Allens Ruminations 04.jpg" to "AllensRuminations04.jpg" (or even "Allens_Ruminations_04.jpg" if you want to preserve the spacing in the name). 2) The CSS you have for displaying the background is not correct. This is what I see in your stylesheet: >#banner { font-family: Comic Sans MS; color: #FFFFFF; background-color: #8F7363; text-align: left; padding: 15px; border-bottom: 1px solid #242424; height: 39px; } #banner-img { display: <img alt="Allens Ruminations 04.jpg" src="http://www.demesneofallen.com/images/banner/Allens Ruminations 04.jpg" width="625" height="75" />; } To display your background image, your CSS should look something like this: >#banner-img { background: url("http://www.demesneofallen.com/images/banner/AllensRuminations04.jpg"); } (using alternate file name for image as described in #1 above.) The #banner-img style is not referenced anywhere in your web page, so putting the background there is not going to do anything. Just to get it displaying, move it to the #banner style: >#banner { font-family: Comic Sans MS; color: #FFFFFF; background-color: #8F7363; text-align: left; padding: 15px; border-bottom: 1px solid #242424; height: 39px; background: url("http://www.demesneofallen.com/images/banner/AllensRuminations04.jpg"); } #banner-img { } Making those 2 changes allowed me to see the background image in both Internet Explorer and Firefox browsers. Hope this helps...

I'm not sure exactly what NetMechanic is looking for, but if you run your home page through the W3C HTML Validator, there's quite a few errors detected for things on your page that are not within the DOCTYPE spec. If you cleared those up, maybe NetMechanic would quit reporting that last error you're seeing.

Don's suggestion may work, but I'd recommend using a full HTML 4.01 DOCTYPE declaration instead of an HTML 4.0 one, since HTML 4.01 is being used now: ><!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">

I've never tried renaming a 16x16 .bmp file to .ico to make an icon - I thought that the file formats were different, so renaming would not be sufficient. I use the free IrfanView program to open the image I want to convert and do a "Save As" to save the image as a .ico file. On the 301/401 errors: 301 is a "Moved Permanently" error message. Have you reorganized your site and moved parts of it, then used a redirect to indicate the new location of your content? These can be set up in the "Redirects" app in your CPanel - creating a "Permanent" redirect would cause a 301 error to show up in your error logs when a user (or a bot) tries to access the old URL. You might take a look at the Redirects in your CPanel and see if anything has been set up there.

I see it more like this: What if you leave a working telephone in front of your house at the edge of your property? Would it be legal for anyone to just come up and use it?

I downloaded the patch and looked at it. If I understand it correctly, it is a patch to the main AWStats code, which is something that you would not be able to apply.

For an <img> tag, the allowed values for the align are left, right, top, middle, bottom. Looks like "middle" is your answer here. That last error seems to be saying that something in your page does not conform to the standard declared by the DOCTYPE statement at the top of your page: ><!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> I don't see anything obvious that would account for that kind of error though.

That's what Search/Replace -> Replace All in your favorite editor is good for.

Clearly I had a head start - I'm not *that* fast!

You have a tag that looks something like this: ><td align="middle"> The allowed values for the align attribute in a <td> tag are center, left, and right. So what you need to do is change the align attribute from middle to center: ><td align="center"> Hope this helps...

1) This is the command I use in a cron job to make a backup of my MySQL database each day: >mysqldump --quick --all --add-drop-table --add-locks --lock-tables --quote-names --user=cpanelname_dbusername --password=dbpassword cpanelname_dbname | gzip -c > /home/cpanelname/path/to/backup/folder/dbname-daily.sql.gz cpanelname = your CPanel user name dbusername = your MySQL database user name dbpassword = your MySQL database password dbname = your MySQL database name The mysqldump utility has a lot options - you can read about all of the options it supports in the MySQL documentation for mysqldump. 2) Searching the forums, I found this thread, which discusses MySQL database backups and includes a link to a php script that will make a MySQL database backup and optionally e-mail it to you. 3) Search the forums for mysqldump - there's about a dozen threads with discussion on it and database backups in general.

My first suggestion would be to try to get assistance for your script from wherever you got it from. Just a guess here, but the error message you're receiving may be an indication that some MySQL parameters in your script or PHP-Nuke are not configured correctly. The PHP function mysql_fetch_row() returns one row of a MySQL query previously executed in the code. I suspect that the query is what's actually failing, so mysql_fetch_row() has nothing to fetch from.