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.
Ok, it works pretty much like it should with one exception. The language value was set to 'und' for all entries, causing them to be empty in edit node although they were visible while viewing. If updated and saved again a new row would appear in the database (so now I had one with a language value of 'und' and one with 'pl' in my case) which in turn caused views to display duplicated results. I removed the duplicates and updated all rows to 'pl' manually fixing the problem, now all nodes can be edited with no problem. I believe this should be fixed so the language column gets filled properly.
Comment | File | Size | Author |
---|
Comments
Comment #1
KarenS CreditAttribution: KarenS commentedThe und part of the field is totally new in D7. How could you have migrated data with any value in the field other than the default?
I have not had time to try to understand how that new code works and don't have a site that uses translations to test on, so I don't know what, if any, changes need to be made.
Comment #2
gnite CreditAttribution: gnite commentedOk so I did a quick test - installed D6.20 in english with cck, created a field, upgraded to D7, migrated field and the above mentioned problem did in fact not exist. I noticed that there was no table 'languages' as I have on D6.20 with an additional language. Here is a screenshot of that table http://pliki.gnite.pl/lang_d6.png. If it were possible to check for that table and if present copy the 'prefix' of the 'enabled'=1 language into the 'language' field of D7's fields that should solve the problem. I also found a post from someone french having the same issue I had.
Comment #3
gnite CreditAttribution: gnite commentedComment #4
KarenS CreditAttribution: KarenS commentedIt is not at all clear to me what the problem is that we are trying to fix. You described a problem in the beginning of the issue, then in #2 you say that problem did not exist. So what exactly, *does* happen with the current code?
Comment #5
gnite CreditAttribution: gnite commentedI'll try to explain better. In my second post i said the issue does not exist when NOT using additional languages, i.e. when installing just the original english. However if using another language the story is the following:
- the fields display fine while viewing nodes
- going to edit node and all the fields are blank, no values are shown here, like creating a new node
- entering them again and saving
- now they show both en view and edit, however
- now there are two entries in the database for that particular field in that particular node, basically there are duplicates one having the language 'und' and one having 'pl' in my case since I'm using polish
- that i turn causes the views module to return duplicated results for nodes that have those duplicated field entries
- manually replacing all und's with pl's solved the problem, now all the values show up in edit like they should without reentering them
conclusion: if not using english the language of the field needs to be set to the one in use.
One exception I found are image field which needed to remain 'und' to function, all the others were malfunctioning with 'und'.
Comment #6
KarenS CreditAttribution: KarenS commentedSomeone using translations needs to provide a patch that works for translations and I can confirm it works for sites that do not use translations.
Comment #7
FrequenceBanane CreditAttribution: FrequenceBanane commentedsubscribe
Comment #8
cpelham CreditAttribution: cpelham commentedHere are two more instances of the problem, so I am somewhat confident now that there is a problem and that we have correctly diagnosed it:
http://drupal.org/node/1122062
Comment #9
cpelham CreditAttribution: cpelham commentedMy sites use two languages so I cannot just write a sql command to replace all the "und" with "en" or another language. Some fields should be one language and some should be another, and since there can be thousands of fields, this needs to be correctly set programmatically during the conversion.
We first need to check for the language setting of the node to which the Drupal6 cck field is attached. I take it we would get the relevant node from the cck field row's nid column? Then we would query the row of i18n_node (if it's a node in question) with that nid and get the value from the language column? And finally we would write that language value to the corresponding language column in the new Drupal 7 field table?
I am only a novice programmer and I'm not sure where this should occur. In content_migrate.text.inc ?
I could possibly try writing the code to do that but it sounds not too difficult (if one knows what one is doing) and probably someone MUCH more qualified here could do it? I would be happy to test a patch if someone else could write one. If no one does soon, probably I'll try to figure it out...
Comment #10
cpelham CreditAttribution: cpelham commentedOK, i just tried changing all the language column values in one field table to "en" even though half the nodes are in another language to see if that might fix the problem anyway. The result is that for some of the nodes, the field contents display correctly on the node edit screen and for other node the field contents still do not get displayed. I don't yet see a reason for the disparity...
I believe that programming the patch is beyond my present capabilities. There must be thousands of multi-lingual sites out there that would like to upgrade to Drupal 7. Can no one step in and write this patch?
Comment #11
cpelham CreditAttribution: cpelham commentedCan this be accomplished by writing a mysql query directly in phpmyadmin? Here's what I have (for correcting one field for one language) but the syntax is wrong. Can someone correct it?
select nid, language from i18n_node;
if (i18n_node language = ja)
then
update field_data_field_instructor_or_artist set language = replace(language, 'und','ja') where field_data_field_instructor_or_artist nid = i18n_node nid
Comment #12
cpelham CreditAttribution: cpelham commentedEven with the language column set to 'en' and with tonight's latest dev versions of ctools, views, date, and calendar (and running update and emptying cache tables),
if i make a fresh (reverted) calendar view and then change the argument from posted date (which works correctly) to my date field which was upgraded via migrate content from D6 to D7, i get the following error:
SQLSTATE[42000]: Syntax error or access violation: 1064 You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'AS field_data_field_event_cck_date_2_ FROM node node LEFT JOIN field_data_field' at line 1
The query is:
SELECT node.title AS node_title, node.nid AS nid, node.language AS node_language, node.changed AS node_changed, field_data_field_event_cck_date_2.field_event_cck_date_2_value AS field_data_field_event_cck_date_2_field_event_cck_date_2_val, field_data_field_event_cck_date_2.field_event_cck_date_2_value2 AS field_data_field_event_cck_date_2_field_event_cck_date_2_val_1, field_data_field_event_cck_date_2. AS field_data_field_event_cck_date_2_
FROM
{node} node
LEFT JOIN {field_data_field_event_cck_date_2} field_data_field_event_cck_date_2 ON node.nid = field_data_field_event_cck_date_2.entity_id AND (field_data_field_event_cck_date_2.entity_type = :views_join_condition_0 AND field_data_field_event_cck_date_2.deleted = :views_join_condition_1)
WHERE (( (node.status = '1') AND (node.type IN ('event_cck')) )AND( (DATE_FORMAT(STR_TO_DATE(field_data_field_event_cck_date_2.field_event_cck_date_2_value, '%Y-%m-%dT%T'), '%Y-%m') = '2011-04') ))
LIMIT 10 OFFSET 0
The exported view is:
Comment #13
KarenS CreditAttribution: KarenS commentedDid some digging into this and it looks like the following happens on a fresh D7 install, so this is what we have to match:
1) If you do not have the Content Translation module enabled, all fields you create have a value of 'und' for the language.
2) If you enable the Content Translation module after you already have some fields created, all fields that previously used 'und' STILL have 'und'. All new fields you create will default to your site language.
I haven't tried an upgrade from a site that used translation in D6 to see if that does anything differently. And I don't know how we determine which is the right value to use in the migration.
Comment #14
cpelham CreditAttribution: cpelham commentedI believe we would want to set each field row's language value to equal the language value of the corresponding i18n_node table row. I am not sure how node revisions might affect this though, if at all.
Comment #15
cpelham CreditAttribution: cpelham commentedI cross-posted this to i18n, and Jose replied that CCK should take care of this and not i18n:
http://drupal.org/node/1072082#comment-4414250
Posted by Jose Reyero on May 1, 2011 at 1:43pm new
About node/fields language, I think cck should do the same as core upgrade scripts, which is setting the field language to the node language.
Comment #16
KarenS CreditAttribution: KarenS commentedI committed a fix for this -- I added the language to the array of node values we retrieve and then populate the new field with that value.
This needs to be tested by someone with a multilingual site.
Comment #17
KarenS CreditAttribution: KarenS commentedActually I'm going to mark it fixed because as far as I can see it will behave properly. If someone with a multi-lingual site finds it does not, I'll need more information about exactly what did not end up correct.
Comment #18
blackdog CreditAttribution: blackdog commentedAs stated in #5:
This is an issue, see my issue: #1159862: Images in image fields doesn't show up after migrating
Comment #19
blackdog CreditAttribution: blackdog commentedThis is also true for node reference fields it seems.
Comment #20
cpelham CreditAttribution: cpelham commentedI have found that another route to go with upgrading that is more work but potentially much cleaner is to make a new D7 site and then export your D6 nodes as CSV (or get them into CSV) and then create the content types anew in D7 and then import the data in using Feeds. Feeds appears to do a good job of creating nodes correctly. I haven't tested this workflow extensively yet but so far so good.
Comment #21
KarenS CreditAttribution: KarenS commented@cpelham, if someone has hundreds of fields to create, that will be a time-consuming process. And not everyone wants to have to install and configure feeds (which is sometimes not for the faint of heart) to get their data migrated. But yes, we should note alternative ways to approach the problem.
@blackdog, do you have a multilingual site? That is what needs to be tested.
Comment #22
KarenS CreditAttribution: KarenS commentedReading the other issue, blackdog has a non-multilingual, non-US site.
We may need to add a switch to add the language only for a multi-lingual site, or only on certain fields, but I have no idea which modules/fields alter the language value, and when. Really really need assistance from someone who understands how all this works.
Comment #23
KarenS CreditAttribution: KarenS commentedOK, more digging into this. If I Content Migrate creates fields without explicitly setting a the 'translatable' flag, they will get set to translatable = FALSE; If you create a field in the UI, it will always get set to 'translatable' = TRUE (there is no way to override that that I can see). If you use languages and the field is translatable, the field language will get set to whatever language. If the field is not translatable the language should get set to 'und'.
So the image and nodereference fields got created as non-translatable, and they want the 'und' value instead of the language.
There is a lot of inconsistency around how all this is handled in core. I need to figure out the right way to handle the migration.
Comment #24
KarenS CreditAttribution: KarenS commentedI created a core issue at #1164852: Inconsistencies in field language handling. There are definitely some core problems making this worse than it needs to be.
Comment #25
clemens.tolboomSubscribe and XRef (committed to drupal-7.x-dev May 18).
Comment #26
KarenS CreditAttribution: KarenS commentedI have no idea with #25 has to do with this issue.
Based on the comments at #1164852: Inconsistencies in field language handling, I think I should revert my earlier change and set all migrated data to 'und', regardless of the language of the node. That is what I started out doing and I have lost track now of what problems that created. Anyone who has a problem with that course of action should jump onto that core issue and make yourself heard. I am going to do whatever they tell me to do there.