TweezerMan

While some people may do it for that reason, I have my domain registration information private so that my home address and phone number are not available to the public.

I believe the key to answering your question is whether your web site would constitute a "nexus" or establish a "presence" where the server is located that would be subject to U.S. federal or state taxes. Beyond having to pay sales taxes or any other tax imposed on the hosting service itself, my instinct is that the answer is "I don't think so" - a web site alone is not enough to establish a nexus or presence for taxation purposes. But as I'm not a tax attorney or accountant, and definitely don't know the state tax laws in every state, this is a question that is best answered by a competent professional.

Welcome to the forums! I've looked at the docs that Bruce refers to - it appears to me that the Entropy Banner is behaving exactly like it is supposed to (random image is loaded each time page is loaded in browser). If you want the banner to change after the page is loaded, I think you'd need a javascript to do that for you.

Me too, Bruce!

As annie and TCH-Raul have said, trackbacks are a standard that has been adopted by most blogging platforms. Sending trackback pings is not that difficult. I've never heard of anyone incorporating a script into a "homegrown" weblog in order to send them though. Back in the "good old days" when I was using Radio UserLand for my weblog, they had not yet incorporated trackback functionality into Radio, so you had to use a stand-alone trackback pinging tool and send your trackbacks manually. Two of them that I knew about are the Wizbang Standalone Trackback Pinger and Adam Kalsey's SimpleTracks pinger. Where I think you'd run into difficulty is finding a script that would automatically receive trackback pings for you. This is because what needs to be done with the data that is received is different for every weblog platform. Since yours is homegrown, I doubt you could find any script that would receive pings for you and store the data properly in your weblog without some massive customization. Most blogging tools will update their RSS feeds automatically when an new entry is published. Movable Type (the blogging tool I currently use) has special RSS templates included that automatically update the RSS feeds when new entries are posted. If your homegrown weblog cannot output and update an RSS feed automatically when you write a new entry, I suspect you'd need something like an HTML scraper script in order to produce it. They work (I've subscribed to a few such RSS feeds in the past), but they're not always pretty. For the amount of work that it appears you'd be looking into putting into your weblog to gain trackback functionality and RSS feeds, I wonder if perhaps you should consider migrating your weblog to one of many available blogging tools that already has these things (and more) built into it.

Congratulations, Robert, and good luck to you in your new position!

It could be that, or that the help desk is waiting for something. Not too long ago, I was having a problem and the server in question was undergoing an upgrade. My ticket was put "On Hold" for a few hours until the upgrade was complete, so the Help Desk would know that they needed to come back later and look at my ticket to see if the problem was resolved.

Do you have mod_rewrite rules like these in your .htaccess file prior to the rule that you've been working on, so mod_rewrite does not process the URLs for your stylesheets? ># Don't rewrite requests for files in MediaWiki subdirectories, # MediaWiki PHP files, HTTP error documents, favicon.ico, or robots.txt RewriteCond %{REQUEST_URI} !^/wiki/(stylesheets|images|skins)/ RewriteCond %{REQUEST_URI} !^/wiki/(redirect|texvc|index).php RewriteCond %{REQUEST_URI} !^/error/(40(1|3|4)|500).html RewriteCond %{REQUEST_URI} !^/favicon.ico RewriteCond %{REQUEST_URI} !^/robots.txt (The above was taken from the MediaWiki Rewrite Rules page linked to in the first post.)

Yes you can - the two commands need to be separated by a semi-colon (";"). If your script is in the same directory that you want to cd to, you need to use something like the following as the "Command to run" for your cron job: >cd /home/cpanel_username/path/to/change/to; ./scriptname

The Alias directive can only be used in server-level configuration files (httpd.conf, srm.conf, and access.conf), which users do not have access to. It is not allowed in an .htaccess file - this is an Apache restriction, not TCH.

If it's working, then you're fine. No, that exactly what you should do. The files you're editing are plain text files and should be uploaded in ASCII mode.

That's why I said, "PHP files are generally text scripts." The Ultimate Form Mailer is one of those exceptions. (I know this because I have it installed on my own web site.) If I remember correctly, at least some of the files distributed with UFM are "compiled PHP" - these would be the equivalent of a Windows .exe file and do need to be uploaded in BINARY mode (as the UFM installation instructions indicate); otherwise, the compiled file is corrupted and will give errors when you try to run it. Bottom line: UFM is a special case that requires special handling.

Uploading a file in ASCII tells the FTP server to convert the line endings from the format the operating system on your PC uses to the format that the operating system on the server uses. Window systems use a two character LF / CR (line feed + carraige return) line ending. Mac systems use a one character CR line ending character. Linux systems use a one character LF line ending character. If I upload a text file from my Windows PC to my TCH account (which is a Linux server), all of the LF / CR character combinations in my Windows text file will be automatically converted to LF characters when the file is saved on the TCH server, so the server will be able to read the lines in it correctly. (The reverse happens if I download a text file in ASCII mode from the TCH server to my Windows PC.) This can be crucial for some types of text files, because if they have the wrong type of line ending, the server won't be able to read them properly. A multi-line script may be seen as one long line, because the server doesn't see proper line ending on each line. Uploading a file in BINARY tells the FTP server to NOT convert any characters at all, to just store the file as it was uploaded. You want this for files such as .zip or .tar.gz compressed archives (altering bytes within them will corrupt them), and graphic file formats (altering bytes within them will change your image and possibly render it unviewable). Since PHP files are generally text scripts, they should be uploaded and downloaded in ASCII mode so the line ending characters are converted to the correct format. If you upload a PHP script in BINARY mode, the worst that would happen is that you would get a 500 server error because the server mis-reads the file.

Thanks for allowing me to join such a great team! I look forward to working with the TCH crew and helping out TCH members with whatever I can. David

Thanks for the link, Bill! Wiping the system and doing a clean install was plan B, because the computer in question belonged to a family member that we liked, so I was willing to go the extra mile and put the work in to clean her system up. I had the time, so I didn't mind. I spent 2 full days working on the system - 1 to clean the junk out, and 1 to update Windows XP (I had a heck of a time getting SP2 to install), make sure the XP firewall was on and working, install antivirus software and do some general maintenance and clean up on the system. It is definitely much better and easier to keep a system clean than to let one get that bad then try to recover it.

That appears to be an error related to MT's dynamic publishing. You might want to take a look at the documentation on what you need to do in order to properly set up and configure MT for dynamic publishing, particularly step 2: You have to create the /home/demesne/public_html/templates_c directory yourself.

Note: Question was cross posted to MT Forums. As Mark Paschal noted on the MT Forums, the way MT generates the URLs for category archive pages changed when you upgraded to MT 3.15. The hard-coded links in your sidebar no longer point at the current location where MT is building your archive pages. Your hard-coded link for the Motorcycles category points here (where the comments links do not work): >http://www.deadpan.net/pie/archives/cat_motorcycles.html ...but MT is actually building the Motorcycles category archive page here (where the comments links do work): >http://www.deadpan.net/pie/archives/motorcycles/index.html The first question you need to answer is: What URL do you want the category archive pages to show up at? Depending on how you answer, you will need to either fix the links in your sidebar, or change the Archive File Template for your Category Archives in Weblog Config | Archive Files.

The URLs to pages where the comments both do and do not work would be helpful.

Yes, it is possible. By default, the MySQL server will not accept connections from another machine, but you can grant permission for your home PC to connect to the MySQL server. In your CPanel, go to "MySQL Databases". Near the bottom of the page is a section titled "Access Hosts". Enter your home PC's IP address then click the "Add Host" button. (If you're not sure what your home IP address is, go to whatismyip.com in your browser.) You did not indicate whether you've installed the MySQL Connector/ODBC (MyODBC) driver - it is required for what you want to do. If you have not installed it, you can download the MyODBC 3.51 driver from their Downloads page. (Scroll down to "Windows downloads" - I'd recommend downloading and installing the MSI installer.) Once you've installed the MyODBC driver, then you need to set up a connection for the driver. In your Windows Control Panel, go into "Administrative Tools", then "Data Sources (ODBC)". Click on the "System DSN" tab. On this tab, click the "Add" button. Scroll through the list of drivers displayed, select "MySQL ODBC 3.51 Driver", then click the "Finish" button. You should now see the "Connector/ODBC - Add Data Source Name" window. On the "Login" tab are all of the fields you need to connect to the MySQL server. Data Source Name - This is the name that Excel will display as a data source. Description - Text description of database connection. Server - Enter just your domain name (for example, ****). User - MySQL database username. Password - MySQl database password. After you have entered the above fields, you can click on the "Test" button to see if the information you've entered is correct and you can make a connection to the MySQL server. In the "Database" dropdown box, select the MySQL database you wish to use. (You will not be able to select a database unless you have entered the correct connection info in the above fields.) The MySQL driver uses a default port of 3306, so you should not need to enter a port number. If you did need to though, an alternate port number can be specified on the "Connect Options" tab. Click the "OK" button to finish setting up the connection - this will return you to the ODBC Data Source Administrator window. The connection you just created should now be visible in the "System DSN" tab. Click the "OK" button to exit ODBC Data Source Administrator. Now you can send a query to the MySQL server and have the results returned in Excel. Within Excel, on the menu, click "Data", "Get External Data", "New Database Query..." (this is on Excel 2000 - hopefully it will be the same or similar on your version of Excel). In the "Chose Data Source" window, you should see the MySQL connection you just set up listed on the "Databases" tab. Click on that data source then click "OK". At this point, you will tell MS Query what tables, fields, etc. you want in your query. Once you've specified everything, the query will be run and the data will be returned to your Excel worksheet. Hopefully the above instructions will get you pointed in the right direction.

You're getting the error because you did not successfully upgrade (overwrite) [mt.cgi dir]/lib/MT/Template/Context.pm when you upgraded - MT is still trying to use the 3.01D version of that file. You need to re-upload the MT 3.15 version of that file.

To correct the error, you need to go into Weblog Config -> Preferences and set the option "Language for Date Display:" by selecting a language then clicking "Save Changes" at the bottom of the page. This is a known bug that occurs with new installations of MT - the language is not set correctly by default.

You just need to delete the MT-Blacklist v1.65 files, which should just be the following: mt-blacklist.cgi plugins/Blacklist.pl extlib/jayallen/Blacklist.pm extlib/jayallen/MTBlPing.pm extlib/jayallen/MTBlPost.pm

1) You're not supposed to be able to view the contents of the scgi-bin directory (a security feature). MT ships with an index.html file (page) that goes into the base installation directory to protect against viewing the directory contents in case it is viewable in a browser. The message you see: ...is from that index.html page. As far as that goes, it is installed in the right place and functioning as it should. 2) I don't know if this is the problem, but the file name is mt-check.cgi (not mtcheck.cgi). Trying to browse to mtcheck.cgi in your scgi-bin directory should produce a 404 error page (Page Not Found), because that page really does not exist. You should try to browse to the following URL in your browser instead: http://******/scgi-bin/mt-check.cgi

You will not corrupt your MT installation, but the version of MT-Blacklist you are currently using (probably v1.65) is not compatible with MT3. When upgrading to MT v3.15, you will also need to 1) remove the existing MT-Blacklist v1.65 plugin files from your installation, 2) install MT-Blacklist v2.04b, which is available from Jay Allen's MT-Blacklist page.

Thanks for the welcome, Don and Bruce! It's not an easy decision to push files on users' installations, but I think TCH made the right decison too. By making the fix into a plugin that worked on both MT 2.x and 3.x installations, Six Apart made it very easy for TCH to fix all MT installations in one shot instead of waiting for each user to find out about the vulnerability and waiting for them to eventually fix it themselves (if they ever did).