Localized webform is missing when exporting with Node Export module (7.x-3.0-rc3).

On server A, I created a node (Webform-enabled content type) to which I attached a webform. In 'Form settings', 'Expose webform component strings suitable for translation.' and 'Keep a single webform across a translation set.' are checked. I added a French translation. All is good, the 'single & localized webform' appears on the French node. Works beautifully.

I then proceeded to export/import the 2 nodes to server B using node_export (got an error, see below). The source node 'looks' perfect and functional. But the translated node (French) is missing its webform. I deleted the imported translation & added a new one. Still no webform.

Is server B's config same as A? I created a test node with webform on server B, translated it. The webform shows up on both the source and the translation without any apparent problem.

Notes:
- The 'Localization by string translations' settings are not exported and need to be configured manually.
- Webform validation rules are not exported either.

Error on import:

Warning: Invalid argument supplied for foreach() in node_export_json_decode_objects() (line 44 of /home/me/public_html/mysite.ca/sites/all/modules/node_export/formats/json.inc).

Should this post be redirected to the node_export issue queue?

Comments

dragonwize’s picture

Category: bug » feature
rv0’s picture

the "single webform across translation set" gets lost along the way. ( @bisonbleu try reenabling that on the src node?)
(in the same way webform validation rules are lost)

There's no good way to solve this afaik.
If there is, then all modules that extend webform should use this method.

lklimek’s picture

Here is my first try to solve this issue. This patch adds webform options to node export, and then processes them on import.

Attached version supports only "Expose webform component strings suitable for translation" option, but I believe it's a good starting point to work further. The issue with "Keep a single webform across a translation set." is that we need to check dependencies between different nodes and update respective NIDs. Shouldn't be too hard if all required nodes are a part of export, but if they aren't, then we should go with mechanisms like UUID.

But the only thing I need is "Expose webform component strings suitable for translation", and that's what this patch should achieve.

mikran’s picture

Assigned: Unassigned » mikran
Issue summary: View changes
Status: Active » Needs work

I think UUID ia mandatory to get string translations to work at all. At the moment translations get mixed up really badly whenever nids change. I'll try to implement initial version of strings exported by UUID rather than nid, sometimes next week.

I didn't test patch in last comment but code style is way off. This is what coder-review tells (also doc blocks need to be updated)

b/webform_localization.module: @@ -681,3 +682,100 @@:
 +26: [normal] Use uppercase for PHP constants, e.g. NULL, TRUE, FALSE
 +69: [normal] else statements should begin on a new line
 +69: [normal] Use "elseif" in place of "else if"
 +84: [normal] Use uppercase for PHP constants, e.g. NULL, TRUE, FALSE
 +88: [normal] else statements should begin on a new line
mikran’s picture

Status: Needs work » Needs review
StatusFileSize
new13.01 KB

Here is initial patch that changes string context from "nid:{...}" to "uuid:{...}" if uuid module is installed. Existing translations are not yet changed. Also this patch does not include the previous patch from #3.

mikran’s picture

StatusFileSize
new13.89 KB

Updated patch. Old strings are now converted into new uuid context strings:

context string before:
1:13:#options-1

context string after:
b5d3856f-054e-4c7f-81cd-1f9848ec23d1:13:#options-1

mikran’s picture

Version: 7.x-1.x-dev » 7.x-4.x-dev

And the patch was for 4.x branch.

GDrupal’s picture

@mikran great job! I think We could have used a independent issue for UUID support but it's ok. Let me double check this, it looks RTBC at first sight.

@lklimek thanks for your work! I think we need some more work around your idea I will be dealing with that after the UUID support review.

GDrupal’s picture

Patch from #6 committed thanks @mikran.

I also added a new function webform_localization_uuid_update_strings() that updates string context when enabling / disabling UUID module. So now there is not need for a database update.
http://drupalcode.org/project/webform_localization.git/commit/899a92d

mikran’s picture

In addition to enable / disable there is still need for that database update for those installations where both modules are already enabled.

GDrupal’s picture

String refresh callback now cover hose installations where both modules are already enabled.

http://drupalcode.org/project/webform_localization.git/commit/6ccaf13

mikran’s picture

With latest version from Git I get MySQL syntax error on install. Attached patch fixes this (do not update if $old_ids is empty). In addition to that I there is another error in setting the webform_localization_using_uuid -variable as that never got the value TRUE. Attached patch fixes these 2.

GDrupal’s picture

@mikran thanks for the patch although I can't reproduce the install error locally.

mikran’s picture

Steps to reproduce on fresh install:

1. drush en -y webform_localization

2. drush en -y uuid

This results in

$ drush en -y uuid
The following extensions will be enabled: uuid
Do you really want to continue? (y/n): y
WD php: PDOException: 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 '))' at line 1: SELECT t.nid AS nid, t.uuid AS uuid
FROM 
{node} t
WHERE  (nid IN  ()) ; Array
(
)
 in entity_get_uuid_by_id() (line 421 of /.../sites/all/modules/uuid/uuid.entity.inc).
GDrupal’s picture

joseph.olstad’s picture

Status: Needs review » Fixed

no comments since last commit, pretty safe to say it's resolved.
feel free to re-open later.

Status: Fixed » Closed (fixed)

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