Support from Acquia helps fund testing for Drupal Acquia logo

Comments

ericduran’s picture

Fine by me.

junedkazi’s picture

Component: Documentation » Code
Category: task » feature
Status: Active » Needs review
FileSize
1.98 KB

Based on the file on http://drupal.org/node/1633038

Status: Needs review » Needs work

The last submitted patch, fivestar-migrate_integration-1635608-2.patch, failed testing.

junedkazi’s picture

Status: Needs work » Needs review
FileSize
2.71 KB

forgot to migrate api function.

Status: Needs review » Needs work

The last submitted patch, fivestar-migrate_integration-1635608-3.patch, failed testing.

junedkazi’s picture

Version: 7.x-2.0-alpha2 » 7.x-2.x-dev
junedkazi’s picture

Status: Needs work » Needs review
jaydub’s picture

Updated patch to add hook_migrate_api() function comment.

Status: Needs review » Needs work

The last submitted patch, fivestar-migrate_integration-1635608-8.patch, failed testing.

jaydub’s picture

Status: Needs work » Needs review
FileSize
2.78 KB

Let's try again with that patch

jaydub’s picture

I'm having issues applying the patch in #4 or my own in #10 via drush make. Seems to trip up on patching fivestar.info. I'm adding another patch that appears to apply clean via directory created by drush make. Sorry for the extra posts - trying to get fivestar to pull and patch via drush make to add the migrate support.

Status: Needs review » Needs work

The last submitted patch, fivestar-migrate_integration-1635608-11.patch, failed testing.

mototribe’s picture

thanks for the patch! I applied it manually and it worked. Great stuff!!!

StuartDH’s picture

I'm using Migrate 2.5 and running #11 with WinSCP/PuTTY produces the following messages:

patching file fivestar.info
Hunk #1 FAILED at 6.
1 out of 1 hunk FAILED -- saving rejects to files fivestar.info.rej
patching file fivestar.migrate.inc
patching file fivestar.module
Hunk #1 succeeded at 159 (offset -19 lines).
patch unexpectedly ends in the middle of line
patch: **** malformed patch at line 88:

The first fail above (Hunk #1 FAILED at 6) can be easily remedied by manually adding files[] = fivestar.migrate.inc to line 9 of the fivestar.info file

However, I can't work out what's wrong with line 88 of the patch

Is it anything to do with the new way of registering classes in Migrate 2.5? - http://drupal.org/node/1824884

I've manually added the following to the bottom of the fivestar.module file

/**
 * Implements hook_migrate_api().
 */
function fivestar_migrate_api() {
  $api = array(
    'api' => 2,
  );
  return $api;
}

but using

    $this->addFieldMapping('field_rating', 'rating');

in my class doesn't seem to migrate ratings from my source db.

I'm assuming that the issue is with the above, but just in case I thought I'd add that my source db has rating out of 10, with one decimal place. As the patch requires that "Primary value passed to this field must be the rating out of 100", I assume that my fields with data of 10.0 should at least show in Fivestar as 10/100?

Any ideas how I can fix the above and multiply my existing ratings by 10? Should something like the following prepareRow do the job?

    public function prepareRow($row) {

     $row->field_rating = $row->rating * 10;

    }
mototribe’s picture

I would try that, I'm using the same to convert my ratings from 1-5 to 20-100.
Btw, I manually applied the patch against 2.2

StuartDH’s picture

Thanks for the info. I'm now trying to patch manually, but some things don't look right

The patch seems to create fivestar.migrate.inc properly. I've manually added files[] = fivestar.migrate.inc to the fivestar.info as well as adding the following to the end of the fivestar.module

/**
 * Implements hook_migrate_api().
 */
function fivestar_migrate_api() {
  $api = array(
    'api' => 2,
  );
  return $api;
}

but I don't get what's happening on lines 74/75 of the patch. There's no difference between the - and + lines of code so I can't see what needs to change.

After that, I've added the following to my migration class field mappings to get source db 'rating' field to migrate to the destination 'field_rating' field of my photo node content type

    $arguments = array(
      'target' => array('source_field' => 'rating'),
    );

    // The rating should be passed in as the primary value.
    $this->addFieldMapping('field_rating', 'rating')
         ->arguments($arguments);

    // Since the excerpt is mapped via an argument, add a null mapping so it's
    // not flagged as unmapped.
    $this->addFieldMapping(NULL, 'rating');

The above destination and source appear in the migrate UI, and MigrateFivestarHandler is listed in admin/content/migrate/handlers but the data doesn't migrate when I run a migration

mototribe’s picture

you'll need to pass in the "target" here instead of the rating:

$arguments = array(
      'target' => array('source_field' => 'rating'),
    );

The target is usually a node id.

StuartDH’s picture

Unfortunately, I still can't seem to make it work and I guess it's down to how I'm creating the mapping class.

Source
node id: id
Rating field machine name: rating

Destination
Type: node
Node machine name: photo
Node id: nid
Fivestar field machine name: field_rating
Rating field voting tag: vote

My Drupal destination db has a table: field_data_field_rating with the following columns

entity_type
bundle
deleted
entity_id
revision_id
language
delta
field_rating_rating
field_rating_target

The mappings in #16 populate field_rating_rating with the correct rating values and NULL in each record field_rating_target, but no values migrate to the votingapi_vote table and the ratings don't display when viewing nodes.

I've been trying all sorts of combinations for source, destination, node, type, field, targets etc, but really not sure what should go where. Please could you to use the above to create the right code below

   $arguments = array(
     'target' => array('source_field' => 'example_target'),
   );
   // The rating should be passed in as the primary value.
   $this->addFieldMapping('field_rating', 'user_rate')
        ->arguments($arguments);
   // Since the excerpt is mapped via an argument, add a null mapping so it's
   // not flagged as unmapped.
   $this->addFieldMapping(NULL, 'example_target');

Thanks

mikeryan’s picture

Some comments:

The arguments stuff is now deprecated, you should be using the subfield notation (since Migrate 2.4):

$this->addFieldMapping('field_rating', 'user_rate');
$this->addFieldMapping('field_rating:target', 'example_target');

Although, the arguments should still work. I haven't used fivestar in a while, hard to say why it's not working for you.

Also note that hook_migrate_api() would best go into fivestar.migrate.inc rather than fivestar.module.

The .info patch problem is that it has a version line - i.e., the patch is being done against a release rather than a git checkout of fivestar.

StuartDH’s picture

Thanks Mike

Could you tell me what's supposed to replace 'example_target' in the #19 code. Anything other than source fields results in errors like

"nid" was used as source field in the "field_rating:target" mapping but is not in list of source fields

but none of my source fields seem to work...ratings are migrating to field_data_rating, but nothing is going into the votingapi_vote table.

Could lines 74&75 of the patch be the issue?

-    votingapi_recalculate_results($entity_type, $id);    
+    votingapi_recalculate_results($entity_type, $id);
Alan D.’s picture

Re-roll using changed format.

After doing this, I have discovered that this only migrates the "Vote (on edit form)" field data. The "vote on view" field type must be dependent on the votingapi table data. D'oh

Usage example, D6 to D7 migration

    $this->addFieldMapping('field_rating', 'rating');
// This field was just NULL when testing D7 field  DB data, so I am 
// not sure on the need, worked fine without for me.
//  $this->addFieldMapping('field_rating:target', 'rating_target');
    $query = Database::getConnection('default', 'drupal6_database')
        ->select('votingapi_cache', 'c')
        ->condition('c.content_type', 'node')
        ->condition('c.content_id', $current_row->nid)
        ->condition('c.function', 'average')
        ->fields('c', array('value'));
    if ($value = $query->execute()->fetchField()) {
      $current_row->rating = $value;
      // $current_row->rating_target = integer value...
    }
Alan D.’s picture

Status: Needs work » Needs review
FileSize
1.75 KB
ziobudda’s picture

Hi, #22 is not totally useful for migrate value.

Fivestar need to write record into votingapi db table. You can import the value, but without entries in votingapi_results and votingapi_cache, it is unusable.

This is my complete() function:

public function complete($entity, stdClass $current_row) {
    //5 star
    $results = Database::getConnection('MYEXTDB')
        ->select('TABLE_ratings','m')
        ->condition('m.whr', 15)    
        ->condition('m.wid' , $current_row->id)
        ->fields('m')
        ->execute();
    dd($entity);    
    $c = 0;
    $t = 0;    
    foreach($results as $res) {
      $c++;
      $t += $res->vote * 20;
       
      $id = db_insert("votingapi_vote")
            ->fields(array(
              'entity_type' => 'node',
              'entity_id' => $entity->nid,
              'value' => $res->vote * 20,
              'value_type' => 'percent',
              'tag' => 'vote',
              'uid' => 0,
              'timestamp' => time(),
              'vote_source' => $res->ip
            ))
            ->execute();
    }
    db_insert("votingapi_cache")
      ->fields(array(
        'entity_type' => 'node',
        'entity_id' => $entity->nid,
        'value' => $c,
        'value_type' => 'percent',
        'tag' => 'vote',
        'function' => 'count',
        'timestamp' => time()
      ))
      ->execute();
      
    db_insert("votingapi_cache")
      ->fields(array(
        'entity_type' => 'node',
        'entity_id' => $entity->nid,
        'value' => $t/$c,
        'value_type' => 'percent',
        'tag' => 'vote',
        'function' => 'average',
        'timestamp' => time()
      ))
      ->execute();
  }

M.

MXT’s picture

Patch in #22 works correctly in my case and I don't need to "manually" insert values in votingapi_vote and votingapi_cache as suggested by ZioBudda in #23. These values are inserted automatically during migration within voting tables.

The only issue I have is that votes are registered 2 times inside votingapi_vote table: why?

Thank you for helping me

MXT’s picture

I've found the reason why my votes are registered 2 times: the reason is that both fivestar_field_insert() and fivestar_field_update() are executed, so votes are casted 2 times.

Temporarily disabling fivestar_field_update() during migration all works fine: votes are registered correctly only one time.

ezeedub’s picture

Status: Needs review » Reviewed & tested by the community

Works for me. Using migrate_d2d, I migrate fivestar comments like so:

class MyCommentMigration extends DrupalComment6Migration {
  public function __construct(array $arguments) {
    parent::__construct($arguments);

    // map fivestar data
    $this->addFieldMapping('field_review', 'review')
      ->description('Handled in prepareRow()');

    $this->addFieldMapping('field_review:target', 'review_target');
  }

  public function prepareRow($row) {
    if (parent::prepareRow($row) === FALSE) {
      return FALSE;
    }

    // fivestar
    // get the migrated nid (target)
    $nid = $this->handleSourceMigration('NodeWithComments', $row->nid);

    // get the rating for this comment
    $q = 'SELECT value FROM fivestar_comment WHERE cid = :cid';
    $rating = $this->connection->query($q, array(':cid' => $row->cid))->fetchField();

    // save the rating and target
    if (!empty($rating)) {
      $row->review = $rating;
      $row->review_target = $nid;
    }
  }
}

whiteph’s picture

Issue summary: View changes
Status: Reviewed & tested by the community » Fixed

Moved fivestar.migrate.inc to /includes directory, and removed it from fivestar.info as it should be found ok in the /includes directory.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.