Drupal 7 version / migration path

Yes, but my time is very limited as I'm away for 7 or so months on holiday before resetting up a house, job, etc from scratch.

Patches or co-maintainers welcome!

It may also pay to track these projects as well.

http://drupal.org/project/fieldentity
http://drupal.org/project/combofield

Dependent on #942310: Field form cannot be attached more than once

Subscrive

sub

subscribe

subscribing too

It doesn't solve the issue, but I found another solution : I used field-collection module, created a field-collection with an image-field, and a long text field.
The field collection items (image + txt) can be then used in Views, like images+description.

I could use this solution with views-slideshow module, it works perfectly, and can even be extended with more txt fields, attached files etc.. 'related' to the image because they are in the same field-collection...

Hope this can help :)

-P-

Would you say that this solution is as good or better than the existing functionality of this module? If so, then this issue will become about a migration strategy and not a upgrade path!

For my situation it is as good or better, because I start to be used to work with field-collection and views, and i often have to attach various informations, files etc.. to images and diaporamas.
In another hand I think imagefield-extended module provide a more easy way to add a simple description field wich can use a wysiwyg editor. And in my experience, this is a very common feature graphic-designers request for theming images descriptions...

The field-collection solution seems to work great, but it's not an obvious way for the new drupalers :)

It's maybe something that should go in core sometime : a txt-area description field for images, allowing use of html and wysiwyg editor..
What do you think ?

I think that the core developers will want to keep core fairly clean, adding a rich text area automatically means that there is at least one more configuration setting and one more db column.

Hi Alan

There is another issue about the image description field and drupal 7&8 here : http://drupal.org/node/1067620

regards
P.

There is an interesting new module File Entity, http://drupal.org/project/file_entity. This looks like a very promising replacement. Any feed back from users about this one?

There are multiple contenders that provide this functionality in Drupal 7, so I am officially calling the end of the road for this module (File entities and field collections come to mind). Sorry.

ok i can understand that there are alternatives to this module in drupal 7 but we just found out that since the extended fields are serialized the data is lost in the upgrade to drupal 7. How do we migrate this data to another solution on drupal 6 before we upgrade to drupal 7?

data is lost in the upgrade to drupal 7

The file fields data column should still be there, it is just not accessible. (Well that is what is meant to happen anyway).

I am still waiting for File Entity to take the place of this module, although I have a sandbox project that could potentially be the successor. There is no upgrade path, as we have yet to require this at work.

From what my engineers told me is that data is lost because the image field extended info is stored in a serialized field under drupal 6 but under drupal 7 there are dedicated database fields for each of the meta data that drupal 7 image fields support. So it is my understanding that the serialized fields are unserialized and any values not used by drupal 7 are just discarded. This includes the description field which is in drupal 6 image field and which we use extensively for captions is just ignored for drupal 7 and not migrated.

My understanding was that the table itself was not deleted. We have done Drupal 5 to 7 migrations, but none from 6 to 7 yet so I can not track this myself atm.

@Alan D is correct, when doing an upgrade from D6 to D7, all the original tables are kept intact. Since the table names are completely different in D6, having the old data around doesn't hurt anything. HOWEVER, Field Convert module (the only module in CCK in D7), has an option to delete the tables when you're done upgrading. At the same time, it warns you a couple of times that you're about to destroy data before you actually delete the old tables and it requires explicit action. So for other users out there, you shouldn't need to worry about the data being lost, however there is yet a suitable replacement in D7. File Entities does seem like the best bet, though it's far from polished.

@quicksketch Thanks for the confirmation of my suspicions!

A general update on things.

I still feel like neither File Entity / Field Collections are a good substitute for this module, but I'm not overly happy with the current implementation of File Attributes either.

If I somehow manage to get some time, (about third down on the list of my priorities in contrib and too much paid work atm), I want to change File Attributes to have a more fluid attribute selection, moving all individual field data be atomic instances, and simply assigning these to field group types. So all display / form settings per field will be the same. Fields within each group would have their visibility toggled via states.

This field / grouping may sound a bit strange, but this grouping allows you to use a single image field as; a poor-mans U-Tube embedded service; an image map; a captioned image (all via Insert module); a custom fields for views, etc, and the group selection hides or shows the fields that you need. I have already used this as such on 4 projects. It feels promising, but needs lots of work. Only once I happy with this will I work on the upgrade path and publish. ETA, completely unknown and secretly hoping that File Entity can fill the gap.

I'm working on a D7 module to extend File Entity, making the entire flexibility of the Field API accessible to files in an inline form. http://drupal.org/sandbox/quicksketch/1797528

Considering I've got projects using ImageField Extended, I'll work on including an upgrade path for ImageField Extended users to file entities, though I don't have any idea how difficult that will be. So no promises, but maybe some hope. :)

Not generally useful to the wider public, but this is how I managed the ImageField Attributes migration to File Attributes (don't use this module, it was written when File Entity was completely unstable and File Entity Inline didn't exist). This was a true migration from a D6 site to another D7 rather than an upgrade.

Copy and rename MigrateFileUri to:

class MigrateImageFieldExtendedToFileAttributes extends MigrateFile {

  // We only had these two fields in general use.
  protected $ife_description = '';
  protected $ife_author = '';
  // This was for our target D7 field.
  protected $ife_entity_type = '';
  protected $ife_bundle = '';
  protected $ife_field_name = '';

  public function __construct($arguments = array(), $default_file = NULL) {
    parent::__construct($arguments, $default_file);
    if (isset($arguments['source_dir'])) {
      $this->sourceDir = rtrim($arguments['source_dir'], "/\\");
    }
    if (isset($arguments['ife_author'])) {
      $this->ife_author = trim($arguments['ife_author']);
    }
    if (isset($arguments['ife_description'])) {
      $this->ife_description = trim($arguments['ife_description']);
    }
    if (isset($arguments['ife_fieldinfo'])) {
      list($this->ife_entity_type, $this->ife_bundle, $this->ife_field_name) = explode(':', $arguments['ife_fieldinfo']);
    }
  }
  static public function fields() {
    return parent::fields() +
      array(
        'source_dir' => t('Subfield: <a href="@doc">Path to source file.</a>',
          array('@doc' => 'http://drupal.org/node/1540106#source_dir')),
        'ife_fieldinfo' => t('Subfield: Destination entity type, bundle and field name (REQUIRED)'),
        'ife_description' => t('Subfield: IFE Image Description'),
        'ife_author' => t('Subfield: IFE Image Author'),
      );
  }

  // Only overridden as rawurlencode() caused copy() to fail.
  protected function copyFile($destination) {
    // Perform the copy operation, with a cleaned-up path.
    $basename = basename($this->sourcePath);
    $prefix = substr($this->sourcePath, 0, strlen($this->sourcePath) - strlen($basename));
    $this->sourcePath = $prefix . $basename; 
    if (!@copy($this->sourcePath, $destination)) {
      throw new MigrateException(t('The specified file %file could not be copied to ' .
        '%destination.',
        array('%file' => $this->sourcePath, '%destination' => $destination)));
    }
    else {
      return TRUE;
    }
  }
  // Copy and paste, then add a line below every file_save().
  public function processFile($value, $owner) {
    ...
    $file = file_save($file);
    $this->updateFileAttributes($file);
  }
  /**
   * Saves a files component profile data.
   */
  function updateFileAttributes($item) {
    if (empty($item->fid)) {
      return;
    }
    ... insert whatever here to update the File entity.
  }
}

// and in the Migrate class constr4uctor
    // Image delta 0 (or flagged) > Featured Image
    $this->addFieldMapping('field_featured_image', 'field_featured_image__filename');
    $this->addFieldMapping('field_featured_image:source_dir')->defaultValue(variable_get('htmigrate_file_path', ''));
    $this->addFieldMapping('field_featured_image:alt', 'field_featured_image__alt');
    $this->addFieldMapping('field_featured_image:title', 'field_featured_image__title');
    // Our magic to get the imagefield extended properties into file attributes.
    $this->addFieldMapping('field_featured_image:file_class')
        ->defaultValue('MigrateImageFieldExtendedToFileAttributes');
    $this->addFieldMapping('field_featured_image:ife_description', 'field_featured_image__short_caption');
    $this->addFieldMapping('field_featured_image:ife_author', 'field_featured_image__photographer');
    // We need this info that appears to be missing.
    $this->addFieldMapping('field_featured_image:ife_fieldinfo')->defaultValue('node:fact_sheet:field_featured_image');

Mostly likely Drupal 7 replacement for this module

Just in case anyone is interested: I'm trying to migrate Imagefield Extended values in D6 to File Entity values in D7. I'm having a hard time with Entity Metadata Wrappers, though:

https://drupal.stackexchange.com/questions/144466/change-values-of-neste...

Here is a script that seems to work for me to migrate data from imagefield extended (D6) to fields with File entity and File entity inline (D7). Before running the script, I migrated the imagefields using the CCK migration module and created two fields - one for an image source and one for an image license. Before (in D6), I had created those two fields in imagefield extended. My fields are called field_bild (the imagefield), field_source, and field_license.

I ran the script using drush: drush scr /path/to/script/name-of-script.php

// Get nids of all nodes that have an image and write them into an array.
$result = db_query('SELECT DISTINCT nid FROM {content_field_bild} WHERE field_bild_fid IS NOT NULL ORDER BY nid ASC');
$nids = array();
foreach ($result as $record) {
  $nids[] = $record->nid;
}
print '
Found ' . count($nids) . ' Nodes with images.

';

// Update image information.
foreach ($nids as $nid) {
  print 'Node: ' . $nid . ' (Images:';
  $node_wrapper = entity_metadata_wrapper('node', $nid);

  for ($i = 0; $i < count($node_wrapper->field_bild->value()); $i++) {

    // Get source and license information from imagefield extended.
    $fid = $node_wrapper->field_bild[$i]->file->fid->value();
    $result = db_query('SELECT field_bild_data FROM {content_field_bild} WHERE field_bild_fid = :fid', array(':fid' => $fid));
    print ' ' . $fid;

    foreach ($result as $record) {
      $data = unserialize($record->field_bild_data);
    }

    // Write information into fields.
    $node_wrapper->field_bild[$i]->file->field_source->set($data['source']['body']);
    $node_wrapper->field_bild[$i]->file->field_license->set($data['license']['body']);

    // Save file entity.
    $node_wrapper->field_bild[$i]->file->save();
  }
  print ')
';
}

Closed because Drupal 6 is no longer supported.