Mass Mailing: 2061 Connections - November/December 2005

The November/December 2005 issue of 2061 Connections went out on 29 Dec 2005 at 1:11:59 PM to 3808 recipients.

Scripting: Mass Mailer Updates

I've made a few relatively minor updates to the mass mailing script.

• I noticed that the sender address entered on the form was not reflected in the actual e-mail sent out. Turns out I forgot to add a parameter/replacement for this value in the e-mail templates. This oversight has been corrected.
• Added a check for sender and subject so that default information could be added if necessary.
• Updated the EOL fix in the fnc_qpEncode() function so that it is a bit more streamlined.
• Updated the BOL period replacement to place the encoded period on a line by itself. This was necessary to avoid line length overflow.
  
• Updated the recipient replacement code to run in two stages. The first stage replaces the recipient information in the body of the message an encodes it using quoted printable. This helps avoid line length overflow on long e-mail addresses. (This code is in addition to code from fnc_qpEncode() that places any placeholder variables on a line by themselves.) The second stage replaces any other occurrences of the recipient address placeholder, which should be just in the message header.
  

Mass Mailing: Workshops

The Atlas workshop schedule was sent out on Dec. 20, 2005, at 4:02 PM to 2444 e-mail alert subscribers and 50 one-time notification addresses.

Graphic Design: Assessment Items

Spent the better part of the last week working on images for the assessment project. Luckily most of the illustrations I had to made were copies of ones that were already on hand, a few with minor modifications. One didn't exist and I had to create it from scratch, which was a significant chore even though I was able to work mostly from pictures I found online.

I certainly don't mind devling into graphic design, page layout, or whatever else needs to be done. Unfortunately the time frames are usually fairly short and with my lack of experience in these areas I'm often left feeling like I'm struggling.

No doubt changes to the current illustrations as well as additional ones will be needed in the future, at which point I'll know if the work I've done is acceptable or not.

Scripting: new 404 page

I've rewritten the 404 page to make the script more efficient as well as friendlier to users.

One reason for the update is that I wanted to remove the possibility of multiple redirects, especially if the end result was a 404 anyway. I modified the script so that each time it makes a change to the URL it uses a combination of the file system object's FileExists() method and the Server.MapPath() method to check and see if a file actually exists. If a match is found then the redirection is made, otherwise it keeps on checking. If no redirection can be made the browser is never redirected and the user receives the error page.

I also removed the automated javascript redirect. Any automated redirects (such as matches from the 404Redirect.txt file) are done via 3xx status messages. Non-automated redirects are now done via a link on the error page. Most of the 3xx redirects are pages that we've moved or shortcut URLs we've made public and so it's preferable to just have the redirection be as transparent as possible. Also, 301 redirects are benefitial to search engine rankings for the majors because the new page will inherit the old page's rank.

One drawback to doing 3xx redirects is that page anchors aren't carried over (depending on the browser). Page anchors were one reason why I had initially used JavaScript redirects ... Science NetLinks was using them to link to portions of Benchmarks Online. SNL doesn't appear to provide many links to our content anymore, so I'll just wait and see if we get any complaints. I can still use JavaScript to tackle the page anchor issue on link redirects.

On top of the change to redirection methods I've also made some other modifications to the code that I hope make it more efficient. One of the bigger changes is that I'm using regular expressions to parse the URL which seems to provide more accuracy in getting the various parts. I also had to add a default document check for instances when the user enters just a directory. I think the script could be made more efficient, but it's looking significantly better.

Oh, and I've fully documented the script as well.

JBJ is helping me with the text of the page. We're just about done with editing, etc. Hopefully I'll be able to post the update on Monday.

On a related note, I really find working with JBJ on our web pages really helps with developing concise and understandable text, an important consideration for web-based content. Sometimes the process is a bit frustration, but I think the combination of his writing skills and my tech knowledge leads to some pretty good "help" material.

I've also linked a contact form that e-mails me when someone wants help finding content. Fully documented as well.

Notes:

• I used a regex tester while developing the regex for this code ... it helped a lot
• Some minor changes were made between Win2k and Win2003 with regard to the way using a custom 404 script works. One apparent result is that, based on the URL in the browser's address bar, Win2K would appear to redirect asp pages to the 404 page while Win2003 does not.

Update 2005-12-29:
I've finally had a chance to review the content of the 404 page with JBJ and it's been updated. When I uploaded the page and did some testing I ran across a couple of errors that had to be fixed.

• Using On Error Resume Next at the top of the page can cause serious problems with If...Then statements.

If...Then statments break if a syntax or runtime error is encountered. The "next" line in the code is executed, that which is inside the If...Then code block, essentially a interpretation of the conditional as True. The only method I know of to get past this problem is to embed another If...Then statement testing for a value in the Err object.

I'm disabling the global On Error Resume Next statement. There are few statements that would outright kill the script on the global level. The main source of error messages so far has been the file check, which I've moved to a function that has error handling. If any further code presents problems I'll do the same.

I'll need to keep an eye on any 404s and do some testing. Since this is the 404 page the user should either see the "Page Unreachable" message or be redirected to the correct page. The user getting a script error is not a viable option for this page.

For more information, see Fabulous Adventures in Coding: Error Handling in VBScript, Part One

• If a redirection from the 404Redirect.txt file contained a querystring component it would kill the script.

I worked around this by checking for a querystring in the txtURI variable when testing a redirect match. If one is found it is pulled out and added to the txtQueryString variable.

• Fixed a problem with the default document check
  

The file test of the default document check was using the wrong value and thus would fail if a directory name was used without the trailing slash.

Also, I made default document check result in a 3xx redirect. More likely than not this is the desired action.

Scripting: ActiveMenu script update

There was a problem with the ActiveMenu script when an image in the story detail was not square. Up until now the height of the image was used to calculate the height required by the story. Unfortunately this would cause the calculation to be either too much or too little when the image was not square. To more acurately calculate the "area" used by the image, and thus the height used by the story, I modified the script to use a line bisecting the image diagonally as the basis for the calculation (currently 45% of that line's length). This is easily done using the classic hypotenuse calculation.

The code library has been updated with the new script.

Scripting: Win2003 IIS and SSI

Ever since upgrading to the new web server the page survey has not been functional. Upon further inspection it appears that a script accessed via SSI #exec in Win2003 has a number of problems when compared to Win2K:

• no access to the originating page's query string
• SCRIPT_NAME returns asp page rather than originating page

The former problem causes a page to not know that the survey has been submitted.

The latter problem causes a page to never display the survey in the first place (surveypage.asp is on the list of pages that are to not have the survey shown).

So far I have been unable to find much useful information regarding SSI in Win2003. SSI doesn't seem to get much attention these days beyond the basic how-to. I've posted a question to one of the Microsoft newsgroups, hopefully I'll get a useful answer.

See my post for more info: SSI #exec and querystring passthrough

Update 2005-11-28:
Of the two options I noted in my post linked above I've decided that the quickest method of addressing this problem is to associate the HTML files with the ASP processor. I'll test on the development server for the next week then implement on the live server.

Update 2005-12-05:
A response to my newsgroup posting confirms that there was a change in the way #exec operates. I've seen no major problems using the ASP processor on the development server so I've gone ahead and implemented it on the production server.