TweezerMan

And Old Timer also said this: So is it price gouging when the merchandise already in stock has the price drastically increased because it is in demand and a necessary item? Seems to me the price for that gas already in the tanks was set the day the tank was full and that the gas station owner will be billed for that amount of fuel at that set price. So how can it be justified to increase the price when you haven't been charged an increase in price yet???? <{POST_SNAPBACK}> It is true that the gas already in service station storage tanks has already been bought and paid for, but at least part of the price of a gallon of gas is how much the service station owner has to pay to *replace* the gallon of gas they sell you. I imagine that service station owners are expecting wholesale prices to increase (they'll have to pay more to get their storage tanks refilled), so they are passing the anticipated increase in their costs to the customer. If they didn't, the increase in wholesale price would come out of the service station owner's pocket until they could sell the entire next shipment of gas. Prices were already high out here, but they're going up too. This morning, a relative was looking for gas and saw a station selling gas for $2.99, with a long line of cars waiting to fill up. This afternoon, that same station is seliing gas at $3.15.

A 403 error is a 'Permission denied' error that is returned by the web server. I'd suggest looking at the .htaccess file in your /oicforum directory to see if there's any directives in it that would block access to the index.php file. If you don't find anything in that .htaccess file, go up in the directory tree to the parent directory and look at its .htaccess file, repeating as necessary until you find the problem or you reach the /public_html directory in your account (which is the top level web directory). Hope this helps...

I think the best answer would depend on what URLs you are using on your local machine to access these pages. Without knowing that, I can't really tell you any details on how you would implement a particular solution. You may be able to use one of the following methods to do what you want: 1) VirtualHost directives in httpd.conf file 2) Alias directives in httpd.conf file 3) mod_rewrite directives in httpd.conf file or .htaccess files Hope this helps...

I guess my first question would be 'how big is your mailing list?'. If Mailman tries to send more e-mails out at one time than what the TCH servers allow, I believe the excess e-mails are just dropped and will not be sent. For specific details on what limits are in place on the TCH e-mail servers, please submit a ticket to the Help Desk.

Welcome to the forums, dasadowski!

Looking at the source HTML, you have this code in your page: ><div id="banner"> <h1><a href="http://www.eatitandloveit.com/" accesskey="1"><img alt="eatitandloveit.gif" src="http://www.eatitandloveit.com/archives/images/eatitandloveit.gif" width="800" height="70" / border =" 0"></a></h1> <h2></h2> </div> Because the <h2> element is inside the 'banner' div, this style from your stylesheet is being applied to it: >#banner h2 { font-size: x-small; display: inline; padding-left: 10px; border-left: 5px solid #fff; } What you're seeing in Firefox is a 5px wide white border on the left of where the <h2> element is displayed (even though there is no text). To make the border 'disappear', you can style the border color so it is the same as the background color: >border-left: 5px solid #006; You could also just remove the border-left style. Hope this helps...

Many perl modules can be installed locally by uploading a copy to your account where a script can find it, but XML::Parser isn't one of them. XML::Parser requires compilation on the server, which in turn requires shell + root access. The Help Desk has to install XML::Parser for you, if it's not already installed on the server. In trying to fix another error, Julius copied a .pm file from an MT plugin and named it 'Parser.pm', and saved it to the plugin's lib/XML directory. When Julius tried to import an RSS feed with the reBlog plugin, perl started looking for XML::Parser, found the copied file, and thought it had the real XML::Parser module. Removing the copied file allowed perl to find the real XML::Parser module on the server, and the error was resolved. BTW, welcome to the forums!

My condolences to you and your family, Andy.

Welcome to the forums, neilsbrother!

Welcome to the forums, orcotuna!

Welcome to the forums, afh! You might check the Error Log in your CPanel and see if any error message is recorded there.

You'll want to add the '&lang=cn' to the URL as I have it above, so the AWStats page will display in Chinese as you wanted. Other than that, no, I don't think you need any other setting.

It's not an issue with URLs stored in your browser's history. How are you entering (going to) the AWStats page in your browser? I did a little investigating, and noticed that if you enter CPanel, click on "Web/FTP Stats", then click on "Awstats", the page will always be displayed in English. This is because the "Awstats" linked page contains a redirect to the actual AWStats page: ><META HTTP-EQUIV="Refresh" CONTENT="0;URL=/awstats.pl?config=my-TCH-domain.com&lang=en"> It appears that the '&lang=en' is hard-coded in the redirect URL, and this will override any language setting in the AWStats .conf file. Unfortunately, I don't see any way to change the language the CPanel is setting in the redirect URL to the AWStats page. It looks to me like your best option here is to bookmark the link you said displayed the AWStats page for you in Chinese: >http://my-TCH-domain.com:2082/awstats.pl?config=my-TCH-domain.com&lang=cn ...and use the bookmark to view your AWStats page rather than going through CPanel. Once you've done this, you probably should set the permissions on the awstats.zucaiblog.com.conf back to 0644. You won't be using the 'Lang' setting in the .conf file, and resetting the permissions to 0644 will allow it to be updated if any changes or updates are published.

Did you remove the '&lang=en' or '&lang=cn' from the URL you're using to access AWStats? If it is left in the URL, it overrides the 'Lang' option in the .conf file. I tested this on my own server - if the URL does not contain the "&lang=" option, AWStats displays in the language specified by the 'Lang' option in the .conf file. The translation is not 100% though - there's some phrases on the page that are not translated / localized into the chosen language. The only other thing I did different is I browsed to the AWStats URL with my domain name instead of the server's IP address: >http://my-TCH-domain.com:2082/awstats.pl?config=my-TCH-domain.com

In your awstats.zucaiblog.com.conf file, I believe you can set the language by finding the following option: ># Set your primary language. # Possible value: # Bosnian=ba, Chinese (Taiwan)=tw, Chinese (Traditional)=cn, Czech=cz, # Danish=dk, Dutch=nl, English=en, French=fr, German=de, Greek=gr, # Hungarian=hu, Indonesian=id, Italian=it, Japanese=jp, Korean=kr, # Latvian=lv, Norwegian (Nynorsk)=nn, Norwegian (Bokmal)=nb, Polish=pl, # Portuguese=pt, Portuguese (Brazilian)=br, Romanian=ro, Russian=ru, # Spanish=es, Swedish=se, Turkish=tr, Ukrainian=ua # Default: en # Lang="en" After setting Lang="cn", you'd need to set the permissions on awstats.zucaiblog.com.conf to 0444 so it will not be overwritten with a default .conf file. I'm not sure if this will fix your issue with the 'Search Keyphrase' and 'Search Keywords' sections though, particularly if the searches listed were done in another language.

I don't see what's bizarre about it. Virtual hosting accounts are hosted on separate servers from reseller accounts. The virtual hosting plans are designed and priced with the intent that only one domain will be used on each account. This allows TCH to ensure that its servers are not overloaded hosting thousands of domains each and running server performance into the ground.

Welcome to the forums, AEROFRESH! If you don't have them already, you'll need to get the login information for the account's CPanel and FTP server. Once you have those, you'll be able to make any changes you want to the site. The 'under construction' page is located at public_html/index.htm on the server. To change what is displayed, you would need to upload a new index.htm file to the account's public_html directory on the server to replace it. Links to video, audio, and image files can be added to the index.htm page so they'll be displayed there, or you can add them to some other HTML page on the site and then just provide a link to that other page. Take things one step at a time, and if you have any questions or run into any problems, you can always ask for help here in the forums.

Welcome to the forums, Nylisk!

Welcome to the forums, StormRuller! I don't use CuteFTP nor do I have any experience with Tripod web sites - sorry!

When I used to sell shoes (over 20 years ago), anything over size 12 was rare.

Welcome to the forums, ronenb75! There's a number of ways to get the username who logs into a password protected directory. One of the following should work for you: >$username = $_SERVER['REMOTE_USER']; >$username = $_SERVER['PHP_AUTH_USER'];

Liz - I'm really sorry to hear about your illness. Take it easy, get plenty of rest, and I hope you get well soon!

Welcome to the forums, Mitan!

Essentially, you're programming in a different environment that what exists on the TCH servers: * There are no TCH servers I'm aware of that are running PHP 5 (my server is currently running PHP 4.3.11). You may encounter things that work in PHP 5 (functions and their syntax) but are not backward compatible to PHP 4. * There are no TCH servers I'm aware of that are running MySQL 4.1 either (my server is currently running MySQL 4.0.25). There are known compatibility issues between MySQL 4.0.x and MySQL 4.1. You're also writing PHP code that makes use of functions that are not available on TCH servers. One example: > $handle = new mysqli('localhost', 'loca', 'loca', 'loca'); mysqli is part of the "Improved MySQL Extension" group of PHP functions: Support for the mysqli extension must be compiled into PHP, and to my knowledge, TCH servers do not have PHP compiled with this option. (Since TCH servers aren't running MySQL 4.1 servers, this extension would not be of much use to anyone.) In order for your code to work on TCH servers, it needs to be written to run in a PHP 4 / MySQL 4.0.x server environment and only call functions that are available in that environment. Your db_connect() function could be rewritten like this to run on a TCH server: >function db_connect() { $handle = mysql_connect('localhost', 'cpanelName_username', 'password'); if (!$handle) { die ('Could not connect to MySQL server: ' . mysql_error()); } return $handle; } And your news.php script would look like this, using my suggestions above: ><?php include_once('conf/main.conf.php'); $story = null; $page = null; $handle = db_connect(); $db_selected = mysql_select_db('cpanelName_foo', $handle); if (!$db_selected) { die ('Could not select database foo: ' . mysql_error()); } $query = "select * from stories"; $result = mysql_query($query, $handle); if (!$result) { die('Query error: ' . mysql_error()); } while ($story = mysql_fetch_assoc($result)) { echo '<table border="0" width="400">'; echo '<tr><td>'; // headline echo "<h2>{$story['headline']}</h2>"; echo '</td></tr>'; // byline echo '<tr><td>'; echo substr($story['story_text'],0,60).'.....';; echo '</td></tr>'; echo "<tr> <td> <p align='right' class='morelink'> <a href='content/story.php?pg={$story['id']}'> Read more ... </a> </p> </td> <td width='100'>"; echo '</td></tr>'; } echo '<tr><td colspan="4"><br><br>'; echo '<a href="index.php" class="morelink">Home</a>'; echo '</td></tr>'; echo '</table>'; Hope this helps...

Welcome to the forums, Manfred! Running PHP scripts under your user ID requires configuring the web server to use phpsuexec to run them. From what I understand, phpsuexec is not used on TCH servers as some features of PHP don't work with phpsuexec enabled, and it can also result in breaking a number of PHP scripts. Yes, this does weaken security in your account. In this case, 'anyone' would be any other user with an account on the same server as you (other TCH customers on your server). I don't believe there is any significant risk from the other customers on your server. The main threat is from hackers exploting a vulnerable script in another user's account, then being able to access your files and directories that have 0666/0777 permissions. Your main defenses here are 1) only set 0777 directory / 0666 file permissions on directories and files that require it, and 2) make and keep regular backups of your account, so if your files are tampered with, they can be easily restored. If it's just a permissions problem, you could use a PHP script to set/change permissions on files and directories that are owned by 'nobody' (since you aren't able to set them via an FTP program or CPanel's File Manager).