TweezerMan

The buttons are predefined fields that the server will fill in at the time a user actually encounters a 404 error. For example, the server will replace the code for "Requested URL" with the URL of the page that user was actually trying to browse to. My 404 page has the following code in it: ><p>The page you requested could not be found (Error 404):<br /> http://<!--#echo var="HTTP_HOST" --><!--#echo var="REQUEST_URI" --></p> The code on the second line is what's needed to build a full URL of the requested page. It's "http://" plus the code from the "Server Name" button, then the code from the "Requested URL" button. I don't know that any of the code from the other buttons would be of much use on a 404 page, unless you just want to display it because you can. There is no requirement that you use code from any of the buttons - it is up to you what you want to display on your 404 page. There is no preview available in the CPanel editor - about all you can do is save the page, then deliberately browse to a URL on your site that you know doesn't exist, causing the server to show you the 404 page you just saved. You can't really "stop" the visitor from closing their browser, but you certainly can include a link back to your home page (I have one on my 404 page as well). The codes are just fields, each representing a piece of information to be displayed. Wherever you want to display one of those fields, you insert the code for that field by clicking one of the buttons above the editor. Yes, the code is an HTML comment, but within the comment is special code that has meaning to the server, and the server will process that code when it serves the page. When you save the file in the "CPanel .shtml editor", it will be automatically saved on the server as 404.shtml (unless you rename it to something else). You don't need to do anything further other than save it. Hope this helps...

No one can look at the URL you've posted, as you need to have an MT login to view it. (Don't post it here in the forums!) Can you do a "View Source" of the page and see if all the HTML is there, or if the HTML code stops in the same place the page display does is your browser?

No - the warning is just advising that you should not install FrontPage Extensions unless you intend to use them (which you are). No - you can publish from FrontPage and upload via FTP however you see fit. I'm not sure about this one, as I don't use FrontPage to publish my site. One thing that comes to mind is that you may have some files that you need to upload to the server, but aren't a part of any page you've built with FrontPage. I imagine you'd need to FTP files like that to the server. I use FTP to upload my files, but that certainly not the only way. Whatever works best for you is probably the best way.

You're probably not able to execute that command because in order to create a directory, the user ID that the script is running under has to have write permissions in the parent directory, and 1) that directory is owned by you, and 2) it does not have 0777 permissions. If you CHMOD the parent directory of $upload_dir to 0777, then you should be able to use your PHP script to create $upload_dir, which would be owned by 'nobody' and have 0777 permissions. Once your script has created the directory, you can reset the permissions on the parent directory back to what they were (0755?).

Click the "Select All" link to select all of the tables in your MT database. Select the "Structure and data" radio button option. The only box you need to check is the "Save as file" checkbox. I'd recommend selecting the "zipped" option, as this will substantially reduce the size of the file. You may want to name the export file yourself, so you can easily find and identify it. Just type a name with no extension (phpMyAdmin will add the extension for you). When you click the "Go" button, the export file should be created then downloaded to your machine. Hope this helps...

The images look fine to me in both Firefox and IE - they appear to be as you say they are supposed to be. I'd first suggest deleting the files in your browser's cache, then reload the page and see if the images are still 'deteriorated'.

Users are only allowed to CHMOD files or directories that are owned by that user. This is not due to a config setting in PHP or the web server - it is a security feature of the operating system. PHP scripts run under the user ID of the web server, which is 'nobody'. This means that PHP scripts can only CHMOD files and directories that are owned by the user 'nobody'. In your case, $upload_dir is owned by you (your user ID), so your PHP script is not allowed to change that directory's permissions with CHMOD. Your script is able to CHMOD files because those files are owned by the user 'nobody'. I'm guessing that your script is changing the permissions of files that were uploaded by the script. Since the script is creating those files on the server, they are owned by the user running the script - 'nobody', and with the script running as 'nobody', it is allowed to change their file permissions. I think your best bet is to set the directory permissions to 0777 yourself and leave them there, since your script isn't able to change them anyway. Hope this helps...

Welcome to the forums, Kara!

If the web server's user ID owns the Mambo files and directories, I think it would be difficult (if not impossible) to update Mambo's files, as you won't own any of the files and directories, they most likely won't have 0777 permissions, and you may not be able to change the permissions yourself.

Welcome to the forums, Mark!

I don't have a gmail account, but it appears to be a common problem that doesn't have just a single (or definite) solution. Some suggested options to try: 1) When the blank page loads, try hitting F5 (Refresh) and see if that will make the page load. 2) Delete your internet cache and cookies, then try logging in again. 3) Try logging into your account at: >https://gmail.google.com/gmail (note the https) 4) Add gmail.com as a trusted site to whatever firewall application you're using on your computer. Hope this helps...

Submit a ticket to the Help Desk and ask them if they can add PHP-Nuke to your CPanel/Scripts Library.

Welcome to the forums, chronofire! Look under "Scripts Library" in your CPanel and see if there is a link there for you to install PHP-Nuke under "Communities/Forums".

I don't know that a full tutorial is required. I think the easiest way would be to use a 'cp' command in a cron job, configured with the "-a" archive option (don't follow symbolic links, preserve file attributes, and recurse subdirectories), and suppress any prompts that might appear: >cp -a --reply=yes /home/cpanelName/public_html/dirA /home/cpanelName/public_html/dirB Excluding files means you aren't performing a true synchronization any more - it's more like a "selective copy". I think you'd need a CGI script to perform the copy from one directory to another - then the script could allow you to specify files not to be copied. The reason you'd need a CGI script (perl or PHP) is to preserve ownership of the copied files - files copied by a CGI script will be owned by "you" instead of "nobody". You'd then run the CGI script as a cron job instead of the 'cp' command I described above. Hope this helps...

Adobe officially stopped selling Adobe PhotoDeluxe 4.0 about 3 years ago. The system requirements for Adobe PhotoDeluxe 4.0 included: The fact that PhotoDeluxe 4.0 could run on Windows NT indicates that might run on Windows XP (but no guarantee on that). I would be very hesitant to install and use software that is that old and no longer supported. It appears that Adobe's replacement product for Adobe PhotoDeluxe is Adobe Photoshop Elements (or maybe Adobe Photoshop Album). There's a number of different graphics editors available that don't cost an arm and a leg, but whether any of them would suit your needs depends on what features you used in Adobe PhotoDeluxe. In addition to TCH-Rob's suggestions, you might take a look at Google's Picasa.

By forcing updates of AWStats, the statistics aren't what I would call "more accurate" or "better" - they are just more recently updated. AWStats is not intended to be a "live" statistics program, but the stats you see in AWStats should be no more than 24 hours old. Depending on what you're wanting to see, there may be a better way to get it than by performing AWStats updates. Running AWStats updates is indeed very CPU intensive, and performing excessive updates could get you in trouble with the server admins (your account could get suspended). Even performing a single update could get you in trouble if it drags down the server too much. See TCH-Bruce's answer above.

Welcome to the forums, Daya!

It depends on whether you're talking about a feed you produce (yes), or one from another site (no). What the Feed Vailidator is talking about is 1) the encoding declared in the first line of the feed, and 2) the encoding declared in the HTTP headers sent by the server. My site's XML feed has the following in the first line, declaring an encoding of "UTF-8": ><?xml version="1.0" encoding="utf-8"?> My server does not send a character encoding in the HTTP headers, so there is nothing to conflict with. If the server did send a different encoding in the HTTP headers (like "ISO-8859-1"), that is something I'd probably take up with the Help Desk (although there are ways to possibly address the issue yourself).

I don't know that you'd see errors from your script in the error log. Usually, errors that occur in a cron job are e-mailed to you. You did enter an e-mail address in the "Please enter an email address where the cron output will be sent:" box on the Cron Jobs page in CPanel, right? Have you checked your e-mail to see if you've received a ton of e-mails from cron by now? You can't call a php script like that in a cron job, shared hosting or not. Are you sure the script is working on your new server (can you call it successfully in your browser)? What is the cron job command that you're currently trying to use?

It looks to me like whatever RSS/XML feed that CaRP is trying to read has some invalid XML code in it. You might try running the URL of the feed through the Feed Validator and see if the feed has XML errors. If it does, you have to contact the publisher of the feed to have them correct the problem.

Welcome to the forums, stix! How did you set up the time for the cron job to run?

Running IE 6.0.29 here.... The drop-down menu is a bit "jerky" if my CPU usage is near 100%, which is easy to trigger by moving the mouse quickly over each menu option one after the other. There may also be some "jerkiness" due to IE trying to render a tooltip at the same time a menu is dropping down when the mouse is hovered over one of the menu options. The CSS rollover button appears to be pulling the background image from the server every time the mouse is moved over or away from the image - I'm seeing traffic on my ZoneAlarm icon every time the background changes. For some reason, it looks like IE is not caching the image. Firefox does not exhibit this behavior. Hope this helps...

Welcome to the forums, netmasterbill!

I have a cordless optical trackball that "never" needs cleaning according to the manufacturer, but I have to take it apart and clean out the little wads of dust and fuzz that accumulate around the points the trackball rests on when I replace the battery (about once a month).

The vulnerability was announced back in January, and discussed on the TCH forums here. It has to do with the AWStats "AllowToUpdateStatsFromBrowser" config option being enabled. By default, this is set to "0" (disabled) and your stats are "locked out from the rest of the world". You would have had to manually configure AWStats to "unlock" them by setting the "AllowToUpdateStatsFromBrowser" option to "1".