the joshmiller minute

Part of the process that I go through when starting on a new website, is spelling out the content types. During this process I look at a proposed (hopefully approved) sitemap and start listing those things that are fundamentally different. For instance, a news item is much different than, say, a simple "relatively" static page (like About Us). So right away, we have a "page" content type and some other unique and well thought-out types of content.

Along the way it's easy to fall prey to an alluring potential time-saver: Skipping the "secondary" Content Types. It makes logical sense: the less times you have to create a content type, the less times you have to add fields, create views, and eventually link it all together with blocks and some awesome drupal module sauce. At least, in theory, it seems to save you time to skip those pesky "little" content types.

[Bad practices alert] I'm about to digress into a fictional account that should you change some of the content types would be completely true... [/Bad practices alert]

Let's say you have a news section on your new website that has to list an event or two within the post. The CCK and the contributed date module should make this an obvious answer: give your news content type a date field. But wait, each event could have an image and perhaps a description. Well, shoot. Maybe events would be better off as it's own content type. Oh, whatever, we can add in some CCK Text fields and run some contemplate magic so that we can relate the order of both the text fields and the event fields. Finish it all off with some CCK filefield magic through an imagecache view and you're all set! Wait, step back a moment.

Yeah, that's right -- we just created an "event" content type within the news content type. If it takes a lot of "code glue" to make your node display correctly, chances are you would be better off with a secondary content type and some CCK nodereferences.

The moral of my rambling story? Don't skip over the content types. It will come back to bite you. If you have unique content that somehow demands that two (or more) cck fields be linked in a weird way (something like a young frankenstein), chances are you have been combining two or more content types. This leads to frustration and formatting nightmares. Until the flexibility of flexifield becomes more commonplace, for every content there should be a content type.

Straight out of core, Drupal will support multiple websites with different databases all from the same drupal installation. The only configuration needed is naming folders within your sites folder. For more information, you can read about best practices for tweaking the site folder structure.

So, once you have setup the right folders, every site will actually load the SAME index.php. This took me awhile to understand believe. The Drupal system then loads the appropriate sites folder. That's why there is an "all" folder (every site gets these modules and themes) and a "default" folder (if your site is not listed, use this files folder and database settings).

That's pretty darn handy when you need 5 completely different sites that have little relation to each other (like the poster-child of multi-site success stories: One Drupal website for each artist at Sony BMG Records). But what about when you have five inter-related branded websites that need to share things like events, databases, even modules? You could get fancy with a lot of hacking between the "all" folder and specific folders, or you could use the "Domain" module. It gives you domain level configuration options, like setting a different "home" page and choosing that each domain have a different views table. As of today, they have released a version 6 release candidate (might as well call it version 2.0 stable, folks).

http://drupal.org/project/domain

I even found a case study where ISL Consulting helped a wine company setup three or four websites that shared events and ecommerce capabilities using the domain module. http://drupal.org/node/369398

Now all I need to decide is if our client needs 5 independent websites or 1 multisite that shares a lot of things... hmm...

Ok, so at Drupalcon DC I would like to record any sessions that I attend and eventually (within minutes?) get these recordings up on the web for others to enjoy. Free of charge. How will I accomplish this?

1) Ask permission

I will be asking each and every presenter that I encounter if I can post the audio that I record from their session on the web. If they say yes (who wouldn't?) -- then up it goes. 

2) Post it somewhere big

Sure I want people to find it. But I can post it on twitter, and perhaps create a page here to keep track of all the sessions that I have posted. No, what I mean is post it on a server that can accept large (high quality) mp3 files and serve them up to a community that numbers in the tens of thousands. Enter, stage left, Archive.org.

http://www.archive.org/create/

Using a newly minted "joshmiller" account, I will be able to upload hundreds of gigabytes for others to download. Free of charge. Truly amazing.

3) There is no step three

Really, there is no step three. I guess this just means that recording the audio of the sessions that I attend is the first thing I have done to contribute back to Drupal and the community at large.

Yes, that's right! I will be attending the first Drupal Conference held in Washington DC. The geek in me is excited to be surrounded by 1,400 other extremely intelligent geeks sporting laptops and programming when things get quiet. The husband in me is excited about going to DC with my wife. We were even able to get her mother to come along so that the two of them would keep each other busy.

Packing List

• Nice Clothes (I think better when I'm dressed up)
• Two laptops (One for the battery and size, the other because one just isn't enough)
• Digital Voice Recorder (I want to share the sessions I attend with the world, one audio file at a time)
• GPS (I get lost... no seriously... all of the time, in my home town... I live two blocks from work, sometimes I can't find my way home...)

I am now going to be documenting my thoughts on this "On Sugar" platform. My reason? Amazing UI. Did I hesitate? Yeah, it feels kinda girly... but this can be ignored compared to the amazing ease that they make posting my thoughts about Drupal using drupal...