When I added the Dreamfall review yesterday I realized certain things did not work as they should, and after investigating the problem further it turned out that there was a problem with blog type nodes. After receiving good advice in the #drupal at irc.freenode.net I began to troubleshoot, and in the process found a great way to set up a staging version of my site for testing new code and modules.
As you may have noticed, some pages on this site have products attached. These are links to products at amazon.com, title, price and all such information about the items is added through use of the Amazon Associate Web Services. For most nodes which don't have any ASINs associated with them, the right hand block will show a random item. Nodes that have ASINs associated with them will display a list of titles and those titles will also display one at a time randomly in the right hand block.
When I set up the Dreamfall blog entry and added the ASINs for the related products, only random products would show, as if the node had no ASINs associated with it. Applying the old Sherlock Holmes method of exclusion, and a fair deal of abduction, I found out that the Drupal function I use to find the NID (node id) of the node returned null. The function I use is called arg(x) and takes an argument X which is the index of the path token you wish to retrieve. Say the path is node/23, arg(1) will return 23. This may seem crude to some professional and skilled programmers but sems to be common practice and it works 99% of the time.
That arg() doesn't work is strange indeed, and shouldn't happen. Using code supplied by Heine in #drupal I tested it on a plain vanilla Drupal install and it worked fine. The cause had to be a a contributed module. Now I couldn't test the modules on the test site, I needed a copy of my real site and I couldn't do testing on the live site so I decided to set up a test site.
Following the instructions given here I got started. It's rather basic, most of it, and not really hard to do if you have basic knowledge of UNIX and have shell/SSH access to your host's server. Problem arised when it turned out I couldn't use the method described since Doreo uses CPanel, a very popular server application and administration software for managing webhosting accounts. CPanel and Web Hosting Manager are great, I used them for a while when this site was hosted on a VPS, they automate many repetitive common tasks. However as with all automated systems they aren't so flexible. The tutorial above requires changes to httpd.conf in order to configure a new VirtualHost, as it's called. A VirtualHost, or VHost is basically just a mapping for a site to a directory on a web server and makes it possible to run several sites off the same machine. I was being told that CPanel would most likely remove any manual changes the second a new site was set up with WHM so the best solution would then be to configure a sub domain.
The greatest thing about having two directories, as the tutorial suggests is that you can easily copy files between them and won't risk deleting or modifying files on the live site. Now this wasn't an option and copying files would be a problem since copying all subfolders of one folder to one of its subfolders poses a problem, a folder cannot be copied to itself, since it may cause a paradox, which leads to a black hole which means big problems for humankind. Problems that probably don't last for more than a split second, but I am digressing.
Using a search engine I finally found a solution and it has been posted as a comment available here. So if your host uses CPanel and WHM, set up a subdomain and use the method I described and it will work like a charm. You will have your own private sandbox to play in!
As for the strange arg(1) problem, well after disabling all contributed modules and not noticing any changes, I uploaded the original unchanged core modules one by one. After uploading a fresh blog.module the problem suddenly disappeared. I erupted in euphoria screaming eureka! I had found the culprit!
Using ConTEXT and its Compare function, I put the two (the original and apparently modified blog.module) and compared them. Apparently I had made some changes to how the breadcrumbs array was built. Having not investigated this further it would seem Drupal feeds the path of the breadcrumb array back to itself as a request string, so regardless of what request string you pass, it will take precedence.
So if you would happen to have problems with arg(1) returning null, check all code you've modified that changes how breadcrumb trails are built and displayed.