Feeds

Author

Upgrade Your Drupal Skills

We trained 1,000+ Drupal Developers over the last decade.

See Advanced Courses NAH, I know Enough
Jul 08 2011
Jul 08

In 2008 I built my first Drupal site, for a furniture business. The site proved to be a big success and we started some other furniture sites as well later on. I also worked on many other Drupal sites and the web in general hasn't been standing still. So last year we decided it was time for an upgrade. Not as easy as thought with a site that is ranking extremely well for a wide range of keywords. It also appeared more difficult to get to a new design.

I moved the entire teakdump site to teakmeubelen.nl, which is super easy with Aegir, added the new theme, and many of the custom modules I had developed for the new Meubels website. With that most of the site was ready except for some settings that weren't easy to grab in code.

As early adopters of technology (especially within the furniture world) we'd also been entertaining the thought of having a site that works well on mobile phones. I had already seen and heard of Mobile Tools, so I gave it a quick try.

The Drupal modules

I was pleasantly surprised by the integration with Display Suite and Context. That plus the Fusion Mobile theme gave me fairly decent mobile site in a very short time.

The mobile build mode make it a snap to get a slightly more usable rendering of nodes on mobile devices and the mobile context makes it easy to quickly rearrange the entire site for mobile devices.

I noticed an issue though: the Display Suite build mode was showing on the desktop site! I had to disable Mobile Tools and look back into this the next day.

Then I checked WURFL but that seemed to just complicate matters a bit more.

As it seems now there was a little bug in the code that sets the build mode, at least I wrote a patch for the Mobile Tools that works very well for me!

The main other thing I ran into was the caching of the theme. I'm using two different themes, one for the desktop version and one for the mobile version of the site. This doesn't work at all if you have the same URLs. So finally I had to take the redirect out of Aegir and into my nginx configuration so that m.teakmeubelen.nl also points to the same install (without a redirect).

SEO

From blog posts I gathered that Google doesn't seem to consider the same content on both desktop and mobile URLs as punishable duplicate content. I just wonder how Google is supposed to detect the mobile URLs (which is one more reason for a nice blog post about my first mobile site).

Now things still need some work here and there but overall I think this site looks great, both on the desktop and on mobiles. And I wonder where to put the iPad and other tablets, as I think the desktop site is just fine on an iPad but Mobile Tools probably considers it mobile hardware anyway.

Jun 30 2011
Jun 30

Submitted by Guaka on June 30, 2011 - 23:18

Whenever you release a site for which it's somewhat important that it's indexed in Google: check your robots.txt.

Last month a new website was released that I had worked on for 2 years. Somehow robots.txt wasn't checked after release. I was curious how the new site was doing in Google but when checking the indexed pages (using the super useful site: operator) I noticed some weird things, pages in Russian were showing on top whereas the Russian language was actually to disappear from the site. So the next thing to check was robots.txt. It looked a bit like this:

User-agent: *
Disallow: /

Which was the exact robots.txt that was used on the development site. This is good for long-term projects. You never know how Googlebot might find your dev site, and once it's found you'll have to change your URL unless you don't care that random people (including folks with bad intentions such as spammers) are looking over your shoulder.

This is how it the crawl rate graph looked in Google Webmasters after fixing this:

Also, if you're on Drupal 6, it's good to uncomment the /sites/ line in robots.txt as it will stop Google from indexing any of your images and other files that are stored in /sites/:

# Disallow: /sites/
May 04 2010
May 04

I'm working on a project to convert a big ASP website into Drupal. On Windows OSes there is not really a distinction between upper and lower case characters in filenames. At first I thought to just leave the capitals, but on web pages links were sometimes with capitals and sometimes lowercase. So I added some stuff to the Apache configuration, usually inside the VirtualHost directive (this does not work in .htaccess):

        
        RewriteEngine on
        RewriteMap lc int:tolower
        RewriteCond %{REQUEST_URI} [A-Z]
        RewriteRule (.*) ${lc:$1} [R=301,L]

But that wasn't all. For the project I'm parsing thousands of ASP files and the plan is to do this everyday while the existing website is updated. We're rsyncing files to be parsed, and the recursively rename to lowercase script I found is nice but it's not very efficient to copy and rename almost 3 GB everyday. I wrote a little Python script in the train today to create lowercase symbolic links to file and directory names with uppercase letters. The hardest part was to properly change directories - it's important to change into the directory the symlink is created but at the end of an os.walk it's necessary to get back to the current working directory.

I'm sure it can be useful to other people dealing with similar issues...

#!/usr/bin/env python
"""
lowlink.py

Recursively creates lower case symlinks to filenames with uppercase letters.

Created by Guaka in 2010, consider this public domain, copy and re-use freely.
"""

import os

def lowlink(path = '.'):
    cwd = os.getcwd()  # os.walk can't handle path changes very well 
    for root, dirs, files in os.walk(path):
        # change directory for symlink creation
        os.chdir(os.path.join(cwd, root))
        print root
        for name in files + dirs:
            lowname = name.lower()
            if name != lowname and not os.path.exists(lowname):
                os.symlink(name, lowname)
        os.chdir(cwd) # restore path for os.walk

lowlink()
my working setup
Jan 25 2010
Jan 25
Sites that show up quickly on a user's screen tend to keep the user's attention for longer and also rank better in Google. So when listening to the excellent Lullabot Podcast 80: Top 40 Drupal Modules Revisited I was caught by Drupal experts stating that Memcache would even speed up your site if it's not a high traffic site. It could off-load the database. I decided to give it a try on a relatively low traffic site of one of my clients. The site is already being served by nginx so the load times are already pretty good. When setting up the experimentation I was a bit confused by the thorough but chaotic instruction to set up memcache. I ran into a problem setting up PECL memcache:
$ sudo pecl install memcache
downloading memcache-2.2.5.tgz ...
Starting to download memcache-2.2.5.tgz (35,981 bytes)
..........done: 35,981 bytes
11 source files, building
running: phpize
Configuring for:
PHP Api Version:         20041225
Zend Module Api No:      20060613
Zend Extension Api No:   220060519
shtool at '/tmp/pear/temp/memcache/build/shtool' does not exist or is not executable.
Make sure that the file exists and is executable and then rerun this script.

ERROR: `phpize' failed
Since I run Debian I solved this by running apt-get install php5-memcache instead. I restarted php-fastcgi (needed for nginx) and added $conf['cache_inc'] ='sites/all/modules/memcache/memcache.db.inc'; to settings.php. Then I ran some tests in Hammerhead.  Not on the front page since there is an embedded Youtube video. I chose a page without any external elements. I was a bit confused at first, and ran several short tests. I forgot to log out and the memcache module was adding a lot of extra information in the bottom.  I thought that was the reason that my site was a lot slower with memcache than without it.  So I logged out and tried again: count latest median avg empty cache with memcache 4 1449 1449 1759 primed cache with memcache 4 1277 1186 1184 empty cache without memcache 4 1239 1283 1483 primed cache without memcache 4 1014 900 950
It could be that I'd have to tweak some memcache settings, or run longer tests, but I think these numbers are clear enough: memcache made my site slower instead of faster!

About Drupal Sun

Drupal Sun is an Evolving Web project. It allows you to:

  • Do full-text search on all the articles in Drupal Planet (thanks to Apache Solr)
  • Facet based on tags, author, or feed
  • Flip through articles quickly (with j/k or arrow keys) to find what you're interested in
  • View the entire article text inline, or in the context of the site where it was created

See the blog post at Evolving Web

Evolving Web