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.
Presently it's not possible to import content into poll nodes. It's possible to import the node title and body, etc, but not the poll options. There's two issues, as I see it, hindering this:
- In most cmses, I assume, poll options are stored in a separate table from the main poll content. Even if I were to modify the main imported poll table view, the migrate tool can not handle more than one row in the view for one piece of content.
- The UI prevents it - there's no option when mapping sources to destinations for the poll options! So even if I only had one row per poll node, I still couldn't import the poll options
Comment | File | Size | Author |
---|---|---|---|
#14 | polls-519906-14.patch | 1.33 KB | helmo |
#11 | polls-519906-11.patch | 5.4 KB | mikeryan |
#7 | 519906.patch | 2.24 KB | stella |
#5 | 519906.patch | 2.58 KB | stella |
Comments
Comment #1
mikeryanThis should be implemented with a new poll.inc file in migrate/modules/core.
Comment #2
stella CreditAttribution: stella commentedI still was unsure how to implement this in the migrate module itself, but I was able to do what I needed to using the prepare_node and complete_node hooks. I did up a quick blog post on it at http://www.stellapower.net/blog/migrate-module-migrating-poll-nodes in case anyone is interested.
Cheers,
Stella
Comment #3
mikeryanComment #4
stella CreditAttribution: stella commentedI need this again now but for 7.x-2.x and so my previous code doesn't work with migrate v2. Again I can't map the poll status, the choices or the associated votes. I'm happy to work on this but think I need a bit of a pointer as to where to start.
Comment #5
stella CreditAttribution: stella commentedOk here's a patch that works for me, but may need some refinement.
I've created a new destination handler: plugins/destination/poll.inc In it I define my extra fields. All, bar the "votes" one, are automatically saved when the node is saved. However, because of an access check in poll_insert() 2 values (active and chvotes summary) are lost on the insert as it seems to be happening as user 0 - I didn't know how to overcome this, other than by doing a couple of db_updates in complete() :(
The "votes" field is a custom one and inserts the actual votes into the poll_vote table.
Another area in need of improvement is that these poll destination fields now appear on every node type destination. Really it should be restricted to just poll nodes, but wasn't sure how to best implement that.
Comment #6
moshe weitzman CreditAttribution: moshe weitzman commentedyou can run a drush command as any user with the --user global option. for more info, run `drush topic` and pick the first topic. in this case --user=1 would solve it.
in a case like this where you really have to set that option for the command to do anything, you can just switch to user 1 in using global $user. see http://drupal.org/node/218104
Comment #7
stella CreditAttribution: stella commentedYeah I did think of using global $user but wasn't sure what function that should happen in. Ideally I'd like it to happen in the plugin itself so we wouldn't have to rely on users having to remember to implement it in their migration routine.
Attached is another version of the patch (which still doesn't address that) but which stops the complete() routine from interfering with non-poll nodes.
Comment #8
mikeryan$this->registerTypes(array('node')); would narrow things down a bit before any handler methods get called.
The fields method does take two arguments: fields($entity_type, $bundle) - so, you can test $bundle=='poll'.
$row->active should be $entity->active, no? A general prepare() or complete() handler can't make any assumptions about what's in $row.
Not to be too demanding:-), but a simple poll migration example in wine.inc would be great. I haven't used the core poll module in ages, don't have time tonight (or this week at least) to construct an example to test with...
Thanks!
Comment #9
alanburke CreditAttribution: alanburke commentedSubscribe
Comment #10
ijf8090 CreditAttribution: ijf8090 commentedSubscribe
Comment #11
mikeryanOK, I've finally got some poll data to work with on my current project. Here's an updated patch, with a few tweaks plus documentation...
Comment #12
mikeryanCommitted to D7.
Comment #13
Fidelix CreditAttribution: Fidelix commentedThank you for the nice work.
To avoid notices on the message log, you might want to change:
to
Here is a full example for migrating polls from D6 to D7 for those looking for one:
Comment #14
helmo CreditAttribution: helmo commentedThe example committed in #12 contained some obvious syntax errors.
Even though it's a comment the php syntax should still be valid.
Comment #15
mikeryanCommitted, thanks.
Comment #16
helmo CreditAttribution: helmo commented@mikeryan: not to be picky but you've committed only two thirds of the patch.
PS: I've added an extended example top your 'Drupal-to-Drupal data migration' sandbox project queue: #1763860: Poll example
Comment #17
mixhael CreditAttribution: mixhael commentedFidelix, I am struggling to make your code work. I am close, but there are some problems:
When I start running the migration (via drush mi Poll) no errors are given, but it takes ages and still didn't stop. So I cancelled the process and checked the status in Migrate UI. I saw that three (of the 15) polls were imported and that it was still busy the other 12. There were over 25000 messages that said this:
So it seems it is looping somewhere.
The three polls that were imported looked good though.
I am using the following code:
Any clue how to fix this?
Comment #18
Fidelix CreditAttribution: Fidelix commentedmixhael, have you applied the changes I suggested on #13?
Comment #19
mixhael CreditAttribution: mixhael commentedI guess you are referring to
I thought my problem was related to this, but the working example you provided in the same post (#13, on which I based my code too) did not contain the exact code. Thus I am not sure where to apply the check if $vote['chid] is set...
Comment #20
Fidelix CreditAttribution: Fidelix commentedThis is on the file poll.inc
Comment #21
mixhael CreditAttribution: mixhael commentedYes, so I just noticed. I had difficulties getting the example in poll.inc to work, as it contained a lot of php syntax errors (for instance: opening bracket for preparerow function). In the end I gave up and tried your example in #13 as it looked more clean and syntactically correct. So far it worked, except for the problem described above. Any tip on where to apply the check in this particular example?
Comment #22
Fidelix CreditAttribution: Fidelix commentedmixhael, edit the file in plugins/destinations/poll.inc.
Find
Replace with
It can't get any easier than this.
Comment #23
mixhael CreditAttribution: mixhael commentedExcuses, I was totally looking in the wrong spot. Tnx alot!
Comment #24
mixhael CreditAttribution: mixhael commentedI've passed the loop now, tnx to the fix, but still not managed to get the poll import working:
My code is based upon the example in #13 of this thread. I tried to modify the relevant piece of code from
To
But that doesn't help.
Comment #25
Fidelix CreditAttribution: Fidelix commentedThis is not a problem with migrate.
SQLSTATE[HY000]: General error: 1366 Incorrect integer value: '' for column 'chid' at row 1: INSERT INTO {poll_vote} (chid, nid, uid, hostname,[error]
You have to deal with your source / destination data properly (chid has incorrect values, it needs to be an integer).
You need to open a new issue since you have a support problem and this issue is for a feature request.
Comment #26
mixhael CreditAttribution: mixhael commentedExcuses for that. Will do and thanks for your time!
Comment #27
pifagor