After an unnamed vBulletin website fell over for the umpteenth time overnight, I suggested to its owner that we upgrade the Linux install that runs it to something vaguely recent. That would allow us to make use of the varnish cache to speed things up.
To avoid misinterpretation of the project name, Linux has had a pronunciation guide for quite some time.
At Drupal Down Under in Brisbane, Australia, kattekrab obtained one for Drupal as well. So if you hear people mispronouncing "Drupal", you can now point them at an authoritative example :-)
For some time now I've been working on a Drupal site that consists mainly of scraped content from a proprietary, ASP based CMS from the late nineties. The Simple HTML Dom Parser, used from within a drush script, has been invaluable. It made scraping the old site content and importing it as Drupal nodes a relative breeze. (No access to the database used by the CMS, boo!)
Part of setting up the new site is importing users and their content profile nodes from a different Drupal site, that was setup a year or two ago to manage an event.
I had hoped there would be a way for me to export these users and their profile nodes from one Drupal to the other, but though I found modules to export one or the other, I might still end up with profile nodes that were no longer related to their users. Of course, that's pretty useless.
When I remembered I was also supposed to add all these users to a simplenews newsletter, the proverbial light bulb came on.
Using the taxonomy view to change how taxonomy listings are displayed is rather nifty. However, I found myself being asked by a client to make sure the page title (ie: the taxonomy term as set by the argument) was properly title-cased. That issue comes up from time to time on the #drupal-support IRC channel, so I suspected it would be easy, as many people had done this.
… or "how I re-invented the wheel". Again
I found myself needing a tertiary menu in Drupal yesterday, which sadly it doesn't provide by default. There is a primary menu and a secondary menu that can auto-populate based on the primary menu selection, but sadly that's the level at which it stops.
Google helped me find a few blogs that show how to easily generate an arbitrary level sub-menu, though most are for D5 and not D6. Ignacio Segura amended code on this blog that makes it all work for D6:
I'm in the process of setting up Redmine (version 1.0-stable) on an Ubuntu 8.04 virtual machine. Getting a recent enough gem and rails is less fun than you might imagine, but the big issue I came across was a bug in the database model, which makes MySQL 5.1 (MariaDB 5.1 in my case) barf on installation.
There is a fix, but I am running from a git clone didn't want to download and apply a diff file to that repository. A quick google found what I need: the git cherry-pick command. It allows you to grab a single commit and apply its changes to your branch. In my case:
git cherry-pick a628b0f186cf4d182ce5cee1a497ad42c5246406
Because all commits have a unique label, when 1.0.1 is released and I update my git clone, I won't suffer merge conflicts from this already-applied change. Lovely :-)
When creating a Drupal site for clients, many people use a temporary hostname for development purposes. What's more, that hostname is not generally on the same domain as the production site. I'm sure I'm not the only one to use client,mydomain.com to develop the www.client.com site.
[[wysiwyg_imageupload:21:]]
When you — like me — use Drupal in a multisite setup, where the same codebase is shared between many sites, you'll have per-site settings, files and images. These are located in a directory structure that's based on the hostname you're accessing the site under. Eg: the files and settings for client.mydomain.com live in the sites/client.mydomain.com/ directory.
However, when the time comes to deploy the site to its production hostname, those settings and files need to live somewhere else. Moving them can result in link and image breakage on the front-end, which is never a good look and means you might need to painstakingly update links and images on all your pages.
[[wysiwyg_imageupload:17:]]
Seeing as the Australian governments proposed mandatory internet filter will filter all traffic on port 80, I thought it
would be helpful to provide a Drupal module that allows you to automagically provide an alternate link to each page on a site.
Your web server should be configured to serve content on a 2nd port, beside port 80, so as to not interfere with browsing requests from users outside of Australia.
Watching the news this evening we inadvisably didn't skip past the sports news. So we were treated to a montage of so-called sports people punching and elbowing each other on the field.
[[wysiwyg_imageupload:7:]]
The footage was somewhat reminiscent of the CCTV footage that is sometimes shown on the news after there has been a fight or bashing at a pub or club.
A major difference though, is that news of a bashing at a pub or club is usually followed with details of someone being arrested and some time later of them being convicted and going to jail.
Some time ago I attended the "Optimisation by Design" course from Open Query¹. In it, Arjen teaches how writing better queries and schemas can make your database access much faster (and more reliable). One such way of optimising things is by adding appropriate query hints or flags. These hints are magic strings that control how a server executes a query or how it returns results.
An example of such a hint is SQL_CALC_FOUND_ROWS. You use it in a select query with a LIMIT clause. It instructs the server to select a limited numbers of rows, but also to calculate the total number of rows that would have been returned without the limit clause in place. That total number of rows is stored in a session variable, which can be retrieved via SELECT FOUND_ROWS(); That simply reads the variable and clears it on the server, it doesn't actually have to look at any table or index data, so it's very fast.
This is useful when queries are used to generate pages of data where a user can click a specific page number or click previous/next page. In this case you need the total number of rows to determine how many pages you need to generate links for.
The traditional way is to first run a SELECT COUNT(*) query and then select the rows you want, with LIMIT. If you don't use a WHERE clause in your query, this can be pretty fast on MyISAM, as it has a magic variable that contains the number of rows in a table. On InnoDB however, which is my storage engine of choice, there is no such variable and consequently it's not pretty fast.