• strict warning: Non-static method view::load() should not be called statically in /home1/oestremc/public_html/dc_d6/sites/all/modules/views/views.module on line 906.
  • strict warning: Declaration of date_handler_field_multiple::pre_render() should be compatible with content_handler_field_multiple::pre_render($values) in /home1/oestremc/public_html/dc_d6/sites/all/modules/date/date/date_handler_field_multiple.inc on line 185.
  • strict warning: Declaration of views_handler_filter::options_validate() should be compatible with views_handler::options_validate($form, &$form_state) in /home1/oestremc/public_html/dc_d6/sites/all/modules/views/handlers/views_handler_filter.inc on line 607.
  • strict warning: Declaration of views_handler_filter::options_submit() should be compatible with views_handler::options_submit($form, &$form_state) in /home1/oestremc/public_html/dc_d6/sites/all/modules/views/handlers/views_handler_filter.inc on line 607.
  • strict warning: Declaration of views_plugin_style_default::options() should be compatible with views_object::options() in /home1/oestremc/public_html/dc_d6/sites/all/modules/views/plugins/views_plugin_style_default.inc on line 24.
  • strict warning: Declaration of views_plugin_row::options_validate() should be compatible with views_plugin::options_validate(&$form, &$form_state) in /home1/oestremc/public_html/dc_d6/sites/all/modules/views/plugins/views_plugin_row.inc on line 134.
  • strict warning: Declaration of views_plugin_row::options_submit() should be compatible with views_plugin::options_submit(&$form, &$form_state) in /home1/oestremc/public_html/dc_d6/sites/all/modules/views/plugins/views_plugin_row.inc on line 134.

The modernization project

General

I am finally going to go 2.0 with dylanchords. The site hasn’t changed much in 16 years, and although there is probably something cute about that, it’s not very nice to work with flat, fixed html, to be honest.

The new dylanchords will run on drupal, and the page you’re on right now is actually the real thing, in the sense that the database structure is mostly in place, and so is the interface for entering tabs and most of what is needed for displaying the information. The only thing missing is – that information. I’ve included the Blood on the Tracks tabs, just to have something interesting to play around with.

The important thing for me, and the reason I want to do this in the first place, is (a) that the process of entering tabs will be simplified, and (b) that there will be benefits concerning the presentation of the tabs (such as: quickly get a list of songs in open tunings, better search facilities, songs in G major for the beginners, etc.).

I’m prepared to do most of the work myself, but the more the merrier and quicker and – hopefully – better. Hence this call for assistance.

Procedure

The biggest change from the flat-file dylanchords is that I have decided to use “song_version” as the basic unit instead of “song”. This makes for a cleaner database, greater opportunities for queries, and easier expansion at a later stage, but also creates a lot more work, since every file has to be parsed and split up into the relevant database fields.

Luckily, I have been fairly consistent with class names etc. in the files, but unluckily, html isn’t the ideal language for this kind of job, since there is no indication where, say, a <h2> element ends (only where the tag ends).

Also luckily, there is a reasonably good conversion module in drupal, but unluckily too, it uses xlt, which is a beast.

Here’s the work I imagine will have to be done:

  1. Some automatized parsing of the files into drupal nodes, hopefully populating the correct fields.
  2. Filling the remaining fields, eiher with default values, or overlooked ones from the files
  3. Checking, manual corrections, etc.

#1 can be done through the conversion module, if I manage to get it to work properly, but I could use some assistance here. If anyone has a better alternative, e.g. to parse the song-files into a new set of song_version-files which can then be added to the database, that’s perfect too.

Once #1 is in place, #2 should be easy.

#3 will probably have to be done in any case, but will not require any special coding skills, so anyone can do it.

Database architecture

There are four main tables (content types in drupal terms):

Album

Fields:

  • title
  • release/recording date
  • cover, etc.

Song

  • Author
  • Preamble - general discussion of the song

Song version

This is where the meat is:

  • Date
  • venue
  • guitar setup (tuning, capo, chords, all as “node references”, roughly equivalent to foreign keys)
  • the tab itself.

There is also a “node reference” to the Song it is a version of.

Album_song

This is a many-to-many pivot table, containing foreign keys/node references to Album and Songversion, as well as disc/track number.

The tricky part is to get the theming right, and to get the proper fields brought into the right places.

Fixed elements

There are a number of fixed elements, such as the help file, the essays, and the integration with the blog. This is mainly a matter of plain conversion or copy/paste.

The rest - navigation, album lists, etc., will be generated dynamcially from the existing material, once it is in place.

Workflow/Theming

I’ve added the BOTT songs, just to try it out, and it seems to be working ok. There are still some rough edges here and there, but on the whole, I’m fairly happy with the results.

Here’s an overview of what I’m aiming for:

Entering tabs

There are some different scenarios here:

1. Dylan comes out with a new album.

I will then add a new album page. On this page, there are fields for the general stuff (title, release info, cover image, etc), and links to add Songs. I’ve found an architecture which makes this quite simple, whether the songs are already in the database, or they are new ones – hopefully so simple that it can be done also by someone other than me, should I decide to go that way.

Track order: would be nice with a drag-and-drop arrangement here.

One problem here is that what is added to the album is neither a Song nor a Song_Version, but an album_song, which is a combination of album and songVERSION. It makes little sense to add the songversion before there is a song to add it to, so if the song does not exist in the database yet, it is added (in a required field) while entering the song_version.

2. Dylan plays a new live version of She’s Your Lover Now.

On each Song page, there is a link to add a new version. Each song_version (whether displayed individually or in the context of the Song page) has an “Add to album” link.

3. A new outtake from Street Legal surfaces.
4. Dylan plays a cover of ABBAs Dancing Queen.
5. I add a tab to the “Other artists” seciton

I haven’t quite decided what to do in these cases. Probably some kind of tick-box system, which will let outtakes be listed as outtakes under their “original” album and as ordinary tracks under Bootleg Series, and a set of “Misc.” categories corresponding to the current “Misc.” index page.

Good ideas here are welcome.

Viewing tabs

With the song_version based system, it is quite simple to generate any kind of lists, static (album pages) or dynamic (“songs in G played live between 1978 and 1994”). The only problem so far has been to get all the back-references right, such as a list of all the albums ANY version of a song appears on, but that’s mostly because of my incompetence. That will be worked out, but someone with great database skills and/or familiarity with drupal’s views system, will be greeted with open arms.

Album page

  • tracklisting
  • list of outtakes
  • link to add song to album

Song page

  • list of versions
  • link to add song version
  • link to albums it’s on

TODO: list of albums ANY VERSION of the song is on

Song version page

  • list of other versions of same song
  • link to main song
  • list of albums the VERSION is on

TODO: What to do with outtakes.

Helpers

I have heard from a number of volunteers who are ready to go to work.

I think of you in different categories:

1. Hackers. People who can write perl scripts to parse anything and the kitchen sink and who dream in xml. Right now, the bottleneck is the bulk conversion in step #1, so help there is urgent. I’ve heard from a couple of you, and promised to get in touch after the summer vacations. Well, here we are…

2. Slaves. Unpaid labour whose only required qualifications are an unyielding loyalty to Dylan and yours truly, and unexhaustable energy, diligence, and meticulousness. Once the basic conversion is done, you will have a lot of cotton to pick.

3. Architects. People who have good ideas about workflow and presentation, both concerning what should be done and how. PHP skills and MySQL knowledge might come in handy here, and a working knowledge of drupal is a gate to dylanchords heaven (a working knowledge of Latin is a bonus, of course, but it won’t help here).

4. Guards. Spam, spam, spam, spam, spam – how to stop it and still enable a vibrant community? I’m not aiming for a new expectingrain forum or anything, but I think it would be a good idea to have a more dynamic channel for letting suggestions and corrections through, and for some sort of community interaction.

I think of myself as someone with one limb in each category, with a serious risk of loosing my grip of any of them, thus falling over.

In other words: I’m going to need you all.

I’ll provide you all with login credentials with permissions according to whichever category you feel comfortable with. If anyone wants any of

  • a mysql dump of the database,
  • a tarball of the site,
  • a zip file of the current dylanchords files

either to set up a local development environment or just to see what’s going on, I’ll provide that too.

Contact me on eyolf@oestrem.com if you’re interested, and indicate (a) which category you see yourself in, and (b) if you want any of the material.