[Resolved] CRED Edit Form Breaks Translation Relationship When Editing in 2nd Language

[Author]

Posts

[George]

(Preferably Beda can answer this question because it applies to a solution in one of his previous posts.)

On our site, users can create and edit their listings in a directory through CRED forms. We decided to make it multilingual, so in order to automatically duplicate content created with CRED, we used the solution in this post by Beda:
https://toolset.com/forums/topic/cred-custom-post-type-front-end-translations/#post-344169

It works amazing, except for when the user tries to edit his post in the opposite language of which he created the post in (so if they created it in Chinese and use the edit form when the language is switched to English, and vice-versa). When a user tries to do this, the translation is broken off and gets lost, and no longer works anymore. I suspect this is because the posts are set to "Duplicate" and not "Translate", which normally doesn't let you edit the 2nd language's post (but CRED overrides this)...

#6 in Beda's post says that the duplicate flag should be removed in this situation, but that is not the case with my forms here.

So to recap:

User creates "Listing" in English, Chinese post auto-duplicates -> User visits that listing in Chinese and uses CRED edit form -> After submit, translation relationship gets lost and Chinese post is corrupt.
(and vice-versa, so not dependent on default language)

EDIT: So I corrected the problem of breaking the translation relationship by first using Beda's shortcode to get language code:

/** 
 *Add ICL_LANGUAGE_CODE shortcode 
 */
         
function wpml_language_code_value_func() {
    $return = ICL_LANGUAGE_CODE;
    return $return;
    }   
add_shortcode('wpml_language_code_value', 'wpml_language_code_value_func');

And then inserted it into my CRED form as a value in a solution Caridad mentioned in this post:
https://toolset.com/forums/topic/cred-wpml-post-to-specific-language/#post-278632

<input type="hidden" name="icl_post_language" value="[wpml_language_code_value]" />

So the form will always update with the current language selected. Great

HOWEVER

The "duplicate" flags still remain, meaning even though the user can now edit the post in either language, any changes will be shown in the other language as well, so translation is still not possible.

I found this field while searching WPML here:
https://wpml.org/forums/topic/batch-change-translate-independently/

_icl_lang_duplicate_of

But I'm not sure what to do with it. I'll check the database. I'm thinking that if this is the right field to update, in the CRED edit form, I can make it an optional field based on whether the user wants to create a separate translation OR keep everything the same across languages.

Please tell me if there's something I missed and could have done in an easier way

[Beda]

Yes I recall the customized approach there.

Pleas aknowldege, that Toolset and WPML are not striving to provide a Front End Editor.
I requested it, but we will not do it.

Instead we provide the Access Plugin with wich you let the Translators edit the translations from within the Backend only.

In this Spirit everything that is related to debugging or improvement/new setup of CRED as a front end Translation tool, is not suported and falls under Custom Code.

What I can do is try to help you to find a workaround (I am sorry that I do not use the approach anymore myself and do not have a working copy of the solution anymore to play with).

I recall, I had myself issues with the hooks

wpml_admin_make_post_duplicates
https://wpml.org/wpml-hook/wpml_admin_make_post_duplicates/
and
wpml_make_post_duplicates (which would theoretically be the CORRECT one to use, as in front end)
https://wpml.org/wpml-hook/wpml_make_post_duplicates/

I changed it to the admin_make as the other simply did not do what I needed.

Now, to debug your problem, I would as first var_dump the Post Object of the translation.

You should see the field _icl_lang_duplicate_of
Now, that field shoudl hold the ID of the "master" post.

You could run a update_post_meta function when submitting the Post the first time, and update that Field with '' (empty).
https://codex.wordpress.org/Function_Reference/update_post_meta

Or even you coudl use delete_post_meta()
https://codex.wordpress.org/Function_Reference/delete_post_meta

Be careful with this, test it on a Develop Site first.

Please let me know if that works.

[George]

Thanks Beda,

I think I'm not going to keep playing around with it to make it perfect. One of the biggest drawbacks is that if a user changes any of the custom fields in the 2nd language, they don't get synced to the original language, which would cause problems. I think we'll introduce a conditional into the CRED form to only let the description be edited in the second language and nothing else. Still, the UE is far from optimal. A second option would be to just create a description-english and description-chinese field in the post type itself, so they always get synced, then just filter each out on the views.

Maybe one day the CRED translator can make a comeback!