The first time I went online was on one of my uncle’s old computers. It was running either Windows (3.1 or 95) and still used DOS for many of its applications. The thing was ancient, and I was scant 10 years old. I didn’t fully understand the implications of communicating or publishing content online, and by no means did I understand the technology that made it all work.

Fast-forward 4 years: every weirdo with an AOL account and too much time had a Geocities account – including me. I learned html 3 and 4, and eventually unlearned the marquee and blink elements. I tinkered with PERL, and javascript, and when CSS announced, I immediately started changing font colors, sizes, and other superficial properties.

More frequently than I cared to, I upgraded to the most recent browser – just to get crucial features that now seem completely arbitrary. The worst part was that the overlap between browser features was so limited; Netscape and Internet Explorer rarely rendered things the same way and had drastically different sets of element support.

Nearly 15 years later and proprietary elements are a thing of the past – but each browser development team implements element support at what seems to be their whim and fancy. After almost a decade and a half, it may not be the wild west that it once was – but cross-browser compatibility issues still render markup development nothing less than a rodeo. Luckily, good cowboys (and gals) can use some friendly frameworks to lasso up the troublemakers *cough*Internet Exploder*cough*.

Now git along, little doggie.

What can we do about it? Design for browsers whose development teams employ agile development cycles to push the limits of current markup capabilities. Thanks Firefox & Chrome.

The front page has a Views Slideshow Block that grabs node data from custom CCK types. These types contain an image to be displayed in the slideshow (but not the node itself) and a checkbox for enabling or disabling the node from appearing in the Slideshow Block. The slideshow images by default link to the nodes from which they were created.

The problem is linking to a page rendered by Views. Since I can’t add a field for the image or checkbox in a view page (not that I know of, let me know if I’m wrong on this) I had to figure out a different way. And I did, but not without further glitches.

I added the image and checkbox fields to my Page content type and created a node with the appropriate image. It appeared in the slideshow and linked to the page. I then tried several methods to redirect the alias to the correct page. First, the Path Redirect Module. Fail. Then, cpanel’s .htaccess redirect configuration tool. Fail. Then manual .htaccess configuration. Fail.

I don’t really know why the .htaccess failed – I have suspicions it has to do simply with Apache not updating, the fact that I have the Global Redirect Module installed, the clean url directives that already exist in the .htaccess file, or some similar url rewriting conflict.

In a pinch, I added this snippet of code to the body of the page I created:

<?php
 header("HTTP/1.1 301 Moved Permanently");
 header("Location: http://www.mysite.com/aliasname");
 exit();
 ?>

This delicious morsel did the trick, but not without a headache first. You’ll have to have access to posting PHP code, and post it as source, even if you select the PHP option.

• I keep all my professional work, including client files, on a separate hard drive partition so that I can easily and regularly back them up, let’s call it g:\
• Client files for web projects are organized as such: g:\clients\client-name\project-name , so that if a long-term client wants a site redesign, I can easily keep these separate rather than dumping them into a single public_html directory for each client
• My local testing server is pointed at a different partition, let’s call it h:\
• I want to be able to serve individual projects via the testing server, but only work on the project files

Naturally, I thought of unix aliases but I’m currently running Windows 7 so I tried shortcuts. Didn’t work. After a little digging, I found the solution: symlinks (which work in numerous OSes – thanks for the correction). From the command line, type:

mklink /D H:\target\directory\linkname G:\clients\client-name\project-name

mklink /D creates a symlink, or a soft link that is the Windows equivalent to unix aliases. The first argument is the directory where you want the link to be placed, and the second is the source directory. Easy as pie.

Be careful when deleting/writing content – the linked directory allows you to manipulate the original file!

I started setting up my attributes and naturally, added one by accident. After finding a button deceivingly named “delete”, I clicked it to correct my error. An http request was sent and the page reloaded – but my attribute was still there, winking at me like an old man who – while sitting on his porch – witnessed your ice cream tumbling off its cone after the first lick.

Luckily, a quick search found a remedy so I pass it along to you, the ethereal inter-web user:

http://forums.phplist.com/viewtopic.php?f=17&t=24502#p67476

Take that, old man.

From choosing the right host to archaic css support, here are some tips to help you remedy the malaise of maligned markup and hosting services:

1. Start with a plan. You need to know five things:
   1. how many people you plan on reaching
   2. how frequently you will be emailing them
   3. what features you would like (html vs plaintext, images, etc.)
   4. the duration of your campaign
   5. your budget
2. Find email list software that does everything you need it to do and is easy to use. Generally, they have demo sites where you can test out their features. Some even integrate with popular CMSes, like Drupal, WordPress, and Joomla. Try several of them out until you find something that you like and that is either offered by your host, or that can easily be installed. Choosing software with good documentation and a large, nerdy user base is typically a good bet.
3. If you are planning on sending a lot of emails, find a host that allows it. Hosts typically set a throttling rate to govern the number of emails that can be sent per hour and per day. Defaults on these figures are usually low, but can often be raised after contacting customer support. Do some research beforehand and you’ll be okay.
4. Make sure the email list software you are using – as well as your host – aren’t blacklisted by major mail servers like gmail, yahoo, etc. Similarly, make sure your host’s filtering/spam settings are either disabled or allow for large quantities of outgoing mail with your keywords.
5. Keep the design simple. Most mail clients and online email service providers allow for minimal use of css and html. They vary drastically in their support (you can find more info here: http://www.email-standards.org/ ), but here are some quick pointers:
   1. Use tables for optimum control over content alignment. Some email clients don’t render floating elements properly and certainly don’t degrade elegantly. You can avoid tabular layouts altogether if you keep your design simple with a single column of text.
   2. Avoid the default line length; in other words, your text shouldn’t  run as wide as the window. There are two reasons for this:
      1. It is harder to read
      2. It won’t grab the reader’s attention to begin with – it looks like most junk they get in their inboxes. Even if they do start reading it, make it easier by limiting the width of a text block to 35-55 characters, either by setting a css width on your containing element, or by using deprecated methods like setting the width attribute in a table.
   3. Use inline css on each element that you want to configure
   4. Counter-intuitively, don’t depend on the “cascade” in body css – in other words, if you want all of your text to be styled with font-family: verdana, you might need to place that on each element
   5. Related to the previous point, avoid using css in the body element; some mail engines strip all html that is outside of body, including body.
   6. Avoid images as CSS backgrounds – instead, use image elements and get creative; a well designed image can create a fake page-corners, fades, and other common html graphics techniques. (a great example is the Organizing for America Campaign)
6. Design for your audience. If you don’t know who that is, do some research. There’s nothing wrong with designing as broadly as possible – but with clear guides. If you know people who have difficulty reading small text will be receiving your email, ensure the text is large enough and with sufficient contrast. Don’t make it gaudily large, around 12-16px in many common webfonts generally does the trick. Images can’t be read by screen readers without alt attributes, so always include them. Title attributes are helpful as well, for mouseovers.
7. Make sure the email has a clear goal and that it is easy to achieve; use image and text links to guide the reader to an actionable task. Generally, these links should point to a landing page on your site from which you can collect referral information.
8. Make sure your content is engaging. From the images to the copy, everything should be designed to appeal to the reader’s senses and sensibilities. Knowing your audience is crucial for this step, so do some research if you haven’t already.
9. Test, test, test. If you don’t have accounts on the major email services, sign up for them. I would advise keeping track of these usernames/passwords in a safe place (http://keepass.info), for future testing purposes. Avoid filling out personal information other than what is required by law. While I don’t condone creating false aliases, I also don’t condone data-mining, as commonly practiced by google/gmail. Tread carefully and wisely. Also, download and/or purchase major email clients (thunderbird, outlook, eudora, etc.), configure them with the appropriate server settings, and test there too.
10. Finally: know the law. The European Union and a few states require opt-in/out clauses and privacy policies to be provided at the time of sign-up and linked in every transmission. Unless you’re living in China, North Korea, or other places where access to information is limited (among other things), the internet is boundless – you can’t plan on never getting a hit from the EU, California, Minnesota, Nevada, or other places where laws exist to protect privacy over the web. While it’s unlikely that problems will arise, they can be avoided altogether by including these things. The best way to protect yourself is to know the law and plan for future problems. I’m by no means a lawyer, but I have taken a course in internet/information law. If you’re uncertain, you should probably set up a consultation meeting with a bar-certified professional specializing in this area. A great online resource is http://www.epic.org You can sign-up for their feeds to stay on top of current electronic privacy legislation, cases, and so on.

There are certainly more techniques and considerations, but these should help get you started if you’re uncertain or new to managing and designing email lists. While I strongly condone pushing browser standards forward, the state of email rendering is even less homogeneous – and emails translate into business and money. While it’s great to support and use standards, the burden of implementing standards compliant emails shouldn’t be on the client. Designers & developers need better support from corporations. Full stop, end of transmission.

Don’t forget to enable anonymous user permissions. This goes for most uploaded content, including attachments.

use the same code to generate your menu:

<?php if (!empty($primary_links)): ?>
<?php print theme('links', $primary_links, array('id' => 'nav')); ?>
<?php endif; ?>

this calls the links() function inside of includes/theme.inc, which triggers the l() function in the includes/common.inc to write the primary links menu. We can’t override the l() entirely because other code uses it, so we’ll copy the code from theme.inc and override the l() function with a site template specific one. Here’s my code:

theme.inc

function mytheme_links($links, $attributes = array('class' => 'links')) {
 global $language;
 $output = '';
 $options = array(
 'class' => '',
 'html' => FALSE,
 );

 if (count($links) > 0) {
 $output = '<ul' . drupal_attributes($attributes) .'>';

 $num_links = count($links);
 $i = 1;

 foreach ($links as $key => $link) {
 $class = $key;

 $links['attributes']['title'] = $link['title'];
 // Add first, last and active classes to the list of links to help out themers.
 if ($i == 1) {
 $class .= ' first';
 }
 if ($i == $num_links) {
 $class .= ' signup last';
 $links['attributes']['class'] .= $class;
 }
 if (isset($link['href']) && ($link['href'] == $_GET['q'] || ($link['href'] == '<front>' && drupal_is_front_page()))
 && (empty($link['language']) || $link['language']->language == $language->language)) {
 $class .= ' active';
 }
 $output .= '<li' . drupal_attributes(array('class' => $class)) .'>';

 if (isset($link['href'])) {
 // Pass in $link as $options, they share the same keys.

//here's my call to the overridden function
 $output .= mytheme_l($link['title'], $link['href'], $links);
 }
 else if (!empty($link['title'])) {
 // Some links are actually not links, but we wrap these in <span> for adding title and class attributes
 if (empty($link['html'])) {
 $link['title'] = check_plain($link['title']);
 }
 $span_attributes = '';
 if (isset($link['attributes'])) {
 $span_attributes = drupal_attributes($link['attributes']);
 }
 $output .= '<span'. $span_attributes .'>'. $link['title'] .'</span>';
 }

 $i++;
 $output .= "</li>\n";
 }

 $output .= '</ul>';
 }

 return $output;
}

and now the l() function in common.inc gets changed to mytheme_l():

function mytheme_l($text, $path, $options = array()) {
 global $language;

 // Merge in defaults.
 $options += array(
 'attributes' => array(),
 'html' => FALSE,
 );

 // Append active class.
 if (($path == $_GET['q'] || ($path == '<front>' && drupal_is_front_page())) &&
 (empty($options['language']) || $options['language']->language == $language->language)) {
 if (isset($options['attributes']['class'])) {
 $options['attributes']['class'] .= ' active';
 }
 else {
 $options['attributes']['class'] = 'active';
 }
 }

 // Remove all HTML and PHP tags from a tooltip. For best performance, we act only
 // if a quick strpos() pre-check gave a suspicion (because strip_tags() is expensive).
 if (isset($options['attributes']['title']) && strpos($options['attributes']['title'], '<') !== FALSE) {
 $options['attributes']['title'] = strip_tags($options['attributes']['title']);
 }
 // Inject a span inside the anchor tag for the purposes of this theme - NOTE - May have to remove check_plain() around
 // the $text variable
 return '<a href="'. check_url(url($path, $options)) .'"'. drupal_attributes($options['attributes']) .'><span>'. ($options['html'] ? $text : check_plain($text)) .'</span></a>';
}

You can see that all I did was include the span element inside the anchor tag using simple php string concatenation. Until I can find a better solution, this does the trick. Don’t ask me about benchmarking, though…