DATA-LOSS: Changing the Language of a node via language assignment deletes the content on the edit page

The same happened to mee too :(

The same happened to mee too . So, I can not edit switched to other language content.

Thanks for your patience y'all, and sorry for the trouble. This is a pretty major bug. I haven't had time to look at it before now, but I'm looking it now and I see the problem. I should have a fix ready within the next day.

I just committed a fix for this bug. In my testing it works. Those of you who've observed this problem, please also test the fix and let me know if it works for you. To test it:

1. Install the next 7.x-1.x-dev release when it becomes available (within the next 12 hours), or, if you prefer, apply the patch.
2. Clear your site's cache ("Clear all caches" at admin/config/development/performance).
3. Go to admin/content, select some nodes, and change their languages.
4. Edit the nodes, and check that their content is still present in the edit block.

This bug doesn't occur in D6.

Marking fixed; please let me know if you think otherwise. I'm going to roll a new release within the next few days.

Fixed in 7.x-1.2.

Sorry to reopen. I would like to report that it deletes the contents both from edit and node view pages. Mostly deleting body and simple text fields.

Thanks

Ugh, that's bad. My apologies.

I'll get to this as soon as I can, but it's going to be a few days at least. Meanwhile, can you please tell me what other multilingual modules you have installed?

Hi, thanks.

I installed regular combo: i18n + Variable, and languageassign.

This module can be very useful after bulk imports or migration, so would love to see this functional. Thanks again

I'm trying to reproduce this, and so far I can't. I've installed i18n, variable, and languageassign; activated all of the i18n submodules; and changed a node from English to French. After that I can still view and edit the node, and its content is still there.

I want to fix this problem, but there's not much I can do if I can't reproduce it. Any other suggestions for reproducing it would be appreciated. Are you sure you're using version 7.x-1.2? Cleared cache?

I would say that in most cases, this module is too dangerous to use unless you deeply understand the drupal field language storage, and have exactly the same translation environment and strategy as the module expects.

After using the module, all field api fields are still attached to the node, but they are still set as as the first language. This module does not change the language of the field values.

Basically, the easiest way to see this is to create content with drupal set in various languages. Then use this module to mass update the language of nodes. Other than the body, most fields on those nodes will appear empty/unset (taxonomy, text fields etc).

In my case I had imported a lot of content using feeds which was set to language "und". After changing content to german "de" using this module the edit forms didn't register any of the imported values for most fields. Using the devel module, one could see that the values were still there, but had been left as "und".

It seems as if the node fields are not being assigned to the proper language when you change the language of it.

It only affects added fields, not body and title.

I'm also very interested in a fix, isn't there a way to do a node_load and emulate an alteration via the node edit form? The module needs to be aware of some fields being "untranslatable" (== always "und"), the easiest way would be to let i18n/core do the magic and just edit a node and send it back via the form_submit, but I'm not that familier with drupal and multilanguage..

Also see this related fix for images being deleted: #1261090: Images deleted after changing language of a node

Greetings Wappie

There should be a warning on the project page since the module isn't currently stable

a total of 50 of my contents are lost. Everything is ok exept the body fields. nothing is showing up in the body field.

My environment is just standard. i used i18, variables and language assign.

I'm absolutely frustrated and do not know what to do.

I think assigning language twice causes the problem.

try with a fresh installation and activate language. I use just bengali and english.
after adding bengali language didn't activate language for some node types (i.e- i didn't enable multilingual in structure>content_type>edit).

I've assigned bengali to language nutral contents.
I assigned same language twice to some contents.

50 of my contents are lost.
my messages were off in a production site.

i think this will help you to reproduce the bug.

All, I apologize that it's taken me so long to attack this bug. I see the problem and will work to fix is as soon as I can. Until then, I've withdrawn the Drupal 7 release.

mahfuzur, I believe that your content is still present. If you use Language Assignment again to change the nodes' language back to its original value, your content should still be there.

subs.

Here is a possible fix:Replace the languageassign_node_presave function. (This code is based on what you would find in the locale.inc from core when you change the lang of a node)

/**
* Implements hook_node_presave().
* Updates the nody and body languages.
*/
function languageassign_node_presave($node) {
  if (property_exists($node, 'languageassign_langcode')) {       
    if (field_has_translation_handler('node', 'locale')) {
      $new_language = $node->languageassign_langcode;
      $previous_language = $node->language;  
     
      $node->language = $new_language;
     
      unset($node->languageassign_langcode);

      $available_languages = field_content_languages();
      list(, , $bundle) = entity_extract_ids('node', $node);
    
      foreach (field_info_instances('node', $bundle) as $instance) {
        $field_name = $instance['field_name'];
        $field = field_info_field($field_name);

        // Handle a possible language change: new language values are inserted,
        // previous ones are deleted.
       
        if ($field['translatable'] && $previous_language != $new_language) {
          $node->{$field_name}[$new_language] = $node->{$field_name}[$previous_language];
          $node->{$field_name}[$previous_language] = array();
        }
      }     
    }   
  }
}

Still dont use this function on field translation. Use it when using node translation only.
Read this to understand the difference between field and node translation : http://hojtsy.hu/blog/2011-jan-31/drupal-7039s-new-multilingual-systems-...

...following.

Could you please disable the download for this module? I used the D6 version / installed D7 via drush and got my content deleted. I know i can set it back but it will cost me a couple of hours :(

Is this the solution?
http://drupal.org/node/1261090#comment-4977026

+1

Subscribing... I'm writing a book on Drupal 7 i18n and want to include this module in it!

[NOTE: If you just want to "subscribe" to this discussion, click the "FOLLOW" button at the top right of this page.]

Kristen

Dear domidc, Thanks for your work.
I tuned your code and tested. And i made a patch file.

It works fine and don't print Unindexed warning.

A little change added.
Calling unset function before compare old and new language.

I just did a bulk change from Language neutral to English and then back (both via the tool and another node manually) and was not able to view the original body content. So, in my case, changing the language back did not solve the problem.

Would you mind provide instructions for bringing the content back?

@barami: Thanks for your patch #29, I've did some language assignments without any data loss.

I tried applying patch from #29 on the latest 7.x dev version and the patch failed.

[kristen:modules]$ patch -p1 < languageassign-fix_content_delete-1086454-29.patch 
patching file languageassign.module
Hunk #1 FAILED at 54.
Hunk #2 FAILED at 165.
2 out of 2 hunks FAILED -- saving rejects to file languageassign.module.rej

The patch works on 7.x-1.2 and fixes the loss of data from the body field for me.

@barami - can you reroll the patch against the dev version because it will need to be committed against dev in order to get in. Thanks!

@Kristen Pol
Hm?
Does your repository pushed to remote repository? I pulled repository and applied patch now, But, It works fine.
I tried master branch and applied tarball 7.x-1.x-dev published on Jun 17. Also i tried on tag 7.x-1.2. Each case are succesfully applied with no errors.

If you were pulled your repository to remote, i will pull and reroll the patch.

@barami - The patch was applied in the wrong directory (thus, the error). I have now applied the patch without errors.

I tested 2 scenarios:

1) Language assignment enabled but without translation.

This works as expected. I was able to change the language of nodes without the body disappearing.

2) Translation enabled.

This one is tricky because I'm not sure how it is supposed to handle the following situation:

a) I have a Burmese node.

b) I have an English node.

c) These are translations of each other.

d) I use language assignment to assign English to the Burmese node.

e) Now I have 2 English nodes in the same translation set.

Should there be a warning/error message?

Is this issue even limited to/related to languageassign.module?

Entity Translation all by itself does this, under certain conditions.

7.x-1.x-dev deleted the content the body field.
All other texts in fields where preserved.

Patch #29 fixed that for me.

http://drupal.org/files/languageassign-fix_content_delete-1086454-29.patch

Thanks @barami

Patch in #29 applies fine and seems to work fine.

This is a critical issue still not fixed after more than one year! There should be a warning on the project's page liking to this issue here so that admins considering using it are aware of this.

This is a very useful module -in theory at least-, but I'm keeping it disabled in my installations (in order to receive version update notifications) till this is resolved. I'm afraid though that the commit history (no commits for more than a year) leads me to assume that it is abandoned.

To #44: I think this only sets the language on the node, but doesn't update the fields.

The patch in #29 applies fine using git apply and seems to work. I've got a bunch of nodes that are language neutral, and I've been testing it from the content list (admin/content) to set the language on some. I've been checking the results both by looking at the node view and edit form, but I also open the Devel tab for the node before and after and check the language property on the node object, and the array key used for fields (which is 'und' for Language Neutral and language code for items that have a language set).

But, it's important to note that the field itself must be translatable: edit the content type, edit the field, and click the "Enable translation" link at the bottom, for each field that may be used.

Also worth noting: the node appeared just fine for me before I realized that I needed to enable translation on each field, but I think this is just a function of the environment I'm working with: all the nodes were language neutral, so fields that do NOT have translation enabled remain language neutral when I translate them, so those field values will be displayed even if the node is set to Japanese. If you're translating a node that's set to English to Japanese, and have NOT enabled translations on the fields, then presumably those values would not appear; only Japanese or language neutral values would. Take this with a grain of salt: there's only about a 40% change that I have any idea what I'm talking about.

this deleted all content on my drupal 7 site.

at least have the decency to make a big bold red warning on the main page.

thanks a lot

#44 @morningtime -- Thanks so much, I searched for an hour trying to figure out how to change the language with VBO, that worked great! So yes, no need for this module anymore.

Updated issue summary.

@Andrew Schulman: can you please update the project's page to note the following:

1. (emphasize) that this issue has been withstanding for more than 3 yeas now.

2. hide the 7.x versions from the downloads section (this is a critical data loss issue and people might jump straight to the downloads without reading notes).

3. point people to using VBO instead as @morningtime suggests back in #44?

Thanx in advance.

klonos and all, I humbly apologize for leaving this issue unattended for so long. You have my attention on it now.

I've removed the 7.x versions from the project page for now. Given the discussion so far:

1. Is the module worth saving? That is, given that you can use VBO to change node languages, would it still be worth the effort to test the fix in #29 and issue a new release?
2. If it is worth saving, does someone have a readily available test case to reproduce the problem? When I last looked at this some while ago, I couldn't reproduce it.

@Andrew Schulman, Thank you so much for this module. Appreciated. I used it since Drupal 6.

You should retire this module. :) Time to move on and consolidate effort in VBO (the big picture).

@Andrew Schulman: Thank you for your very prompt actions once I "pinged" you.

The way I see it these are the pros for keep on maintaining this project:

1. The "Set language" option available in the actions drop-down is more prominent/obvious/straight-forward and less "cryptic" than "modify entity values".
2. To use VBO, you need to build a content view - it doesn't work on the admin/content page that comes by default with drupal (that's where newbies will look first for such an option).
3. Even if alternatively you ask users to use Administration Views in order to replace the admin/content page with a view and then act with VBO on it... that might make it easier for newbies (they skip setting up a view), but on the other hand we do ask them to install and configure 2 modules instead of just one (that by the way works out of the box after installation without any special configuration required).
4. With this module it is as easy as selecting the language from the drop-down and hitting the "Update" button while with VBO it is a 5-step thing (select "modify entity values" -> hit execute -> select language -> hit next -> hit confirm)

...and to be fair, here are the cons against keeping the project alive:

- the maintainer is plagued by the same thing that we all suffer from: lack of time

Anyways, my point is that it's definitely worth "saving" the project, but it all comes down to how much time/energy you have.

PS: working on STR and will update the issue summary accordingly...

...added steps to reproduce in the issue summary.