A close relative of mine asked me to help him with choosing, installing and maintaining a blog for him. I am a big fan of Drupal (the software behind this blog, in case you were wondering) but just couldn't bring myself to recommend it. Don't get me wrong, Drupal is IMHO superior in almost all technical aspects but its user interface is just not as easy to use as WordPress. The person in question being a fairly inexperienced user of web technologies, usability was a major concern. The result can be admired at Hartwig Schmidt's blog.
After this site has been using the old, boring, standard Drupal theme for two years, I am now proud to present my own creation: the new Diary Products theme. It uses the phptemplate engine and is a hybrid between table-based and CSS-based layouts as I am not a follower of the pure "Look Ma, No Tables" approach. There are still a few glitches here and there but overall I am quite happy with it.
If you are a user of Urchin 4 or 5 you might have noticed that Urchin’s “Countries” report does not match the standards that Urchin has set for professional website statistics. It seems to be Urchin’s weak spot. It might be ok for you but I was certainly disappointed when I discovered that Urchin determines (or should I rather say: attempts to determine) a visitor’s location from a database that is derived from reverse DNS lookups. This type of location reporting can hardly be considered state-of-the-art, even less so for a commercial website log file analytics application. This article is about how Urchin 5 can be fooled into using true Geo IP mappings for its Countries report.
Urchin is a professional web log analysis and statistics application. It was recently acquired by Google and what used to be called Urchin 6 On Demand is now being integrated into Google Analytics. I don’t know for how long the stand-alone Urchin 5 will be around but right now it is still used by many individuals and corporations. I was not happy with the way Urchin deals with dynamic URLs, i.e. URLs that have query parameters in them. After playing around with Urchin 5's advanced filters for a while, I came to the conclusion that they can be employed to improve Urchin's dynamic URL handling.
If you look at all the pages of a particular site, you will notice that most pages share common parts. These common parts typically include navigation, header, footer, styles and so on. Of course, you can duplicate the common part in every html file on that site. But as the site grows, making a change to one of the common parts ends up in a lot of tedious work: you need to apply the change to every single HTML file on the site. Now imagine your site has 1000 pages! You don't want to do that.
For months, my client's site was running fine using the above
simple solution. Over time though, I noticed several oddities. These oddities
were caused by the fact that the home page is accessible under two URLs, the
the non-canonical root
shown in the figure below.
In modern web design, it is considered good practice to have a "Back To Home" link on every page so that users can easily return to the root of the site, i.e. the home page. Because of that I wanted a Home button on every page of my client's Typo3-based website. Although this seems like a very simple thing to do, it turned out to be quite a challenge in Typo3, especially when trying to avoid duplicate content penalties induced by major search engines.
It's often considered convenient to decorate external links in order to indicate the distinction between links that go to a page on the same site and links that leave the site. On one of my sites I use CSS to set a background bitmap for all links. Until today the bitmap was the same for internal as for external links. I used a little hack in order to set the class attribute of internal links to some value while leaving external links untouched.
One of my clients runs his own intranet for his employees. The intranet currently consists of a bunch of static HTML pages which are written and maintained by a single editor. This approach might have been sufficient five years ago but as the intranet grew it became apparent that the static HTML would become unmanageable in the near future. I therefore suggested replacing the existing solution with a community-oriented CMS. Due to certain requirements the set of contestants was cut down to two: Drupal and Plone. I favored Plone because a) I am slightly disappointed with the direction and pace that Drupal’s development has recently taken and b) I wanted to learn Zope and Plone anyway.
Problem: Your web site uses the Typo3 CMS. Your typoscript templates contains TMENU objects for navigation menus. You want to use the page alias somewhere in the
A tags of these TMENU menus. For example, you want to set the id of a menu item's A tag to the alias field of the page that the menu item stands for.
<a id="widgets" href="...">Buy Widgets</a>
Buy Widgets is the title of the page and
widgets is its alias.
Problem 1: The Site Title Is Global
Your site supports multiple languages using the "modern" single-tree aproach where one page has one or more translations in alternative languages. In Typo3 every page's title usually starts with the site title and the page title is appended to it. The page title can easily be translated by customizing the language-specific header fields. The site title, however, can only be set globally. Consider yourself lucky if your site title is universal across languages. Mine isn't. Furthermore, I like my site's title to contain main search engine keywords, i.e. the words I want my site to be found under in Google, Yahoo and so on.
In this patent assigned to Google, the number of slashes in URLs is used to score the documents to which the URLs point. The existence of this patent led some webmasters to believe that they need to optimize the number of slashes in their URLs in order rank well in Google, especially for hierarchical sites like directories.
My research on a small data set did not give any evidence to support this hypothesis.