TweezerMan

Welcome to the forums, timm! There's three steps to setting up a MySQL database: 1) Add (create) database 2) Add (create) user 3) Add user to database (grant user privileges to access database) Once you've completed these 3 steps, you should be able to access your database in phpMyAdmin. You may want to look at the TCH movie tutorial on setting up MySQL accounts, illustrating how to perform the above three steps. Hope this helps...

The default port that MySQL servers use is 3306, and the default socket on Linux systems is '/tmp/mysql.sock'. Unless you have reason to believe the MySQL server under XAMPP is not using the default port and socket, I'd suggest trying those settings and see if the script works.

Welcome to the forums, whitelot!

I don't use WordPress, but I agree with TCH-Thomas: It looks to me like the directory permissions on the 'backup' directory need to be set to 777.

The current design of MT3 allows for the running of MT code to begin from more than one directory. The standard MT scripts (such as mt.cgi, mt-comments.cgi, and mt-tb.cgi) start running their code from the main MT installation directory. Plugins may have their own *.cgi scripts located in the MT/plugins/<PluginName> directory where they are installed. MT initializes all plugins when any MT cgi script or plugin cgi script is run, which includes the setting of library paths requested by plugins. The reason why using relative directory paths to identify a plugin's lib directory doesn't work is because the "current working directory" could be 1) the main MT directory, 2) the plugin's main installation directory where its own cgi script is installed and currently running, or 3) another plugin's main installation directory, where *it's* cgi script is installed and currently running. There is no relative path that a plugin can specify that will result in the same, correct directory path in all 3 cases. Take an example from your own plugin, MT-Protect. The current code you have evaluates to the following statement: >use lib plugins/Protect/lib; If a main MT script is running, MT will look for MT-Protect's lib directory here... ><MT_dir>/plugins/Protect/lib; ...which is correct. If MT-Protect's cgi script is running, MT will look for MT-Protect's lib directory here... ><MT_dir>/plugins/Protect/plugins/Protect/lib ...which is not correct, and you got around that issue by adding the following to MT-Protect's cgi script: >use lib 'lib'; If another plugin's cgi script is running, let's say MT-Blacklist for example, MT will look for MT-Protect's lib directory here: ><MT_dir>/plugins/Blacklist/plugins/Protect/lib In this case, the user will see a plugin error whenever they run MT-Blacklist (or any other plugin's cgi script). The only sure way to specify a consistent library path, no matter what cgi script is running, is to use an absolute one. This is not a problem with MT, unless you consider MT3's plugin architecture to be a problem (which I do not). To get an absolute path to a plugin's lib directory, a plugin must be able to at least determine the absolute path to the main MT directory. Once you have that, completing the path to the plugin's lib directory is easy. A plugin could do a bunch of backflips in its own code to try to find the MT directory and determine the absolute path to it, but this isn't necessary. Before plugins are initialized, an MT object is initialized and the absolute path to MT is stored in this object (MT->{mt_dir}) All you need to do is access the MT object and get the absolute path to the main MT directory from it. Assuming MT versions >= 3.1, your plugin code could specify an absolute library path with just the following two lines of code: >require File::Spec; use lib File::Spec->catdir(MT->instance->{mt_dir}, 'plugins', 'Protect', 'lib'); MT versions prior to 3.1 don't support the instance() method, so you'd have to come up with an alternate method if you intend for your code to run on older versions of MT. The above code is not thoroughly tested, although I did test it on my install of MT-Blacklist, and it appears to be working fine. Seems like a workable solution to me.

There are other possible causes of a "Writing to '*.html.new' failed" error - for example, a problem with an Archive File Template in Weblog Config | Archive Files, a problem with the "Output File Name" on an Index template, or incorrect settings for DirUmask, HTMLUmask, or HTMLPerms in mt.cfg. I'd be willing to bet that if you said what you were doing when you receive the error, and what the error message was, the true cause of the problem could be determined and you wouldn't need to use "NoTempFiles 1" in mt.cfg to get around the error.

This is what the MT Manual says about the NoTempFiles setting in mt.cg: Usually, when you receive an error about writing to *.html.new failed, it is because 1) the Local Site Path or Local Archive Path is not set correctly in mt.cfg, 2) the Local Site Path / Local Archive Path directories do not exist (you have to create those directories if they do not exist because MT will not create them), or 3) the permissions on the Local Site Path / Local Archive Path directories are not set correctly. The creation of temp files while writing weblog pages is a good thing - if MT crashes or aborts in the middle of updating a weblog page, your original weblog page will not be deleted or modified. Setting "NoTempFiles 1" in mt.cfg prevents this feature from being used. I have never encountered an MT installation where setting "NoTempFiles 1" in mt.cfg was necessary - it doesn't solve any problem that a user is likely to have. It usually does not eliminate the "Writing '*.html.new' failed" error - the error merely changes to "Writing '*.html' failed" instead, as the original problem (one of the three causes I mentioned above) still exists. You can use whatever settings you like in mt.cfg, but I wouldn't recommend using "NoTempFiles 1" to anyone.

Welcome to the forums, grimreaper169!

Your Local Site Path doesn't look right, unless you really want to have your weblog in a directory named "index". I think you probably should be using the following for your Local Site Path: >/home/cpanelName/public_html

But did you try what I suggested, exactly as I wrote it? What happens if you make the change, and can we look at the page after you've made the change? I took a closer look at the mod_rewrite rule you're trying to use: The rule you have actually does the reverse of what you say it does - it will take a URL like this: >http://www.thecheapgifts.com/store/agora.cgi/00036 ...and rewrite it to this: >http://www.thecheapgifts.com/store/agora.cgi?p_id=00036 I don't know which way you intend for URLs to be rewritten.

Welcome to the forums, smartdog!

Welcome to the forums, Tim! How come? I'm not reselling, I just want more than one domain and an easy space to maintain. <{POST_SNAPBACK}> The virtual hosting plans are designed and priced with the intent that only one domain will be used on each account. The reseller hosting plans are designed and priced for the ability to use multiple domains on each account:

Welcome to the forums, Vimal! Your navigation menu, as well as all of your other javascripts, do not work when you rewrite the URL in this form: >http://www.thecheapgifts.com/store/agora.cgi/00036 ...because of the way you link to them in your HTML code, and what both the browser and server do with those links. Your navigation menu javascript is linked using the following code: ><script type="text/javascript" language="javascript1.2" src="menu.js"></script> The "menu.js" is a relative link - in this case, relative to the URL of the page being displayed. With the above script appearing on a page at the above URL, the browser tries to fetch the script from this location: >http://www.thecheapgifts.com/store/agora.cgi/menu.js The "agora.cgi" part of the above URL is not a directory - it's your store CGI script. The server interprets the page request as a request for store/agora.cgi, thinking that "menu.js" is a parameter to the script instead of a file name. The server returns another copy of store/agora.cgi, and the browser tries to run the HTML code of your web page as a javascript (and fails). It is doing this for all 4 javascripts you are loading on the page. When the URL to your web site is not run through mod_rewrite, the javascripts work because with a page URL like this: >http://www.thecheapgifts.com/store/agora.cgi?p_id=00036 ...a script tag linking to "menu.js" will try to retrieve the following file: >http://www.thecheapgifts.com/store/menu.js This file exists, so the server retrieves it, and the browser runs the javascript without any problems. To fix this problem, you need to code the links to your javascripts so the server looks for them specifically in the /store directory, instead of in the directory the browser thinks the currently displayed page is in. You'd need to change the code for your navigation menu from this: ><script type="text/javascript" language="javascript1.2" src="menu.js"></script> ...to this: ><script type="text/javascript" language="javascript1.2" src="/store/menu.js"></script> This change will force the browser to get your javascript from the /store directory on the server, where it actually is. You need to make this same change to the other 3 script tags in your page. I suspect a similar issue may be preventing you from editing your web site in FrontPage - that there's a relative URL or file/directory name in FrontPage's configuration somewhere that getting tripped up in the same way as your javascripts are. Side note: Your web site has some serious structural problems - multiple <html>, <head>, and <body> tags and there should be only one set of each. Hope this helps...

I can't explain what you're seeing, but here's a few things to consider: 1) Your code is supposed to be testing "concatenating multiple small strings", but the string you are concatenating over and over is about 6K in size - not exactly what I would consider to be a small string. As the string size approaches the size of memory that the buffer allocates (10K?), I would expect less of an advantage in using the output buffer. Rather than test 1000 concatenations of a 6K string, I'd probably be testing with a 600 byte string, or even a 60 byte string. 2) I was under the impression that you'd only want to use the output buffer in the context of actually outputting something to the browser. If you aren't wanting to output the resulting string to the browser, I'd probably wouldn't use output buffering - I'd just concatenate text into a variable like you do in your first test. I think the overhead of using the output buffer may be too much if you're not going to actually output the buffer contents to the browser. 3) I don't think you're testing quite the same thing in each test: In your first test, the sample text is merely concatenated into a variable, then the variable is unset (discarding the text) at the end of the test. In your second test, the sample text is being concatenated into the buffer, but then ob_get_contents() copies the buffer into the $test variable, ob_end_clean() purges the buffer, and finally the $test variable is unset. At the point where the buffer is copied to the $test variable using ob_get_contents(), the text in the buffer is about 6MB in size. I think that would take a measurable amount of time to copy then purge from the output buffer. Basically, you may be comparing apple and oranges and thus not conducting a fair test. I don't know how much this will help, but there's my two cents!

Welcome to the forums, greywolff!

I don't know that there any definition of what constitutes "normal" traffic other than what is normal for your site. One thing I did notice: Hits 544085 (66.24 hits/visit) 66 hits per visit seems like a lot to me (the web server is, on average, serving 66 files for each page that is requested from the server). Do you have a lot of individual graphics files on your web pages?

My first guess would be that the visitors who are hitting these pages directly are coming from a search engine. If I really wanted to find out if someone had directly linked a page or image, I'd download the web server logs, search for the URL in question, and check out the remote IP addresses, referers, and user-agents - see if there's anything in common or anything that stands out.

The way I understand it, you can design the look of your pages as a sample page in your HTML editor, but you would then split the sample page into two parts - a custom header and footer template. AgoraCart will display pages with the header and footer templates you designed, and the content generated by AgoraCart will be displayed between the header and footer templates. So to answer your question, yes, AgoraCart is going generate (make) the pages of your web site (at least the ones that will be part of your "store").

Again, it depends on where you live (and thus what the law is). In California, that statement is not true.

These are the only options I know of: 1) If the traffic is recent, you may be able to see the full referer URL on the "Latest Visitors" page (under "Web/FTP Stats" in CPanel). 2) The web server's access log will also contain the full referer URL ("Raw Access Logs" in CPanel).

I'm not really familiar with AgoraCart, but it looks to me like you need to set up pages from your site to be in AgoraCart instead of the other way around. It doesn't appear that you can just add snippets of code to regular HTML pages and have them work with Agora Cart. You may want to look at the AgoraCart Overview and the AgoraCart Online Manual for more information.

Welcome to the forums, cherry! I'm sure that's there some form you'd need to fill out. It could be as a simple as filing a DBA ("doing business as") just to register a name for your company, but there could be others, depending on what kind of company you want to set up and where you live. Many jurisdictions freely provide information to new small business owners to educate them on the law, forms, taxes, etc., so it might be worthwhile to check with your local government offices (or their web sites) and see what they have.

You replace the '0' with '1'. The '444' refers to the file permissions on the .conf file - you set those with your FTP program or CPanel's File Manager. As to how the settings changed, the server default probably changed. You normally would not edit the .conf file unless you wanted to make AWStats do something different from what the server's default is.

You were not too much trouble - that's why we're here. But it did take a while to research the code on 7 different plugins (4 of which I don't use and didn't have a copy of), then document the changes to 5 of them. No, it is not an error in the MT 3.16 code. As I said: ...the problem is with the code in each of the plugins I had you fix. If it was a problem with the MT 3.16 code, I would have shown you how to fix that instead. Glad to hear they're all fixed and that there's no stragglers.

Your issue is due to AWStats not performing reverse DNS lookups. You can configure AWStats to perform them by going into the tmp/awstats folder on your account and editing the awstats.your-TCH-domain.conf file. Look for the following section: ># If you want to have information on domains/countries visitors, you must ask # AWStats to make reverse DNS lookup (if not already done in your log file). # If you set DNSLookup to 1, don't forget that reverse DNS lookup decrease # seriously AWStats time processing. # If you keep DNSLookup to 0, all hosts will be reported by the IP addresses # and not by the full hostname of visitors. Domain/Country chart will also # report all visitors from a domain/country "Unknown". # Possible values: 0 or 1 # Default: 0 # DNSLookup=0 Replace the 0 with a 1 (one) and save the file. The next time stats are run, reverse DNS lookups will be performed. You should also change the permissions on the .conf file to 444, so it will not be overwritten with a default config file when the stats are run.