1. Log in to your account at Moniker.com.
2. Go to the My Domains page (i.e. your domain manager)
3. Select the check box for the domain you want to set up for Google Apps
4. On the domain management menu, click IP (third tab from the left in current layout)
5. Click on Template Manager
6. Click on Create New Template and name it something like Google Apps
7. Delete all selections for that template by clicking the check box next to each entry and saving the template. This gives a blank slate to work with.
8. Under Add Template Records -> Select Record Type choose to add a CNAME record.
9. Your hostname will be the verification code Google gave you (something like googleffffffffab123456) and your address will be that code appended to the Google domain (so in this example googleffffffffab770727.google.com). Note that there is no http or anything like that.
10. Go to the Google help page on creating a CNAME record and scroll down to the Check the status of your CNAME record and enter the address with no http prefix (again googleffffffffab770727.google.com in this example). It should verify in a couple of hops if it’s working right.
11. Go back to your Google Apps admin panel and verify your domain.

There is a level a geekiness beyond which few will tread. This likely crosses that frontier. I’m prompted to write this as a result of a discussion on WebmasterWorld about which URLs should and should not have a trailing slash. One person threw out the idea that URLs for files should not have slashes and URLs for directories should. While that seems sensible, when talking about the architecture of a website, that terminology makes no sense anymore in the context of dynamic websites. In that case, we would be better off to speak of vertices or nodes and edges or, if the site is strongly hierarchical, we could think in terms of branch nodes and leaf nodes. In the latter case, we might (or might not) consider branch nodes to be “directories” or “folders” and leaf nodes to be “files”, even though the URLs no longer bear any relation to some underlying structure on a hard disk.

So all of this got me thinking about the characteristics of a modern URL and what it means for thinking about site structure and the implications that has for building listing pages that are good for the user first and foremost and good for search engine optimization as a consequence. Of course, in my usual elliptical way, it will take me 2,000 words to cycle back around to that point.

Before I go into all that, to stave off pedantic comments about URLs versus URIs, a URL is simply “a type of URI that identifies a resource via a representation of its primary access mechanism (e.g., its network ‘location’), rather than by some other attributes it may have” according to the W3C report on the subject (see also Dan Meissler’s summary). Translation: what you see in your browser address bar is always a URL and all URLs are URIs (actually Chrome breaks this by omitting the protocol identifier, but close enough). A URL was once considered a specific subset of URIs, but can now be considered a colloquial but useful (as per the W3C report) rather than a technical term.

URLs Are Abstract

In the old days, it was usual for URLs to reveal something about server architecture, and you still see this on some sites (especially ASP sites on Windows servers). Examples are URLs like:

1. http://example.com/page.html
2. http://example.com/page.php
3. http://example.com/category/
4. http://example.com/index.php?p=123

In the first two examples, the file extension suggests that the URL is pointing at a file, and that #1 is a simple HTML file that will be fed directly to the client (i.e. browser) as it exists on the server, while #2 is a PHP file, which needs to be evaluated by the PHP processor on the server, which will then feed the actual data to the client. In #3, especially since it is on the same domain as the others, we assume because of the trailing slash that it points to a directory, that is a collection of files on the server hard disk. In the final example, the URL suggests that it points to a file and that file is getting a parameter passed to it and the variable “p” will have the value “123″.

Now of course, this could all be wrong. We’re making an assumption that the URL indicates something about the server. However, early on Tim Berners-Lee proposed the Axiom of Opacity of URIs which states simply:

The only thing you can use an identifier for is to refer to an object. When you are not dereferencing, you should not look at the contents of the URI string to gain other information.

source: Tim Berners-Lee, Universal [sic] Resource Identifiers — Axioms of Web Architecture, 1996.

Dereferencing is just a tech geek way of saying retrieving the resource which is a tech geek way of saying displaying the page or image.

So in other words, the URL should only tell you and only does tell you how to locate the thing you’re looking for. It should not and ultimately does not expose the underlying system that is finding that thing. This axiom was usually ignored in the early days of the web because it was so easy to make a URL point to a file or a directory on the hard drive of the server. So out of laziness, URLs betrayed a lot about the server architecture, but this was a consequence of laziness, not an inherent and certainly not a desirable characteristic of a URL.

In my own case, like all beginners at the time, I started with simple URLs that mapped directly to specific files using the actual file names, including file extensions. One of the reason I started building my own content management system (CMS), though, was that the lack of abstraction bothered me. I hadn’t read any of this stuff by Tim Berners-Lee, but I just felt that storage location and addressing should not be so tightly tied to each other.

As a former programmer, I believed in having an abstraction layer between the user interface and the underlying technology. However, at the time I built my first pages, I was writing my dissertation in history. As a scholar, having URLs point to the host, directory, subdirectory and file location was like having call numbers point to the building, floor, shelf and shelf position of a book, rather than some abstract naming scheme like the Library of Congress classification. We do not expect the call number of a book to reveal anything about the architecture of the storage facility and I could see no reason why the URL of the “resource” would betray anything about the architecture of the server. Rather, the LC call number is based on the information architecture of the LC system without reference to the physical architecture of the building holding the books. It seemed only natural to me that my site URLs should be based on the information architecture of the site, without reference to the server setup.

This observation set me on the path of creating my own content management systems where the page content was split among as many database tables as necessary and the URL was simply an entry in yet another table. The URL table had a column with the URL and that was keyed to some number or whatever that told the program how to put together the page. At this point, the URL was a pure abstraction.

Eventually, I began looking for an open-source alternative to my custom CMS, which as a spare-time project of one guy had substantial limitations. One of the things that initially attracted me to Drupal was that it offered complete URL abstraction, using a lookup table as I was doing in my custom CMS. Now, ten years later, Drupal remains my CMS of choice, even though WordPress and many others now have similarly convenient URL abstraction (yes, this blog is on WordPress — I like it for blogging or very simple brochure sites; I like Drupal for almost everything else).

In 1997, to get good URL abstraction, I needed to build a system that had URL abstraction as a basic component and for that I had to know a programming language and be able to interface with a database. Most people were still hand-coding HTML at the time. Only a small number of people, either through reading or just thinking about it, knew about the Axiom of URI Opacity or, as I conceived it, URL Abstraction. Those that did, often did not have the technical means to achieve it. So we came to think of URLs as being somehow related to server technology. And we came to think of branch and leaf nodes in terms of directories and files, and we differentiated directories from files by the presence of absence of trailing slashes and file extensions.

Flash forward to 2012. Beginners are now more likely to install WordPress than to learn to hand code HTML. And WordPress and most other CMS now have very convenient URL Abstraction built in. So I now see abstract URLs, that is URLs that are simply a lookup column in a database, as the norm. The old-school URLs that tell you something about the machine architecture are a dying breed. And good riddance. by implication, the idea that a URL should differentiate a directory or listing from a file or page becomes problematic, as we’ll see.

URLs As API

If URLs are abstract and are just a lookup column in a table, what does that mean? Among other things, it means that they no longer are a server hardware interface, they are a sort of Application Programming Interface. They are a means not simply of looking up a resource, but of interacting with the underlying program through an abstracted interface. I say the interface is abstract because I don’t know what a given URL does once captured by the program (because URI Opacity is a fundamental principle), only that it does stuff. But as a Drupal developer, I can grab any part of the URL and create very different results, routing data through one template or another based on the second or third or fourth term of the URL.

In effect, when I build a site in a system like Drupal with abstract URLs, I can make any part of the URL fire any sort of action, in effect exposing an API to users and designers. Yes, the URL still tells the server how to “dereference a resource” but the underlying program can treat any and all parts of the URL as a parameter and in arbitrary ways (i.e. any part can have any meaning/implication). This is a natural consequence of opacity and abstraction.

URLs are Content

This may stretch the definition of content a bit, but think about what an abstract URL becomes. It is a column in a lookup table, which means that from an information storage point of view, it is identical to the meta title, the H1 tag content, the nagivation menu items and the body of the page, the latter of which may be assembled from many different tables.

We will commonly use the URL as the key to figure out which item to look up in the other tables, but I may decide to list all pages of a certain taxonomic category, in which case the category is the lookup criteria and the URL is simply data.

Is it content? I would say that ideally it is in the sense that it contains actual information that tells the user, search engines and site editors what the page is about. If it is stored like any other data and it conveys information about the page like any other data, is it not page-specific content? If you’re paying attention, it might appear that passing information about the page through the URL violates the axiom of URI opacity. However, URI opacity refers to how the user agent is to treat the URI, not whether or not it can convey information to a reader about the meaning and content of the resource that is referenced. In the case of a web page served via HTTP to a browser, it means that the browser is not to make assumptions about how to handle the page based on any component of the URL (file extension, presence/absence of a query string). It is, rather, the job of the HTTP headers to pass this information and the browser to do what it’s told. So URI opacity means opaque to the user agent, not necessarily to the user!

Directories Are Abstract

Since URLs are abstract, opaque and serve as API and content, what then is the distinction between “directory” and “file”. In the discussion that prompted this, someone said that directories are lists of pages. I can see that definition working on a classic server setup where when you have a URL that points to a directory and you allow the user to have the “index view”. In that case you get a list of files in that directory. In that case, we typically want (and depending on server setup may even need) a trailing slash to indicate what we’re looking at. But such a view is a gross violation of the principle of abstaction. It’s fine for a file server, but not for a website.

If we switch to a dynamic site built on Drupal (and to a much lesser extent WordPress), we quickly lose all sense of listing pages as directories. To take a very simple example, my Yosemite flower identifier page is what would be a classic “listing” page. And yet, what do we find there?

• Rich Structured Data. What’s here is being pulled from several different database tables to put together a list, yes, but not really a mere list of pages and certainly not a list of files. It has a photo, the common name (which is the only part linked to the page for that specific flower), the Latin name (genus and species) and the Family name. This is not merely a listing or link to the page, but a subset of data on the page. This particular page does not have any introductory content, but it could easily prepend a 30,000 word discourse on the native plants of Yosemite to the listing. In which case, is it primarily a list or primarly a page? And what possible meaning do those terms then have? In any case, the terms “directory” and “file” have no meaning at all here.
• Arbitrary Data Collections: Infinite Directories for a Given Set of Pages. The structured data presented here is arbitrary. I could list these same pages and have the strucutred data show as paragraphs rather than columns, I could have columns with color and number of petals rather than taxonomy. I can have a virtually infinite number of presentations for this same listing of pages. Because we have abstracted URLs, collections of pages are arbitrary, abstract themselves and blur the line between listing and page. The distinction between branch nodes and leaf nodes still makes sense, but both become “pages” (though in Drupal parlance only leaf nodes are “nodes”).
• The URL is an API. The user has access to various select boxes to create a custom listing page. This is simply offering the user a convenient means to hack the URL, which is to say, the API for this list. Again, thinking in terms of a URL that points to a directory loses all meaning.

Who Cares?

So who cares whether or not URLs are abstract and whether or not a trailing slash is added to a URL? More to the point, what does this have to do with anything practical? I would say there are substantial implications here for the design of pages, specifically branch node pages. The most important of them is this: if the distinction between directories and files is meaningless, between listings and pages has become inobvious, and if we see all page-specific parts of the page as “content”, this suggest something to us about site architecture.

The main thing it suggests is that we need to look for the “value add” that a listing has. If it is a mere listing, does it help the user or merely add one click layer to her quest to find relevant information? The value add might be a nice introduction and guide to the category, with most popular and best pages highlighted. In the case of my flower finder page, the value add over a straight list is that people can filter by characteristics they know in order to get a small set of photos from which they can, perhaps, visually identify the flower.

All of this has me thinking in terms of paying more attention to the content of my branch nodes, as it were. It has me thinking that laziness and sloth lead me to create simple listing pages, but these have little value to the user and they also make it harder for the search engines to differentiate one collection of pages from another. So ideally, every branch node becomes a significant content page, a guide to both user and search engine and, I would say, to site editor to sharpen her sense of the information architecture of the site. As you can see, sadly, the organizational principle of Raised By Turtles is basically to put things in the blender and then pour… but that’s work for another day.

First things first. Reboot of your computer after install (not just a standby/hibernate). Though rare, it can happen that the http server can’t access port 80 and therefore can’t start (port 80 is the default for webservers). If you don’t know what that means, that’s fine. Just read on.

So now you’ve rebooted and it’s still not working, so we want to find out whether it’s on the WordPress end or the server end.

• Can you access a text file through your browser using http (i.e. not opening the file directly, but through the server)? Let’s say you have a readme.txt on your local server. If you go to http://localhost/readme.txt (assuming that exists), will that come up? If that works, than your http server is fine and the issue is with WordPress.
• If you get a Page Not Found error (also known as a 404), that means the server is running, but it doesn’t have a file named readme.txt in the root directory. If you think it does, you’ll need to figure out which directory WAMP sees as your server root. To figure this out, find out where WAMP is on your computer. Typically, unlike most applicationsm, WAMP installs to C:\wamp, but it could be in your Program Files directory depending on how you installed it. There you want to find your httpd.conf file which is going to be in a location similar to C:\wamp\bin\apache\Apache2.2.11\conf. In the httpd/conf file, look for places where DocumentRoot is set. It will have one global setting and may have additional settings depending on how things are set up (if you have additional virtual hosts set up). The first one should be where localhost runs. So verify that DocumentRoot points to where your files are actually stored. Now try to load the readme.txt file
  again.
• If that works we can now make sure that PHP is up and running right. Create a file that has just this one line in it:
  <?php phpinfo(); ?>
  Now save that to something like info.php in your server root and just go to http://localhost/info.php. That should bring up a long page of output about your PHP setup. If you are just getting a blank white page when you go somewhere you expect to open a PHP file, that means WAMP is running, but you have either errors or no content in your application. That’s a whole different debugging process.

Assuming you can’t bring up a simple text file.

So you’ve done all that, and things just don’t happen when you try to open http://localhost. I’ve had this happen fairly often because I’ve had Windows (especially Vista) turn on Microsoft’s IIS server after automatic updates. When this happens, IIS grabs port 80, it’s not available for Apache and your web server can’t start. So you run automatic updates and suddenly Apache and WAMP and all that go away. So we need to get rid of IIS and open up port 80.

• Via the Control Panel
  • Open up Programs and Features
  • Select Turn Windows Features on or off
  • Navigate to IIS (Internet Information Services) and just turn all that junk off. Deselect it all.
  • Restart
• Via the Services Manager
  • in the Start menu, type Services. This should bring up the Services icon. Click it to open
  • Scroll down to Windows Web Publishing Service and right click and choose properties
  • Change the startup behavior from Automatic to Disabled.
  • reboot

If you’ve rebooted and you still can’t get Apache started, check that something else isn’t blocking port 80. So from the Windows command prompt (go to Run and type cmd) type:

> netstat -aon

then check for a line that has port 80 appended to an IP address, for example:

TCP 255.255.165.21:80 0.0.0.0:0 LISTENING 832

This tells us that Process 832 is using port 80. Go the task Manager to check the PID of 832 and terminate it if it’s not WAMP. Now try to start WAMP. If it does, you have figured out the problem, but you will want to figure out why that process is starting up and whether you can either stop it from launching when you boot or get it to use another port. I’ve found that Skype is common offender and it has a setting in the Skype options to make sure it does not use port 80.

As with any complex application, there is room for all sorts of other things to go wrong, but in practice I’ve found that in most simple cases, this will get you up and running.

You can pull this data from Ubercart simply enough but it requires a few subqueries to get all the data you need. This is because both the sales data and shipping are in the same table, namely uc_order_line_items. So you need to pull each line item from the table as a separate subquery.

There’s one other gotcha. Ubercart carries tax through to four decimal places in the database, so you need to round that to the nearest penny, as Ubercart does on checkout. This gives you a spreadsheet with all the values you need, minus the actual amount paid for shipping, which you’ll have to pull from Quickbooks or whereever.

It’s possible, also, that you’ll have to adjust for your server time if your server is in another time zone. In other words, you may need to adjust the timestamp to take that into account. And of course, Ubercart stores your order dates and times as Unix timestamps, so we have to take that into account when we do whatever conversions we need. Fortunately MySQL handles Unix timestamps with no problem.

When all is said and done, we end up with the following query:

SELECT FROM_UNIXTIME(o.created,"%Y-%m-%d") AS 'Date', o.order_id AS 'Order ID',
    tax.sales_tax AS `Sales Tax`, shipping.shipping AS 'Shipping Charged',
    o.order_total AS 'Order Total', o.billing_postal_code AS 'Zip Code', o.billing_city AS 'City', z.zone_name AS 'State'
FROM
    (SELECT ROUND(amount,2) AS sales_tax, order_id FROM uc_order_line_items WHERE TYPE LIKE 'tax') AS tax,
    (SELECT amount AS shipping, order_id FROM uc_order_line_items WHERE TYPE LIKE 'shipping') AS shipping,
    uc_orders AS o,
    uc_zones AS z
WHERE o.order_status LIKE 'completed'
    AND tax.order_id LIKE o.order_id AND shipping.order_id LIKE o.order_id
    AND o.created > UNIX_TIMESTAMP('2010-12-31 23:59:59') AND o.created < UNIX_TIMESTAMP('2012-01-01 00:00:00')
    AND z.zone_id LIKE o.billing_zone
    AND o.billing_zone LIKE '12'
ORDER BY o.billing_postal_code;

Notice that we are ordering by billing postal code. This is because in many ways, this is our most relevant piece of information. Many of the client’s customers order while on the road, so the billing address is the one that counts for tax purposes (the same as for a gift purchase or whatever). The postal code typically determines the tax rate, so it allows us to effectively sort by location. Once exported into an Excel spreadsheet, though, we can of course sort and hash however we want.

Here’s a sample of the final output in SQLYog (a Windows MySQL client):

Sample Output from SQLYog

Enjoy!

Since my first explorations, a handful of modules have made great progress and you can achieve full-featured mega menus with the excellent Megamenu module. There are also some other now-mature projects like Nice Menus, and the Superfish module, which includes mega menu support. Upon further reflection, though, I became increasingly troubled by various usability drawbacks and SEO concerns. My notes on the topic got rather long, so I’ve divided them into a series that sums up some thoughts on the usability advantages and disadvantages of mega menus and then looks at the SEO concerns with mega menus. You can see an example here from the new YosemitePark.com site (click to view full size):

Lots of Options!

You might be able to see some potential problem areas there, but let’s take a look at the good, bad and ugly of mega menus in the next post. Read on about Mega Menus and usability ——»

Usability Advantages of Mega Menus

• All options visible. A traditional dropdown menu hides almost all options from the user until she hovers over the parent category. If the user does not think with the same hierarchy as the designer, she will have to play Treasure Hunt, hovering over many parent items to find an item. This can lead to frustration too if the dropdown keeps disappearing when the user is not asbolutely precise with the cursor. In theory, mega menus can solve that problem.
• Organizing options. Mega menus allow friendly and visual grouping of options into logical groups. A traditional dropdown becomes completely dizzying when the number of options gets too large.
• Images and Icons. Often, mega menus are designed to have images or icons that correspond to, and quickly confirm for the visitor, the content of the menu. So the Contact category might be illustrated with an address book or telephone icon or some such thing.

Usability Concerns

So mega menus are a no-brainer right? What could go wrong? As it turns out, plenty. Jakob Nielsen has highlighted a few mega menu usability issues. Usability expert Jared Spool noted early on that mega menus could get you into trouble in his article on 6 Epic Forces Battling Your Mega Menus. Usability aside, Spool explains the sudden popularity of mega menus thus:

Mega menus seem like such a good idea. After all, they make the marketing team happy, as they remove all that nasty navigation away from the prime real estate of the home page, leaving room for the team’s messaging goodness. At the same time, the mega menu gives the design team a rich sandbox to play in, with much flexibility on how they display the site’s main links.

He lays out his six arguments against mega menus, most of which are in fact not unique to mega menus at all and I don’t find them inherently problematic (not that germane here; scroll to the bottom of the article for some thoughts on Spool’s six problems). He notes that Amazon, a rigorous conversion optimizer, tried mega menus for a year and dropped them. Spool concludes:

If your design would benefit in some desperate manner from this navigation cliché, go ahead and use it. However, you probably want to watch it real close. Make sure you’re watching your users and your key performance indicators (especially revenue, if you’re an e-commerce concern).

I wouldn’t go so far as that, but the it’s easy to see some of the issues that might arise with mega menus.

1. Forest of Options Obscures the Trees. I know, that metaphor usually runs the other way around, but with mega menu, you often see a pretty forest, but have trouble finding the tree you want. You can see in my screenshot from the introduction, there is a temptation to make the mega menu into a sitemap (cick image to enlarge).
   

   Lots of Options!

   Since you can throw in every imaginable option, you do. As a result, the user is presented with a dizzying array of options and, one might guess, becomes paralyzed by the number of options. It creates an easy out for designers and site architects who don’t want to make choices. Now, I don’t want to get into the old saw about only presenting users with seven choices in menus. It is not true now and never was, but at a certain point, the number of options becomes visually distracting and difficult to read, and it seems to me quite common to see mega menus cross that line simply because they can.

2. Screen Size problems. This is not unique to mega menus. This can be a problem with options dropdowns (i.e. select boxes) that have long options or standard dropdown menus if they get big enough. The problem is that the mega menu is, well, mega, so this is a lot more common. You can see from this screenshot that mega menus can become completely non-functional if the window is narrow, as on a mobile device, or short, as on a netbook (click images to see full-sized):
   

   Oops! A not-so-mega menu

   

   Oops! Short window problems

   You can see that the mega menu is cut off on a narrow or a short screen. Anything that sticks out past the browser window is missing. With most types of content, this isn’t a big deal. Sure, the user has to scroll right to see it, which is annoying, but it can be done. With a mega menu, however, the user cannot scroll! Why? Because it only stays displayed when the mouse is hovering over the menu. Move the cursor down to the scroll bar, and the mega menu disappears. Scroll, and the link goes off screen. You literally cannot use the mega menu on a narrow screen.

   The Yosemite Park site solves this by allowing you to click on the root term and be taken to an index page, where the sub-options are displayed by default. That’s a pretty good solution, but it means the user needs to know, or guess, that the root term is a link and is clickable. It would be interesting to track visitors and see how they ultimately use this navigation.

This was part of what ultimately took the blush off mega menus for me personally. I just found that you compound implementation problems and if you’re not careful and don’t test on a lot of platforms, you have a high chance of letting a significant usability problem creep in. In addition, I was also concerned with the SEO impacts of mega menus (next section) ——».

Addendum: Spool’s issues with mega menus

If you’re really interested in Jared Spool’s Six Epic Problems, here’s a quick rundown, but it’s really more the SEO issues that you should read about next. Anyway, I’m not all that concerned with most of these issues, but here are some supplementary thoughts on Spool’s Six Epic Problems.

1. Menus are not Buttons. Since a menu isn’t a button, users don’t know they have to do something to make it expand. Realistically, they may simply not know it expands and will go there to click, only to see more options revealed. It’s better than not expanding.
2. Missing Trigger Words. In other words, since most options are hidden, users can’t see that they exist. But short of the navigation taking up the whole page as a sitemap, you’re not going to change this, and a mega menu at least gets you half way, though as you’ll see in the next part on the SEO problems with mega menus, that halfway solution is often a result of a bad information architecture decision.
3. Category Names not always inherently sensible. Well, of course not. This is a problem with any navigation and, again, is an information architecture problem more than a user interface problem.
4. Users Wait Before Moving Their Mouse. In other words, if they can’t see what they want, users sit there paralyzed and won’t click anything at all. Again, mega menus aren’t the root problem. If the design only allows, say, seven navigation links, then that’s what there is and they may not always have enough information scent to get the user to click, whether on hover those menu items reveal nothing (i.e. it’s a single-level menu hierarchy), reveals a cascade of hierarchical dropdowns (classic model) or is a mega menu. Realistically, the mega menu at least removes a one or more decision points vis-à-vis the classic hierarchical dropdown, where the user will have the “pause” problem at every level, instead of just at the root level.
5. Mega menus hide the information that’s under them. That’s a problem when the user accidently hovers over the menu while trying to read the content, which suddenly get’s hidden. That can be annoying, but in a minimally usable design, the mega menu should disappear simply on mousing out and most users today will know this. I find this a much less problematic usability issue than the one I noted where in a small screen, parts of the mega menu are not visible, clickable or usable at all.
6. Problems with hoverless devices. As we move to devices that don’t have cursors and mouses, they can have trouble triggering the menu expansion. Of course, this again is not unique to mega menus, but concerns anything that uses hover behavior as a trigger. This has become so ubiquitous that I think this is largely solved by most devices these days, though I am an iPad virgin, so I can’t say for sure.

Read on about the SEO impacts of mega menus (next section) ——».

Mega Menus and Search Engine Optimization Problems

Ultimately, it wasn’t the usability questions that brought me up short with respect to mega menus. It was the SEO concerns. Mega menus end up putting lots of links at the top of the page, sometimes hundreds. Google itself says in its Webmaster Guidelines that webmasters should “Keep the links on a given page to a reasonable number.” Google’s official Search Engine Optimization Starter Guide (PDF) recommends that webmasters should avoid “creating complex webs of navigation links, e.g. linking every page on your site to every other page” (p. 12). When the mega menu gets truly large, it effectively ends up doing just that or very nearly.

Few voices in the Search Engine Optimization community are more respected, experienced, and authoritative than Ted Ulle. Back in 2008, Ted had a number of clients with -950 penalties and one of the common characteristics that jumped out was a tendency to have site navigation with tons of links. In internet years, 2008 is a while ago, but Ted continued to see this problem in 2010 and 2011, as we’ll see. Also, in 2010, Jane Copland of SEOMoz said that in her opinion “massive drop-downs certainly aren’t adhering to SEO best practices.”

So why would a large collection of links in the page templage create problems? There are a number of possible reasons. Unlike some of the usability issues, none of these are unique to menus formatted as classic mega menus. Instead, they are a simple function of the number of links, but I do believe that once the mega menu tool is available to the design team, the number of links tends to explode. So it is more an enabler than a cause per se.

1. Confused Relevancy Signals. It helps the search engines determine what a page is about if you keep it laser-focussed on the topic at hand. Normal navigation adds a handful of keywords that can confuse the signal a bit, but it compensates by helping focus the search engine’s understanding of overall site content and spotlight the most important pages. Mega menus, on the other hand, can add hundreds of keywords that confuse the signal. In information theory, the keywords in the mega menu are “noise” and it make it harder for the search engines to figure out the “signal” (page topic) and therefore figure out relevancy of the page to a given search.

   Google is getting better at ignoring navigation and boilerplate content. Some people contend that, therefore, this is not a problem. But Ted Ulle stated in January 2011 that he still believed that a large number of links in the page template is problematic for relevancy. In brief, you are challenging the search engine by adding this much noise to the signal and you have to ask whether or not you really want to depend on the strength of the Google or Bing algorithm to sort out your “semantic chaos” as Ted calls it.

2. Link Equity Dilution. This is similar to the semantic confusion caused by the forest of anchor text in your navigation. Each page has a certain strength and each link passes some of that page rank to the pages it links to. You can stop passing that equity by using the nofollow attribute on your link, but you can’t preserve the link equity this way. When you add a nofollow attribute to the link, it still leaks equity from the source page, it just doesn’t add it to the target page. So no matter how you cut it, they massive number of links are diluting the link strength of the page and tending to make it harder for the engines to figure out which parts of the site are important.
3. Crawl Challenges. This was more of an issue in the old days when search engines crawled only the first 100KB of code or so, but even with improvements, you’re putting a bigger challenge before the search engine.
4. Page Load Times. Again, this is a minor issue, but a massive collection of links in the navigation will slow down load times and rendering. Of course, one decent image or a large CSS file will quickly outweigh this, but we do know that load times are or soon will be taken into account in the Google algorithm at least, and we can expect other engines to follow suit.

Fixing the Mega Menu Problem

So what is an enterprising webmaster to do? You have a number of options, some better than others.

1. Reduce the number of links.good results with clients by reducing navigation from over 60 links down to 22. By tracking click patterns, Ted and his team found that a single link accounted for 60% of the clicks from the front page and the top ten links accounted for 99% of all clicks. So with some serious thinking about information architecture and some good analytics, you can simply reduce the number of links which will also improve usability. If you can get buy in, this is the preferred solution of course, but buy in will be difficult in any large organization unless you have the data and a strong case. And even then, some doorkeeper with a love of the current layout may block any and all arguments, no matter how reasonable.
2. Source-Ordered ContentIt is quite possible to put your menu at the end of your code and get your main page content at the top, but then display the page with the header (and thus the navigation) at the top. This is relatively easy to implement and I used to do it systematically (less so now), but of course, the links are still on your page. So though it mitigates the effects of having all that anchor text and links high on the page, the noise is still there.
3. iframe for navigation. I’ve never actually done this, but some people recommend it for boilerplate content in the site footer. The problem with doing this for the navigation is that you’ve entirely removed the navigation as an on-page factor for relevancy and so forth. So yes, you get rid of the noise in the signal, but you also get rid of a lot of the signal and your ability to build link flow throw the site. It seems like a collossally bad idea.
4. Use HTML 5 and hope the search engines understand. The HTML 5 spec includes the ability to specifically denote part of your document as navigation using the nav element. Of course, this is bleeding edge, so it’s rather early to expect the search engines to be smart enough to understand this and act appropriately. But let’s just assume it’s 2015 and they all “get” this. You still have the fundamental problem that your navigation is a key tool in telling the search engine what your site is about, and by including a massive number of links, you’ve given up your chance to provide signal to help the search engine cut through noise. In other words, at a certain number of links, you’re still adding noise rather than adding signal. So, again, it may mitigate the ill effects of the design, but it still misses out on a great opportunity.
5. Lazy Loading. Lazy loading is where delay loading content until the user wants it. So you images that are low on the page, for example, don’t get loaded until the user scrolls down. There are some excellent JQuery lazy loader plugins that let you implement this simply enough. So that would keep it out of the search engines, but the navigation needs to be responsive and readily available to the user, so load on demand seems like a terrible solution in this case.

So in short, it seems like the best alternative is to use your navigation like a lens to focus the search engine on the main points of your site, and you do that by making hard choices. As I mentioned at the outset of this series, in the end, I found great solutions for mega menus in Drupal , but for all the reasons detailed here, have tended to avoid mega menus if possible.

The video shows it in use. I apologize for the terrible audio that goes in and out of sync and has a lot of noise – I did this on my slow old laptop with the mike built into my cheapo headset. The video is a bit disorganized, but hopefully it’s enough to show you the power of wp_pear-debug. See below the video for some useful links.

The common methods available in php_debug are listed here:
http://www.php-debug.com/www/docs/V2.0.0/PHP_Debug/Debug.html

That page is surprisingly hard to find from the php_debug home page, so make a note of it.

Plugin Home Page
http://www.communitymodder.com/Released-wordpress-plugins/wp-pear-debug-wordpress-plugin.html – nice description, screenshots, and help on how to install and use the plugin.

The official WordPress.org Plugin download page

In the video, I call the dump() method using the direct invocation:
wp_pear_debug::dump($defaults, ‘Defaults1′);

Since I’m not doing much, this was simpler than creating a new object and invoking it as

$debugObject = wp_pear_debug::get();
$debugObject->dump($default);

SEO

• Headspace2 — an SEO Swiss Army Knife. This lets you control titles, control what gets indexed and what doesn’t, create meta descriptions (which are used in the Google results if there is not a matching keyword phrase on your page), integrate analytics packages, use distinct page titles (in the title tag) and post title (in the H1 tag), and much, much more.
• Redirection — Another John Godley plugin like Headspace2. This lets you redirect links, which is useful for at least two situations: 1) you can redirect for pages with obsolete URLs not already handled by WordPress and 2) you can send links to an address like http://yoursite.com/outbound/outgoing—link which allows you to track outbound links and their statistics. If the outbound link may change often, you can redirect to a standard location and just change the URL in one spot.
• Google XML sitemaps — for some reason, the Headspace2 plugin wasn’t working for a while on some sites, so I used this.
• Excerpt Editor — just discovered this one — killer plugin for bulk editing Excerpts on legacy site. The name Excerpt is misleading. In point of fact, what we want is summaries or teasers that give the user a sense of what the article is about, rather than an excerpt (usually the first bit of the post) that may or may not describe the actual content. So this makes the category pages and front page a lot more scannable for the user. Furthermore, since the "excerpts" are not excerpts at all, but unique content, this will help with duplicate content issues (which is why I put it under SEO, though it could just as easily be considered a usability plugin). Anyway, this makes it super easy. I needed to create 25 excerpts quickly on a site the other day and this made it super easy (not so easy that I’ve done it on this blog, but I’m raised by turtles, so things take time).

Interface Customization

• Widget Logic — show/hide widgets for certain categories, pages, users, tags. For example, let’s say you have a text widget that says "Sign up for our newsletter," you might not want this on your newsletter signup page. This lets you show and hide widgets on specific pages and posts, as well as categories pages.
• WP Greet Box — Based on an idea made famous by Seth Godin, which suggest showing some special content only to new users (users with no cookie for your site). So if Greet Box thinks the user has never been to the site before, you could show a header above the post that says "check out these other popular posts" or something like that to orient new users to your site.
• WP Post Admin Column Filter — filters the post admin screen so that it only shows columns you want — no website as I just wrote the pre-alpha version. Very simple and currently hard-coded column selection only.
• Exclude Pages — lets you keep specific pages out of Page widgets/menus. For example, I might want to have a Terms and Conditions page, but I typically wouldn’t want that to show up in my Recent Pages or my main menu. This lets me exclude those.

Spam Protection

• Hashcash — block most spam without making users deal with a CAPTCHA. This can also be used in conjunction with a CAPTCHA or with Akismet (which should be on every WordPress site).

Ad Management

• Ad Injection — inject ad code or any code into posts. A lot of the really major media sites like to put ads in the middle of an article so that the reader has to read over it. This does it automatically for small-timers like us and it could be used for many things besides ads, such as a random image to dress up posts, or whatever.
• Ad rotation — This lets you put a set of ads into rotation for various spots on your site and manage them through a central interface. This is good if you want something simpler than OpenX or Doubleclick for Publishers.

Image Display

• Lightbox Plus — A lightbox, that is a plugin that displays images in a floating layer above the page, without leaving the page. It’s what I’m using on this site.
• Floatbox Plus — a paid lightbox, but very nice. We’re using this on the photo gallery on the site of our Yosemite Vacation Rental.

Debug

• wp pear_debug — sort of like the Drupal devel module. A bit hard to explain and I hope to do a video of this one, but let’s say you need to capture some information about what’s happening inside a plugin. If you have it output all kinds of debug info, that messes up the look and may itself cause things to crash. This lets everything run normally, but outputs the dumped data nicely formatte.
• Debug Bar — this gives you all kinds of information about the setup and system. Not nearly as handy as wp_pear_debug, but still handy.

Contact Forms

• cForms II — Awesome contact form plugin that allows you to build complex forms and require specific information. Very good if you’re capturing leads, taking reservation requests, that sort of thing. We use this to create a reservation request form for our vacation rental in Yosemite. Super handy and it has worked really well for us.
• Contact form from Joost de Valk — simple and it’s by Joost, which means it’s done right. If you don’t need all the bells and whistles of cForms II, this is a good option.
• Secure and Accessible Contact Form — an old workhorse. This is still in use on this site and most other places and never have had a problem.

Geek

• Syntax highlighting evolved — if you post code on your blog, this will give you great syntax highlighting. You can see it in action on this site on my pages on adding noindex and nofollow tags to Drupal category pages and my page on adding custom form labels on Drupal forms (useful if the client just dislikes the standard labels or if you want different labels on the public and admin sides).

Third—Party Integration

• Twitter — display tweets on your site… Since I never actually tweet, I can say this seems to work fine, but it doens’t exactly get a tough workout from me

Automated Backup and Maintainence

• Back up your files — uploads and your custom stuff. Essentially a backup of your wp—content folder (minus base themes I think).
• Database backups emailed to you or just archived.

One of the killer tools is Deploy, which lets you build a site, then put in the FTP and database info for your live site and simply hit a button and push your dev site out to the live site. When coupled with the Drupal Deployment module it’s amazing (post on that coming one of these days).

WordPress, though has a nasty habit of making all the links absolute and then using the General Settings to set site root. The problem is that you have to set this to http://devsite.com for development and then when you deploy to the live site, it will die because it needs to be http://devsite.com

There’s a simply solution though. You can set the URL in your wp_config.php file to use as site root whatever it’s hosted on by simply adding these lines

define(‘WP_SITEURL’, ‘http://’.$_SERVER['HTTP_HOST']);
define(‘WP_HOME’, ‘http://’.$_SERVER['HTTP_HOST']);

That’s it. Now you can deploy and it will just run, out of the box.

Fortunately, Drupal provides you with taxonomy_node_get_terms_by_vocabulary(). In Drupal 6, this takes the $node object and a vocabulary ID. Then you just have to cycle through the terms it returns and see if your term is in there.

In my case, I have some pages that need to be publicly accessible, but must not be in Google or other indexes. So I let those get tagged with a special taxonomy term (“custom” in my case, but it could be “noindex” or anything). All you need to know is the vocabulary ID and the term ID for the term you’re testing for and you can apply the meta noindex to any node. Sometimes node_load() carries a high cost, but since we’re only testing this on nodes and we’re testing for the node in question, that data should be cached and should not result in another database query.

function MYTHEME_preprocess_page(&$vars, $hook) {

// if this is a node and not being edited and it is tagged with term 41, then add a "noindex" tag
   if (arg(0) == 'node' && is_numeric(arg(1)) && is_null(arg(2))) {
	    $node = node_load(arg(1));
	    $terms = taxonomy_node_get_terms_by_vocabulary($node, 2);

		foreach($terms as $term) {
		  if ($term->tid == '41') {
			$vars['head'] = drupal_set_html_head('<meta name="robots" content="noindex" />');
		    break;
		  }
		}
	}
}

In order to get the meta tag to show, you’ll need to clear your caches.

As it turns out, you can simply require the form submission to fail just like it does for credit cards and bring the user back to the checkout details page. To do so, simply go to Admin -> Store Administration -> Configuration -> Shipping Quote Settings (/admin/store/settings/quotes/edit) and turn on “Prevent the customer from completing an order if a shipping quote is not selected.”

And that’s pretty much it – just check that setting and no more accidental free shipping.

Webgility’s eCC seems to be the leading solution for most carts and the ones that have a really nice shipping integration are mostly hosted solutions, which poses a problem if your store has out of the ordinary situations. So what are the options?

Webgility eCC

This is actually a great solution. It has only one real problem from our perspective – it expect all computers to be on the same network. This is not, as it happens, our use case. The ony downsides here seem to be that to get eCC working, you have to have Quickbooks working and if your copies of eCC will be running in a non-networked environment, you have to have 2 full licenses, rather than a full and an add-on license. So the total extra cost is $170 extra for a full eCC license and whatever it costs for a cheap, outdated copy of Quickbooks on EBay (about $50). So for $220, this issue goes away.

In addition, you’re on the hook for a monthly fee of about $16-$35 or so, which is the cost to have a Stamps.com or Endicia Dazzle account which is required for shipping label printing to work. This is typical of most of these systems and not eCC specific.

Deep Thought Courrier

Deep Thought Courrier handles only the Quickbooks end and is $500, so a fair bit pricier than eCC. On the plus side, the Courrier Deep Thought website is actually powered by Ubercart, so they are presumably eating their own dogfood. The app also works with Cubecart and osCommerce. But this still leaves the shipping integration unsolved.

(eCC OR Deep Thought Courrier) + Pony Express Mailer

Meanwhile, Pony Express Mailer handles only shipping integration, though I use the term "integration" a bit loosely. Pony Express is only $40 and connects to a database if it’s local and then to USPS Click n Ship. Of course, an e-commerce site is not going to have a local database, so that means creating a method of building an XML file in your store, downloading that, and then uploading it to Pony Express. At that point, Pony Express supposedly integrates with Click n’ Ship, though I can’t test this because their link on their free trial page is broken. Hopefully they’ll get back to me soon.

The disadvantage here is the extra step required: open website, download orders, open orders from Pony Express for shipping, and then input shipping info into the site, which presumably is going to be a manual cut and paste affair.

The advantage is that it uses Click n’ Ship directly, without going through Stamps.com or Endicia, and thus has no monthly fee. This means a minimum savings of around $200/year.

Atandra T-HUB

Atandra T-HUB is basically the same functionality as eCC, though a fair bit more expensive. If you want Quickbooks and shipping integration, you start at $500 with additional fees for support contracts ($250 per year) and setup and training ($250). Unfortunately, T-HUB does not have an off-the-shelf Ubercart integration, despite supporting a zillion other carts (sigh). So for Ubercart you have three options

• Use their CSV datafile option. Essentially, have your store generate a CSV file, download it, load it into T-HUB and off you go. On the other hand, ugh… Not a very convenient solutions
• Hire them to do a custom integration. Let’s assume this is not cheap
• Do it yourself based on their published XML spec. In this case, you must pay about $450–$700 to have your integration "certified" and of course you still pay the T-HUB license fees.

Farther Afield

If you want to look outside the Book, then you can use xTuple/Postbooks which is sort of an open source Quickbooks as near as I can tell (and more — it looks like a full Enterprise Resource Management system) and it has full Ubercart integration. That will, of course, be a massively hard sell to anyone who already has a business running on Quickbooks.

Then there have been some attempts at a direct Quickbooks integration with Ubercart. That still leaves the shipping problem unsolved, but the bigger problem is that neither of these projects, either Ubercart Quickbooks Integration or Quickbooks API have ever made it as far as an official stable release. Since this is critical financial data were talking about, it would be nice to see something a lot more mature, but it’s a potential place to start if you’re looking to roll your own. If you want to go that route, it looks like the best place to start is George Montana Harkin’s fork of the QB API project.

So in short you use Node Reference to set the source of the data and you use Node Reference Views to set the format of the data.

Enable both modules.

Now, add a new field to your content type. You’ll have three choices – checkboxes, select list or auto-complete. It doesn’t really make any difference. This is just how you’re going to choose which ones to include. Select list works well for a medium number of choices %raisedbyturtles.orgexample the total number of components you’ll have available). On the next screen where you’re configuring the field, choose which content types are going to be available. In our case we have a special content type for components.

Choose your content types

Now we have to create view using the same name as the field type. If you have forgotten what you called it, raisedbyturtles.orgink to get the field name (you can also edit the field and it will tell you on the edit screen).

This field name must be your view name as well (click to enlarge)

Now go over to the Views listing and create a new view and give it the same name as the field. In this case nr_component_weights. The view in this case is simple — we just grab the name of the component and the weight. We format it as fields (inline) and rows.

Views Settings (click to enlarge)

Then, here’s the magic — under Display fields (as opposed to Manage fields) you can choose View as the display mode. The field will now automatically use the View that has the same name.

Choose the View display formatter

Now when you go to your node edit screen, you can select whichever nodes (in this case Components) you want to include.

Select the nodes you want included in the view

Then when you view your page, it will include a field that consists of those nodes, formatted by the View you just created.

Voila - views output as a field

Magic!

1. You don’t have to actually enable the PHP filter, which cuts down on the risk
2. The resulting field won’t be editable by just anyone, but only people who have rights to manage content types
3. full CCK integration
4. Options for storing in DB or not, so you can effectively cache the computed value, which in the case we’ll look at here, has a bit of overhead.

One thing to keep in mind: if you do store the value in the database, I believe this will not update until you save the node. I’m not sure if there’s a refresh mechanism or not.

This is pretty simple – just enable the Computed Field module and create a new field on your content type and make it a Computed Field type.

Then in the computed field, you just add your PHP to grab what you need. In our case, we want to grab the attribute options that are specific to the actual node that we’re looking at.

Obviously, this is hardcoded for Attribute 1.

$result = db_query("select ao.name from
                {uc_product_options} as po, {uc_attribute_options} as ao
                 where ao.aid='1' AND ao.oid=po.oid AND nid='%d'
                 order by `name`", $node->nid);

$items = array();
while ($row = db_fetch_object($result)) {
  $items[] = check_plain($row->name);
}
if (empty($items))
{
 $node_field[0]['value'] = '';
}
else
{
  $num_options = count($items);
  $leftside = '';
  $rightside = '';
  $colsize = intval($num_options/2);

  for ($i=0; $i<$colsize; $i++) {
      $leftside .= '<li>' . $items[$i] . '</li>';
  }
  $leftside = '<ul class="left half">'. $leftside . '</ul>';
  for ($i=$colsize; $i<$num_options; $i++) {
      $rightside .= '<li>' . $items[$i] . '</li>';
  }
  $rightside = (empty($rightside)) ? '' : '<ul class="right half">'. $rightside . '</ul>';
$items = array();
  $node_field[0]['value'] = $leftside . $rightside;
}

And then to output it, in the Display field,

$display = $node_field_item['value'];

So if you have site editors that have the rights to create new menu items, you end up with a massive set of menu choices the user is confronted with and no way to stop them from trying to add a Product link (for example) to the Navigation menu. Or less worrisome, it’s just a hassle for the user to try to find the right menu, since they sort alphabetically. So they’ll have scroll forever for anything with a name that sorts lower than Navigation.

Thankfully, there is a module that lets you hide irrelevant menus in the Drupal node creation form: Menu Settings per Content Type module. This module lets you set it so that when adding content, only menus that might be relevant for that content type get displayed.

Here you can see a before and after, but note that even though I did some Photoshop work to show more of the Before versiraisedbyturtles.org visible, it’s still a lot less than half the choices. Whereas for the After, that shows the entire menu as presented to the content editor/writer.

click to see full size

Let’s say that you have a field like Weight in one of your Drupal content types (for example, an e-commerce site with Ubercart will have Products and those all have a Weight field). So you want to change that on the entry form to something like Shipping Weight (product as packaged), as distinguished, for example, from Field Weight (product as used).

It’s really easy to change that using one of the many string substitution methods in Drupal. You can create a full-on translation file using the built-in Drupal Locale system, but that’s overkill if you’re building a site in English. Simpler is to use the String Overrides module, which lets you simply override any string. Simply input “Weight” in one column and “Shipping Weight” in the other and it’s done!

Simpler still, in your settings.php file, you can simply add a few overrides without the extra overhead of adding a whole module:

 $conf['locale_custom_strings_en'] = array(
   'Weight'      => 'Shipping Weight',
 );

Same effect. Great! Just one little problem. Now if you go to a page that has some type of sorting, like for a menu item or taxonomy term, the Weight field that determines sort order in Drupal now reads “Shipping Weight” when that isn’t what it is at all. Arrgh! Drupal indiscriminately looks for any text wrapped in the t() function that matches “Weight” and replaces it, regardles of context. That’s no good!

To get some more granularity, you need to alter your form on a form-by-form basis. To do this, I created a simply module to make the form tweaks I need. I call it TD_form_tweaks because it is for the Trail Designs site. Like any module, it needs a .info file

td_form_tweaks.info

name = TD Form Tweaks
description = "Programmatically make necessary tweaks to forms on the site."
package = User interface
core = 6.x

version = "6.x-0.9"
core = "6.x"
project = "td_form_tweaks"
datestamp = "1287267734"

And then the actual functionality.

/**
* @file
* td_form_tweaks allows form modifications using the methods outlined
* in this excellent Lullabot post:
* http://www.lullabot.com/articles/modifying-forms-drupal-5-and-6
*/

/**
* Implementation of hook_form_alter().
*
* This lets you make changes to any form in the site. You can alter
* remove or add form elements. You can also alter the validation
* and submission behavior. The name will always be modulename_form_alter.
* If this will only be used on one form, you can use the hook_FORM_ID_alter
* function instead of the hook_form_alter.
* see http://api.drupal.org/api/function/hook_form_FORM_ID_alter/6
*/
<pre>
function td_form_tweaks_form_alter(&$form, $form_state, $form_id) {

/*
* used with devel module to determine form ID and such
*      $dpm($form);
*/

$is_product == FALSE;
$product_types = uc_product_types();

// is user creating a new product page?
if (arg(0) == 'node' && arg(1) == 'add' && in_array(arg(2), $product_types)) {
   $is_product = TRUE;
}

// is user editing an existing product page?
if (arg(0) == 'node' && arg(2) == 'edit') {
  $node = node_load(arg(1));
  if (!empty($node->type) && in_array($node->type, $product_types)) {
     $is_product = TRUE;
  }
}

// if it's a product, alter the form
if ($is_product && $form['#id'] == 'node-form') {
      if (!empty($form['base']['weight']['weight'])) {
        $form['base']['weight']['weight']['#title'] = t('Packaged Weight');
      }
  }
}

And voilà! This could easily include a switch statement and be set up to make any number of changes to any number of product types. A bit more work than a simple string override, yes, but it doesn’t propogate willy-nilly throughout the site.

Essentially, the problem is this: the Fusion theme for Drupal uses Superfish menus. If you have a vertical style menu that expands downwards and you have a block below it, when it expands, the flyout menu will be partialy hidden by the menu block below it.

After much going around, the community came up with a couple of solutions mixed into a long thread on Drupal.org and more succinctly summed up in a support page at Fusion Themes and that content is reiterated on the general Fusion Theme Troubleshooting page. See also the page on Customizing the Fusion dropdown menus which has some useful information on theming that aspect of Fusion. The Fusion folks also have some good instructions on making a slick looking horizontal menu with the second-level menu also horizontal—a neat effect. The third level, if you have one, is then a normal vertical dropdown.

In essence, they suggest setting the containing Drupal block to overflow: visible in the CSS and, if that doesn’t solve the problem, to set the inner block, that is .block .inner to position:static

Neither of those worked for me. I went round and round with this, trying all sorts of combinations, applying these in many combinations to many elements, also playing with position:relative and many other options. Eventually, the solution was dead simple. Assuming that you have a menu named “main” and it’s in a block, then

#block-menu-menu-main {
position:static;
}

That seems to have solved all of my Superfish issues with positioning.

I still couldn’t get the arrows to show using autoArrows, but I simply wanted arrows on all menu items that have a flyout submenu. Since Drupal already applies the class “expanded” to such items, this was easier to do with simple CSS anyway.

li.expanded {
background:url(“/sites/default/themes/acquia_prosper/images/arrow.png”) no-repeat right center transparent;
}

And then finally, to override default Superfish settings as set by Fusion, you simply add a new Superfish initialization function in your js/acquia_prosper_script.js file like so:

Drupal.behaviors.acquia_prosperSuperfish = function (context) {
$(“div.block ul.sf-menu”).superfish({
hoverClass: ‘sfHover’,
delay: 800,
animation: {opacity:’show’,height:’show’},
speed: ‘slow’,
autoArrows: false,
dropShadows: false,
disableHI: false
}).supposition();
};

That pretty much solved my Superfish problems.

One remaining issue is that I wanted some top-level menu items that are NOT links. That is to say, that have no destination page, but only a submenu. Drupal does not by default allow this. The page I mentioned earlier on customizing Fusion dropdowns suggests the Special Menu Items module. I haven’t tried it yet, but it looks like it would do the trick.

In brief, a mega menu is a dropdown menu that shows all child menus (as in child and grandchild menus) in one big flyout.

Many Drupal themes come with Superfish menus, including the popular Fusion family of themes, so that seems like a decent place to start. Over on Dave Buchholz’s I-cre8 blog, he has a brief post on Superfish mega menus that links to a demo and a download.

Beyond Superfish, there is an alpha version of a Megamenu module. Does it play nice with Superfish or replace it? I’m not sure yet.

If you’ve planned way ahead and haven’t started theming yet, you could use the JDT3 theme from JoomlArt which comes with Mega Menus built in, though you will have to buy a membership in JoomlArt in order to access it. The site is running Joomla I suppose, but there is a Drupal demo, which with a little styling would be quite adequate.

Some Other Menu Stuff

The Menu block module creates a block that appears dependent on context. So if you have articles and galleries, if you’re looking at an article category or node, it can give you a menu block with items relevant to navigation from where you are currently. If that makes any sense…

And while we’re at it, if you want to add arrows to Superfish menus in a Fusion theme, the good folks at FusionDrupalThemes.com have a nice little tutorial.

• Ubercart is a shopping cart system built on Drupal. I love the power of Drupal CCK (custom structured data fields of any imaginable sort) plus Views (which allows for amazing custom data extraction and presentation. There’s simply nothing like it and Ubercart lets you build on the power of Drupal.
• Webgility e-Commerce Connector (eCC) is a desktop tool that provides complete integration between Ubercart, the Quickbooks accounting system and shipping systems, notably Endicia Dazzle and Stamps.com.
• Stamps.com lets you buy US Postal Service postage and print shipping labels straight from your computer, for both domestic and international shipping.
• Endicia Dazzle lets you print shipping labels not only from the USPS for domestic and international shipping, but also from UPS and FedEx if you sign up for one of the pricier plans.
• Both pre-fill and print integrated customs declarations as a single label and advise on prohibited items for the country in question (you can’t legally send a radar detector to Swizterland, for example).

Overall, the system is pretty incredible and both Dazzle and Stamps.com work great. As standalone applications, I could take either one and be very happy. Both of them offer 30-day free trials, so there’s no harm in doing what I did and testing both to see which works best for you.

When it comes to using Stamps.com and Endicia Dazzle through the eCC interface, though, there are a couple of differences as you can see in these pictures and as described below (click to see full sized images):

Stamps.com Tab in eCC with Shipping Info

Dazzle—no shipping rates

Endicia—no shipping info

Now when you click to generate the label in Stamps.com it just generates it right from eCC without opening the Stamps.com desktop application. When you click to generate the label via Endicia Dazzle, it takes you to the Dazzle desktop app, but minus the information you really care about—the Send To address and the shipping charges. This is not the case if you are shipping entirely from within the Endicia interface, but in that case, there’s no great way to get your data from your store to Endicia—the best option for Ubercart is to generate an XML file, download it, open Endicia, load the XML file into Endicia and then generate labels.

• Stamps.com actually tells you how much the shipping will cost before you print. To me, this is just a huge plus in favor or Stamps.com
• Stamps.com also keeps you within Webgility eCC and so you see the address that it’s printing for and all the other details. The eCC Dazzle connector transfers you to the desktop Dazzle application when you click on “Generate Label”, but the handoff is a little rough.
  • when the Dazzle app comes up, it does not display the Ship To address or the postage charges.
  • If you have Dazzle already open, the XML file used to transfer data between eCC and Dazzle will be locked, which means that eCC can’t send data to it and you’ll go almost through the whole process and then it will fail with and “Outputfile not generated” error (note, this is not “Output File not generated”, outputfile is a specific term used by the Dazzle XML spec).

  Again, this is another huge plus in favor of Stamps.com

• Dazzle has a “test mode” where it will print labels with “Void” across them, so that you can test print before you commit. I think that’s key, since you don’t see the rates ahead of time, but really not necessary in the Stamps.com interface, because you have all the information you need. So I would say this somewhat mitigates the issues mentioned above, but who wants to print a test label, review it, and then print it for real?

With the USPS shipping, postage is like money. When you print a label, you’ve spent money just as much as if you converted your dollars into a Starbucks Frappuccino and, since the Ship To address is printed on the label, a week-old label is about as hard to convert back into dollars as a week-old Frappuccino. So if you’re primarily shipping USPS, it’s a lot nicer to use the Stamps.com interface.

On the other hand, Stamps.com limits you to just one shipper. If you bump up to one of the Pro Plans with Endicia, you also get UPS, FedEx and Ke

Depending on your budget, however, you can use both. In order to run eCC you need the Dazzle premium service ($16/month). Stamps.com costs about the same