Edit: I've added a link to a lovely zoomable map of IP address allocations to the bottom of this post.
What with the ipcalypse being well and truly upon us I thought I should see how the final IP allocation distribution has ended up. By continent, that is. The data was trivially easy to find, so I stuck it in a spreadsheet and generated a graph:
Back in 1998 our old trusty HP LaserJet MP5 broke and we replaced it with an HP LaserJet MP6. Over the decades it has provided its humans with reliable Mac OS and Linux printing joy and one of the cats with a warm place to sit in winter and - once - an emergency litter tray.
The cat wee didn't kill it though and after a clean up it provided close to another decade's worth of (slightly smelly) prints.
Sadly it's now running low on toner and it would seem that obtaining new toner cartridges for it is no longer a matter of simply popping down to OfficeWorks. Time then to go shopping for printers.
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.