{tech}.Ben Buckman.net

I have an Embedded Media youtube video field shared across multiple content types on a site, and nodequeues for the administrators to pick from these videos and feature them on various landing pages. The designs call for the videos to be different sizes on different pages - sometimes the standard 425px, sometimes 300px, sometimes widescreen 600px. When I saw the designs, I thought "I'm sure that's easy to do," and gave my approval. I'm implementing each "featured video" using a view that pulls from the respective nodequeue and displays the video as a field.

Well... I've spent hours trying to crack this nut, and my conclusion is that it's nearly impossible to do in a clean way. By clean I mean, I want to specify per view what size the video should appear. I can't set it per content type (using the backend UI) because the videos come from many content types, and if I set it by URL, there could be other videos on those pages that don't need special formatting. The settings for the field in Views only have Full and Preview, not custom sizes.

The logical approach seemed to be a hook_views_pre_render like so:
$view->field['field_video_youtube_embed']->content_field['widget']['video_width'] = 300;

That didn't work (still came out 425px), so I decided to go down an academic rabbit hole to figure out why...

The problem seems to arise with the generic content_handler_field::render() class that the field is rendered through. The object has a perfectly good $this->content_field array, which includes my modified width/height. But the function finds it necessary for some reason to get a fresh field array,
$field = content_fields($this->content_field['field_name'], $values->{$this->aliases['type']});
so the parameters are all reset. Why??

I'll just use a fields preprocessor to re-render the field. Should have done that to begin with; this study was intellectually fascinating (in a sad way) but otherwise a huge waste of time.

I've been using Subversion for years and it's high time to switch to Git. So I finally got moving on that last night, starting with various non-site projects like my contributed Drupal modules.

So far:

• Set up an account at GitHub (I've been hosting my own SVN repo and don't want to bother with that anymore; besides, GitHub offers so much more than code repositories.)
• Install Git for Mac package.
• Install SVN2Git.
• On my server, backup my SVN repo with tar (in case I lose some critical files or file history in the process).

My projects are all in subdirectories of one SVN repo, but in Git they're supposed to be separate. For each project in SVN:

• Create a repo in Github
• Create a holder for the new repository locally: mkdir PROJECT
• Initialize a repository in that directory: git init
• Import from SVN: svn2git https://path/to/svn/dir --rootistrunk
• Connect the local repo to the Github repo: git remote add origin git@github.com:USERNAME/PROJECT.git
• Push/sync it: git push origin master

In some cases I was pulling the SVN directories via svn:externals into other sites. So as a stopgap, I switched the external URL to GitHub's read-only SVN access, and it moved over seamlessly.

SVN2Git imports the entire history of the files, including trunk/tags/branches if applicable (in this case the --rootistrunk flag indicates a flat structure), so I could then delete the files from my SVN repo.

Next steps: * Read Pro Git (free) and other Git resources I've collected. * Learn how to establish a Git-centric development/Drupal workflow. * Start moving whole sites from SVN to Git.

For anyone interested, the code for my Drupal modules and other code I'll release publicly over time will live at http://github.com/newleafdigital. (Unfortunately for now, contributed Drupal modules still have to be copied to CVS, but that's moving to Git eventually as well.)

Drupal has an inconsistent data structure for CCK fields: if a field is only in one content type, it's stored in a content_type_XX table as a column, but if it's shared across multiple content types, it moves to its own content_field_XX column. Views figures out where fields are located automatically, but in custom SQL queries, this can be a real pain - you can write a query that works one day, then share a field, and the query breaks.

I asked for a solution to this on IRC and was pointed to this post by drewish, Correctly accessing CCK fields in SQL queries. I adapted that method a little to create this helper function:

/**
 * function to get the TABLE or COLUMN for a CCK FIELD
 * method adapted from http://drewish.com/content/2010/06/correctly_accessing_cck_fields_in_sql_queries
 *
 * @param $field_name
 * @param $type 'table' or 'column'
 *
 * to get both table and column, run function twice with each $type
 */
function helper_cck_field_sql($field_name, $type) {
  $field = content_fields($field_name);
  $db_info = content_database_info($field);
 
  if ($type == 'table' && isset($db_info['table'])) {
    return $db_info['table'];
  }
  elseif ($type == 'column' && isset($db_info['columns']['value']['column'])) {
    return $db_info['columns']['value']['column'];
  }
  return NULL;
}

I spent a long time today trying to figure out how to customize a Date field in Drupal 6. The field is called field_recurring_dates and looked like this:

I wanted the "To" date to only show the time, no date - so the field has Date, Start Time, and End Time. The field is repeating/"unlimited" so the whole unit gets returned via AHAH with the "Add Another Item" button. Renaming that to "Add another day" was easy, but getting the date/time fields to change was elusive. I tried everything else I could think of: #process, theme overrides for every element, preprocess, with no luck. The field is generated by a hook_elements inside the Date module, and I couldn't find the equivalent of a hook_elements_alter ... until I asked on IRC and got the perfect solution from Fox: the Form API's #after_build callback.

So here's the code, finally working, inside a custom module:

function MODULE_form_alter(&$form, $form_state, $form_id) {
  // work on initial node form and AHAH-generated partial form
  if ($form['#id'] == 'node-form' || $form_id == 'content_add_more_js') {
    if (isset($form['field_recurring_dates'])) {
      $form['field_recurring_dates']['#after_build'][] = 'custom_date_combo_after_build';
    }
 
    // rename the 'Add' button
    if (isset($form['field_recurring_dates']['field_recurring_dates_add_more'])) {
      $form['field_recurring_dates']['field_recurring_dates_add_more']['#value'] = 'Add Another Day';
    }
 
  }
}
 
function custom_date_combo_after_build(&$element) {
  // can be MULTIPLE items
  // need to find all the NUMERICALLY-KEYED elements
  foreach($element as $key => &$field) {
    if (is_numeric($key) && is_array($field) && isset($field['value']) && isset($field['value2'])) {
      // remove the Date part of 'To Date's
      unset($field['value2']['date']);
 
      // rename 'From Date' => 'Date'
      $field['value']['#title'] = 'Date';
 
      $field['value']['time']['#title'] = 'From Time';
      $field['value2']['time']['#title'] = 'To Time';
 
      // remove 'To date' block title
      $field['value2']['#title'] = '';
 
      // only need helper text outside whole group
      unset($field['#fieldset_description']);   
    }
  }
  return $element;
}

With a little CSS, it now looks like this:

Perfect!

Update and Correction: The above line,
unset($field['value2']['date']);
didn't work, because the missing 2nd date field messed up the field's validation.

So I checked out the Date Single Day module mentioned in the comments, and it's pretty much identical to this method except for this change:
$field['value2']['date']['#type'] = 'hidden';   // not unset()!

That seems to work well.
As a side note, I tried the #date_format attribute mentioned in the comments and couldn't get that to work at all. Also the first and second dates aren't separated in the form array enough to set a different #date_format on each. So #after_build seems to be the best bet.