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.