Taking a break from writing about Drupal here at the end of the week as according to my About page, I am also "allowed" to write about music...

This boxed set was released a few years back and won 2 Grammys. I have been a fan of Jelly Roll Morton for about 10 years now, I reckon. I'm not a huge Jazz aficionado or anything. I can appreciate more or less all forms of Jazz but have always been fonder of the earlier stuff, and of vocal Jazz - Billie, Ella, Jelly Roll, Sara Vaughn, Nina Simone, etc.

Anyhow, I think I'll have to get this boxed set at some point. It seems it contains all of the original recordings and interviews done by Alan Lomax, one of the greatest folklorists and musicologists of the 20th century. Seems there are some explicit bits in these recordings, especially when Mr. Morton migh have tipped the whiskey bottle a bit before performing or being interviewed.

Well, maybe a friend or family member who is reading this post will take note and I'll have a surprise on my next birthday :-)

In today's Daily Drupal, I'm presenting an issue we're facing: how to share content across our Drupal sites. We are migrating roughly 70 websites to Drupal in the manner described on this page.

Currently, like many websites, we use Dreamweaver to manage our flagship site with many SSIs (Server Side Includes) that are used for sharing bits of content on multiple pages on our site but also for sharing with our 70-odd affiliate sites. So, we're looking for a clean and elegant solution in Drupal for translating this relationship, the relationship between SSIs and their respective pages/sites.

We have considered solutions that involve:

• using RSS feed(s) in some creative way
• standard blocks shared between sites (how to do this?)

but are pretty sure neither are appropriate for this task. For instance, blocks, by default, appear on every page and that's not what we want. We want certain bits of content (currently stored in SSIs or .inc files) to be able to be placed within specific pages on multiple sites.

The Deploy Module looks promising but is still in development. Something like Crossite looks interesting but has no Drupal 6 version. And, finally, I turned up the SSI Module, also still in development, which looks appealing as well.

I'm sure we'll figure this out as I'd imagine many many folks are moving to CMSes like Drupal from a Dreamweaver, static .html, SSI world. And, my experience so far with Drupal is that it is very flexible and thus there are probably several ways to accomplish this.

Beginning next week, The Daily Drupal will become The Weekly Drupal (I was, perhaps, a bit too ambitious with the "daily" part). I will try to write a very thorough, weekly post about my experience working with Drupal. The RSS feed remains here and the tag has been updated to "Weekly Drupal."

Today's Daily Drupal is about Podcasting in Drupal. We are migrating our flagship site, plus 70-odd other sites, into Drupal. On our flagship site, we offer Podcasts via a normal Podcast RSS feed as well as on player pages. I think this is a fairly common arrangement for Podcasters: let visitors listen right away and download an .mp3, .mp4, etc. and if they like, they can subscribe via an RSS link.

So, I'm making notes for myself and gathering information on "best practices" (how folks are arranging themselves to podcast in Drupal). Here is what I have so far:

Modules needed:

• FileField Podcaster: http://drupal.org/project/ffpc
• Views: http://drupal.org/project/views
• CCK: http://drupal.org/project/cck
• SWF Tools: http://drupal.org/project/swftools
• Feedburner: http://drupal.org/project/feedburner/ (to route our feed through our existing Feedburner URL)

I believe this video shows more or less exactly how to do what we need to do re-create our Podcast infrastructure.

Some questions that I have at this point that actually relate to Drupal content generally are:

• How to create a Podcast "template" page? (we have a fixed footer to our current player page that has links to sharing, subscribing, emailing, etc. and a fixed logo on the page that I wish to use on each player page without having to insert them everytime)
• I know the FileField Podcaster Module listed above allows you to automate the creation of the RSS feed XML - is this then editable later or can one create a template for this so that additional metadata could be inserted (i.e., our logo for iTunes presentation, etc.)?

I'm looking forward to using Drupal to automate the posting of Podcasts to our site. Right now, the process is a bit too manual and thus prone to link insertion errors, metadata slip-ups in the RSS feed, omissions, etc.

This has been the Daily Drupal for 21 July 2009. To subscribe to The Daily Drupal, a week-daily column about Drupal from the perspective of a new Drupal user, use this feed.

Today's Daily Drupal is about the Taxonomy Module and working with taxonomies or structured vocabularies in Drupal. Now, admittedly, this is a subject close to my heart, me being a librarian and all - I love me some thesauri, structured vocabularies and metadata standards! Again, we're in our 3rd month using Drupal and are just starting to get into the real configuration and development in order to migrate roughly 70 websites into a single codebase, multi-site install of Drupal. (see here)

We plan to have several taxonomies of varying degrees of specificity on our flagship site and some basic topical and hierarchical ones used across our affiliate sites. For reference, I'm beginning by re-reading the basic overview of using taxonomies in Drupal beginning on page 59 of O'Reilly's Using Drupal book, a book I highly recommend if you're new to Drupal, as well as the documentation on drupal.org here. According to drupal.org:

Taxonomy is the practice and science of classification. Taxonomy is a method of organizing content on a site. For example classifying music by genre could generate this list: classical, jazz, rock. A single area such as "classical" might be further classified as concertos, sonatas, symphonies, and so on.

Of the three types of vocabularies that Drupal supports...

• simple list of terms
• organized hierarchies of terms
• free tagging

... we only plan to use the first 2. It is possible that we will allow free tagging in a future password-protected, intranet environment but not on our sites now, as a rule. So, I'm beginning with a very simple, high-level "master" taxonomy for organizing our content prior to content migration later this year. In addition, we will have a "news" taxonomy as well as an "archiving" taxonomy.

One of the issues we are facing is the balance between employing Drupal's "content types" in conjunction with or possibly instead of a taxonomy. For example, should a podcast be a content type "podcast" and then be tagged using one of our taxonomies, or should it be simply a page or story in the system and then be tagged with taxonomy term "podcast" in some kind of structured vocabulary. We are opting for the former, but I think an argument could be made for the latter, depending on the context of the information.

In general, we're going to try to keep our "content types" to a minimum and employ taxonomies plus the Views Module to present content and create rich RSS feeds, etc.

See also:

• Taxonomy presentation from Drupalcamp Colorado
• More about Taxonomy
• Drupal taxonomy tutorial

This has been the Daily Drupal for 21 July 2009. To subscribe to The Daily Drupal, a week-daily column about Drupal from the perspective of a new Drupal user, use this feed.

Today's Daily Drupal is about integrating Drupal with external databases. Obviously this is a huge topic, so a forum like The Daily Drupal is not ideal to cover it in a post. But, as The Daily Drupal is really just my log about working with Drupal (we started our project just over 2 months ago now, so I'm very new to the system), I'll throw out some keywords and thoughts on this topic, as I see it now.

We have a large, external user database that we need to use to authenticate users in our Drupal installation (single codebase, multi-site installation for about 70 sites as here). So, what we need to happen is this: when a user visits any one of our Drupal sites, they can login with the credentials used for current, externally hosted database and their roles, affiliations and other information are "imported" or mapped to Drupal permissions, roles, etc. thus allowing this external database to control what they can and can't do on our sites.

We've been given some advice from consultants, namely:

One method:

• implement the hook_form_alter() to alter the way authentication is done
• calls an our external DB returning an XML response with the required info

Another method:

• create a MySQL database that the external DB managers can insert data into (preferably one dump with subsequent hourly updates transferring changed data only)
• then, run a process that maps this MySQL DB to the user DB of Drupal

All seems reasonable to me, and I'm sure that there are many (not infinite) other paradigms one could use to accomplish this task. I'm also quite aware that the technical details might not be as straightforward as this all sounds depending on the DB and complexity of the roles/permissions scheme. Obviously, whichever method we ultimately use, security will be of highest priority. I have searched drupal.org for this issue but found it slightly tricky. I searched for phrases like "authenticating users from external database" and "external database integration with drupal" but found a lot of unanswered questions and no clear instructions. I'm not surprised as this issue is so case-specific and really depends on which DB you're trying to plug into Drupal.

This functionality is not urgent right now in our project, so I'll continue the search for case studies, example scenarios, etc. and see what I come up with. One thing's for sure, we're definitely NOT the only Drupal newbies facing this issue as many people must have data in existing DBs that wish to use in Drupal.

This has been the Daily Drupal for 21 July 2009. To subscribe to The Daily Drupal, week-daily column about Drupal from the perspective of a new Drupal user, use this feed.

PS. I promised to write about something besides Drupal on this blog, namely: library and information science, Web 2.0 and Web 3.0/Semantic Web as well as occasional posts about music. This is still the case. I'm just drowning in Drupal at the moment!

Today's Daily Drupal is a topic that is very new to me: backing up Drupal. There is a related topic which is versioning and how to handle versions of one's Drupal "build" which I think needs addressing here as well.

So, we've had Drupal installed now for about 2 1/2 months. We have several test sites running from a single codebase using multi-site installation as per this page. The work is moving along and Drupal has proved to be quite user-friendly from the backend prospective (kinda fun, too!). We're very keen now, of course, to begin implementing backup procedures. As I understand, there are several critical components for backup in a Drupal installation:

• MySQL database(s)
• Drupal's core: all files including Modules, Themes, .php files, etc.
• Any contributed modules/our own work

This page gives further details on how all this can and should be done. I find it interesting the tip about one's content needing to exist in 3 places to exist. So, if you're in a hosted environment, I guess that would in your host directory, in your hosts backup directory and somewhere locally on a machine you control at the minimum. I, also, highly recommend getting a failover service. We currently use a failover service for our flagship site. This means, we have a service that checks every few seconds to see if our site is up. If not, if "fails over" to a server where we keep a mirror of our site. In addition, we have tape backups and backups made on DVDs and external hard drives. So, by my count, we currently have our data in 4 places, so I guess we're doing okay.

A related question I have about Drupal that relates to backing up is versioning. Is it necessary to have a build management system running the background of Drupal controlling versioning using something like a CVS repository along with something like ANT or Phing. I am, admittedly, NOT a programmer, but it has been suggested that we could use CVS and Phing in our project to control versioning of our Drupal installation. My question: is this overkill? Doesn't Drupal have it's own mechanisms for versioning (Drupal 6.13, 6.14, etc.) and through modules like the Devel Module one can manage the development of one's own Drupal installation without these other backend systems?

I have been warned that we need a way to create something called a "clean build" of Drupal via the employment of a CVS repository and Phing. Should I be worried if we don't use these backend build management systems. We aren't scheduled to do a lot of custom module development. Thus, won't Drupal's existing backup and versioning capabilities suffice for us?

Today's Daily Drupal is a quick one about a new tool I just discovered: Open Atrium. The site describes it with this formula:

Apache + PHP + MySQL + Drupal + Hot Sauce = Open Atrium

Quote from the sites:

Open Atrium is an intranet in a box that has group spaces to allow different teams to have their own conversations. It comes with six features - a blog, a wiki, a calendar, a to do list, a shoutbox, and a dashboard to manage it all.

Sounds really promising. We are planning to create an intranet or community platform with Drupal at some stage after we migrate our 70+ sites to Drupal. This could be the solution. The documentation says it's basically like installing Drupal.

I was wondering several months ago if there exist any pre-configured installations of Drupal (a la Acquia) for certain applications - intranets, blogs, wikis, community sites, etc. I know you can create all these with Drupal but wondered if there was Drupal "blog installer" or "community site" installer which basically offered the developer an out-of-the-box configured community site with everything turned on. Seems that's what this is for intranets - really exciting.

When I have a moment (and that might be a while as we're knee-deep in our Drupal project), I plan to install and assess the suitability of Open Atrium to serve as our community platform/intranet.

For now, I think I'll watch the video they have on the site and do some more reading. Congrats to the Open Atrium folks for making this tool. It looks like a really interesting.

Today's Daily Drupal is about XML web services. Admittedly, this is vague territory for me as I'm not a programmer but as I understand it, web services using protocols like SOAP are an efficient way to exchange data between websites, computers, etc. Our Drupal project will involve obtaining some data from an external database hosted in another country. Up until now, we've obtained data via SOAP as structured XML. Now, we need to use Drupal to do this.

I identified the following modules as possibile solutions for this task:

http://drupal.org/project/webservices
http://drupal.org/project/soapclient
http://drupal.org/project/soap_server

Our programmers will have to evaluate the suitability of these for our purposes. With my limited knowledge and just from reading the module descriptions, I'd reckon that the SOAP Client and/or SOAP Server are the match for us. A HUGE concern, obviously, is security. I'm still not completely clear on how security works with these kinds of protocols. Is it as secure or more than simply ftping files. I assume more secure but am not sure. I am reading this series on web services and security at xml.com to try and get up to speed on the security issues.

This has been the Daily Drupal for 16 July 2009. To subscribe to The Daily Drupal, use this feed.

This is the first of a series: I'm going to try to write a post every day (weekdays only - need my weekends, please!) about Drupal - "The Daily Drupal" if you will, with thoughts, issues, commentary, etc. on Drupal and specifically our Drupal project. If you want to subscribe to the Daily Drupal, here is the RSS feed. So, here goes...

Today's Daily Drupal is about theming...
Over the last few days with little to no knowledge of how to adjust or customize a Drupal theme, I was able to migrate this blog into Drupal and make simple, small tweaks to the template files and the CSS of my chosen theme. Of course, my main partner in this process was the incredibly helpful Firefox add-on, Firebug. This add-on to the Firefox browser allows one to "inspect" the code behind any element of a web page.

So, using Firebug, I was able to identify which stylesheet controlled which element in my blog and navigate, within the Drupal file structure, to the appropriate CSS and modify it. Here's what it looks like:

HTML:

CSS:

  >>>> 

I just completed the migration of my blog from wordpress.com to my very own Drupal installation. You are looking at the results. The old blog is here mavergames.wordpress.com. I think it looks quite spiffy and only took, in all honesty, about 2 days of work time to rebuild the entire site including the infrastructure in Drupal. Now, I want to play around with the features in Drupal including the Views module and other more-powerful and flexible aspects of Drupal.

The original impetus for me to make this migration was this: I submitted my blog for inclusion in Drupal Planet. Someone pointed out that it was a Wordpress blog. Then, someone else chimed in saying that there were other Wordpress blogs in Drupal Planet, so that wasn't an issue. Regardless, it got me thinking that it would be a fantastic exercise in learning Drupal to migrate this blog into the system. After all, I'm managing a project where we're migrating roughly 70 websites into Drupal! (See previous posts on this blog including: http://mavergames.net/content/more-cloud-issues).

I'm really enjoying this process by the way. Drupal is a great CMS and actually, gasp, kinda fun!