Computery

Full-screen browser for OSX - PlainView

Tags: 

Building my presentation for the FL Drupal Camp I was stuck - neither Firefox nor Safari would let me do a full-screen browser display so the audience was going to be stuck seeing my title bar, browser window border, tool bar, etc - not terribly good for a presentation. A bit of searching later I discovered the perfect solution - PlainView. Built on the same WebKit engine that powers Safari (OSX's built-in web browser), it very simply gives you a border-free, toolbar-free browser that can be made to display in the full screen, hiding everything else. It suited my needs perfectly, I'll definitely be using it again and strongly recommend it.

Moving your TimeMachine

Tags: 

It's bound to happen to everyone, they outgrow their TimeMachine and want a new one, a bigger one, one that will allow them to go further into the past... I'm talking about OSX's built-in backup system here, I don't know what you were thinking..

So ever since starting to use OSX Leopard I've been using TimeMachine to keep a running backup of my laptop for two reasons - I can instantly jump back to an old revision of a file, and it keeps a near-constant mirror of the OS as it is with all of the software & settings intact. My laptop came with a 120gb drive and I've been using a 160gb USB drive for TimeMachine. Obviously enough, when this is my main machine I move a lot of files around - download lots of files (all legit), delete some, move others to a file server, but with TimeMachine keeping a regular hourly backup of all change files it can end up bloating up pretty quickly. Sure enough, within a few short months I'd filled up the drive and for the past three or four months it regularly informs me that it has flushed some older backups in preference to keeping newer data.

It's 2009 and hard drives of all sorts are insanely cheap. Taking advantage of the early sales I snagged a 320gb replacement internal drive for the laptop and a 500gb external drive for TimeMachine. Incidentally, both of the drives were made by Seagate, as all of my drives are, as all of their drives (at least up through their January 2009 new models) come with a five year warranty, so between backups I'm (mostly) guaranteed five years of usable storage.

Moving on.

I personally don't like moving data off a primary drive due to the inherent reliability problems of external storage - if it's important data then it needs to be on an actively used internal drive, not on a DVD or CD sitting on a shelf somewhere for grubby little fingers to play with (or get knocked over), and definitely not on a USB memory key that's going to get put through it's paces in the next laundry cycle. All external storage formats should be used for backups exclusively. End of story.

So, in order to keep my data intact I planned a drive shuffle. First I was going to migrate the TimeMachine backup data to the new external drive, then I was going to swap out the internal drives and follow up with a quick restore off the backup drive to the main OS drive. Simple enough, and something I've done before.

Well the first step, as mentioned, was to migrate the 160gb (actually only 145gb due to drive companies lying about the size of a "gigabyte") to the new 500gb drive so I could retain the last few months of data as an active backup. That seemed simple enough. Because the drive comes pre-formatted for use with Windows (NTFS), I plugged the new drive to my laptop, ran the funky Seagate software installer & allowed it to wipe & repartition my drive for OSX. After rebooting (yeah, go figure, silly company) I has a 465gb usable drive. But it didn't have my TimeMachine data.

The official guideline on migrating TimeMachine data is to use DiskUtility to "restore" the data to a new drive - odd terminology, but it kinda makes sense. Well, for some odd reason it started giving me an error when I tried this. Just to be sure (and because computers make us crazy by expecting different outcomes for repeating the same procedures) I tried again, and sure enough, the same error.

Poop.

A quick google later and I find two shareware utilities that might also do the trick - CarbonCopyCloner and the amusingly titled SuperDuper. Long story short - both tools would run for a few minutes and then seem to get stuck, sitting with zero change in progress while saying they're copying this file that's actually rather tiny (so it wasn't that it was just moving a huge file). Enough of that, back to google.

A bit more research turned up an article on the excellent MacOSXHints.com which detailed how to use the UNIX tool dd to copy a drive, including to use it to recover lost data off a partition. So I gave it a spin.

The instructions are simple. First off, use the tool "df" to find out the exact location of the partitions or drives you wish to copy (the first column marked "Filesystem"), e.g. the 160gb drive showed as "/dev/disk3" and its partition as "/dev/disk3s2", while the 500gb drive was "/dev/disk2". Then, once you know the drives you just run the following command: "dd olddrive newdrive" e.g. "dd /dev/disk3 /dev/disk2".

Well, while I was overjoyed that my first h@rDk0r3 use of UNIX in some time actually started to do something, I was dismayed to see it say the average copy speed was "1705KB" i.e. 1.7meg per second, and at that rate would take 26 hours to complete. Bummer. As it turns out, by default it works with tiny 512byte data blocks, which obviously takes FOREVER.

While researching it I come across another tool that bids itself as a simpler tool for migrating partitions called "ddrescue". I do a quick download, compile and run, and sure enough it's using the same block size. Sure enough, there's a handy little option called "--block-size", or just "-b" for short, that lets you tell it to use larger blocks of data at a time. A quick "-b 4096" later and the transfer speed jumped to ~5KB. Good enough, though it still took six hours.

After the six hours I now had a drive that seemed to all be there, but it only said it was 145gb and my efforts to resize it with Disk Utility just gave a wonderfully error that says "Error with partition: MediaKit reports partition (map) too small".

Back to the drawing board.

I then thought "maybe I have to copy just the partition instead of the entire drive. Six hours later... and I was left with basically the same thing - Disk Utility said that the entire drive was in one large 465gb partition, but Finder said it was only 145gb.

Back to the drawing board. Again.

And back to Disk Utility.

This time around I deleted the existing partition first so that the 500gb drive was completely blank. I then set the Rescue action to erase the destination. Four hours later it had copied all of the data, another two hours later and it had verified the data.

Golden. Or so I thought.

I now have a single, 465gb partition that shows up in Finder and Disk Utility. The only problem is that Disk Utility says that the drive itself has no partitions! While I'm stumped, I think I'm going to count my blessings, just deal with it - TimeMachine works again, and if I find a fix I'll post an update.

Come to DrupalCamp Florida on Feb 7th, 2009

Tags: 

Anyone who has February 7th (2009) available, and who isn't already going to the excellent Acts_as_Conference, should take a trip to Altamonte Springs for DrupalCamp Florida! This new event promises a day's worth of free presentations on all things Drupal from some of Florida's best consultants and advanced users, including the exceedingly talented Ryan Price. I've proposed a few talks myself, and the unconference-style of the weekend will mean almost anyone with a bit of experience should feel comfortable taking a few minutes to share something with the rest of the group. At the time of writing there are about 50 people signed up, so there's plenty more space available. I strongly recommend anyone interested in content management, or even just PHP, take at least some time out of their day on the 7th to come along for a look-see.

In addition to the presentations on the 7th there's an effort to have a workshop / group help-like setup for the 8th, and hopefully we'll get to put some of our skills to good use helping others and learning more.

Be there!

Building a Drupal site - pick a theme

Tags: 

When building a new site in Drupal, unless you've got a large team of developers, one of the first things you're going to want to do is pick a new theme, i.e. a site template. Thanks to the efforts of hundreds of developers from around the world, there are over 170 themes for you to investigate for Drupal 6 (even more if you're stuck with Drupal 5), each one with its own set of traits. For example some use a table-based layout while others use a pure CSS layout, some are single-column designs though most are multi-column, some that have literally tons of slots for you to add content blocks, some with multiple color options, and some that act as just a bare starting point for you to build your own.

Here are a few things to look for when choosing a theme:

Tableless Design

When you design a page layout you have two options for positioning the various components - tables or CSS. Tables are the old way of doing the design and are very inflexible, not to mention difficult to manage, so CSS has become the defacto standard since the millennium.

An important benefit of a CSS design is that you can add an alternative CSS file to make your page instantly printable. It's both horrible from a user friendliness standpoint to require people click to a separate page for it to be printable, but I honestly also find it really dumb to require people do some special trick just to print your content rather than just clicking the browser's Print button. It also gives you, as the site developer (or the person hiring the developer) a much easier time to make global changes, e.g. if you want to make your site all green & red for the holidays or if maybe you decide to tweak the layout a small bit every few months to add some variety, it'll be much easier when there's one master CSS file.

While some of the table-based themes might look good, long-term you and your site will be better off with a CSS-based theme.

Multiple Collapsible Block Regions

Drupal allows you to place portions of content / functionality around your page using things it calls "blocks". Many plugins also can add even more blocks available for you to use, e.g. Tagadelic adds a block showing a tag cloud for your site's keywords, and as a developer you can really easily create your own. Blocks are positioned on your site into spaces called "regions", with most themes having a few standard regions - heading, left sidebar, top sidebar and footer.

While some have taken this flexibility and have gone completely nuts, e.g. AD Blueprint which as 44 regions, I tend to look for one with about eight regions - the usual header, footer and two sidebars, then also one above and below the page content body, plus maybe an additional one between the header and body for e.g. highlighting the week's most important content

Valid Code

In today's technologically competent world there's no excuse for sites to not be present valid code. Using the World Wide Web Consortium's HTML validator and CSS validator, every developer needs to ensure their code is tested and compliant with XHTML 1.0 Transitional ("Strict" is better) and has valid CSS code. Further, themes need to be tested to ensure approximately 99% browser compatibility, which means IE6 & IE7, Firefox and Safari 3. Thankfully most theme developers have done their best to stick with this, so your visitors should have a pleasant experience.

Hopefully the above will help you on your way to build the site of your dreams, with the CMS of your dreams :)

URL aliases tip for migrating from Wordpress to Drupal

Tags: 

I recently re-launched a site of mine, breastfeedingfordads.com, which I migrated from Wordpress to Drupal. It took a bit of work to get the basics the way I wanted, and replicate the functionality of the plugins I was using, but it seems to work well.

There was a bit of a problem, however. Out of the box, all of the old articles that were converted to the "blog" content type (as created using the converter mentioned before) had the arcane default URL structure of "content/[title-raw]". An obvious problem was that this didn't match the Wordpress default nor my custom format of "[yyyy]/[mm]/[title-raw]". This was leaving me with lots of unnecessary 404 errors and disgruntled visitors, so it needed to be fixed.

Here's how I fixed it:

First off I had to update the existing settings so that Global Redirect wouldn't keep re-building the wrong ones..

  • I went to the "Automated Alias Settings" page (Site Building -> URL Aliases -> Automated Alias Settings).
  • Under the "General Settings" section I removed everything from the "Strings to Remove" text box so all words would be retained.
  • Under the "General Settings" section I also enabled the "Reduce strings to letters and numbers from ASCII-96"
  • Under the "Node Path Settings" section I updated "Blog entry paths" to "[yyyy]/[mm]/[title-raw]".
  • Under the
  • After that I hit "Save Configuration".

Next off I had to purge the old aliases:

  • I went to the "Delete Aliases" page (Site Building -> URL Aliases -> Delete Aliases).
  • Once there I selected "content" and clicked "Delete Aliases Now".
  • After a moment all of the page aliases had been removed.

Lastly, I wanted to create the correct aliases ahead of time - I could have left it Global Redirect to do, but best to take care of this now:

  • Again, back to the "Automated Alias Settings" page.
  • Under the "Node Path Settings" section I opened the "Replacement Patterns" section and clicked on "Bulk generate aliases".
  • I think clicked "Save Configuration" to have all of the URLs updated, and because there were more than 50 nodes to update I had to run it twice.

Note that the last step could have been done in one step by updating the "Maximum number f objects to alias in a bulk operation" to a higher number, but on very large sites you should be careful to not set it too high or the page will time out.

Anyway, after a few quick moments all of the old URLs were no longer generating 404 errors.

Pages

Subscribe to Computery