Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
I created support for the migrate module with the fivestar module.
If they don't include it in the migrate module, it'd be useful for the fivestar module.
Comments
Comment #1
ericduran CreditAttribution: ericduran commentedFine by me.
Comment #2
junedkazi CreditAttribution: junedkazi commentedBased on the file on http://drupal.org/node/1633038
Comment #4
junedkazi CreditAttribution: junedkazi commentedforgot to migrate api function.
Comment #6
junedkazi CreditAttribution: junedkazi commentedComment #7
junedkazi CreditAttribution: junedkazi commented#4: fivestar-migrate_integration-1635608-3.patch queued for re-testing.
Comment #8
jaydub CreditAttribution: jaydub commentedUpdated patch to add hook_migrate_api() function comment.
Comment #10
jaydub CreditAttribution: jaydub commentedLet's try again with that patch
Comment #11
jaydub CreditAttribution: jaydub commentedI'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.
Comment #13
mototribe CreditAttribution: mototribe commentedthanks for the patch! I applied it manually and it worked. Great stuff!!!
Comment #14
StuartDH CreditAttribution: StuartDH commentedI'm using Migrate 2.5 and running #11 with WinSCP/PuTTY produces the following messages:
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 fileHowever, 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
but using
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?
Comment #15
mototribe CreditAttribution: mototribe commentedI 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
Comment #16
StuartDH CreditAttribution: StuartDH commentedThanks 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.modulebut 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
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
Comment #17
mototribe CreditAttribution: mototribe commentedyou'll need to pass in the "target" here instead of the rating:
The target is usually a node id.
Comment #18
StuartDH CreditAttribution: StuartDH commentedUnfortunately, 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
Thanks
Comment #19
mikeryanSome comments:
The arguments stuff is now deprecated, you should be using the subfield notation (since Migrate 2.4):
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.
Comment #20
StuartDH CreditAttribution: StuartDH commentedThanks 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
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?
Comment #21
Alan D. CreditAttribution: Alan D. commentedRe-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
Comment #22
Alan D. CreditAttribution: Alan D. commentedComment #23
ziobudda CreditAttribution: ziobudda commentedHi, #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:
M.
Comment #24
MXTPatch 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
Comment #25
MXTI'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.
Comment #26
ezeedub CreditAttribution: ezeedub commentedWorks for me. Using migrate_d2d, I migrate fivestar comments like so:
Comment #27
whiteph CreditAttribution: whiteph commentedMoved fivestar.migrate.inc to /includes directory, and removed it from fivestar.info as it should be found ok in the /includes directory.