[Resolved] Problem with duplicates not being created correctly via Toolset Forms

Your code to create the duplicates is fairly straightforward: you hook into the cred_save_data action when the form is submitted, and run the wpml_make_post_duplicates action to generate the duplicates.

In the instances where this is failing it could be because the cred_save_data action is not triggered for some reason, or the WPML code to generate the duplicates fails, and to begin to know why this fails we need to know which it is.

So, can we add a line to log when the cred_save_data hook runs (you'll need your debug.log turned on). Then when the issue occurs again you can check the log for the time the problem post was published to see if the cred_save_data hook ran at all.

So modify your code like so:

function sync_language_duplicates_on_submission( $post_id, $form_data ){
error_log("cred_save_data hook run for post $post_id with form " . $form_data['id']);
    // Post Form - New Nanny Ad (56261)
    // Post Form - New Job Ad (56251)
    // Post Form - New Native Nanny User (56255)
    // Post Form - New Family User (56244)
    // Post Form - New Message (56276) // Removed - no longer translatable
    // Post Form - Reply Message (56278) // Removed - no longer translatable
    // Post Form - New Nanny Ad - Unverified Nanny (56272)
  $forms = array( 56261, 56251, 56255, 56244, 56272 );
    if ( in_array($form_data['id'],$forms) ){
        global $sitepress;
    // Use WPML API
        do_action( 'wpml_make_post_duplicates', $post_id ) ;
    }
}
add_action( 'cred_save_data', 'sync_language_duplicates_on_submission', 12, 2 );

Let's run that and see what it shows.

OK, let's go through each of those in turn:

1) Yes, I think you can close the Toolset ticket, let's handle it here.

2) All the duplicates should have the "_icl_lang_duplicate_of" postmeta entry, yes, otherwise they are not duplicates; if they exist at all, they would be translations and so are not kept in sync.

3) Noted.

4) So, for that example post (ID 61573) there is no other-language version of the post, only the German original. Which means the duplicate wasn't created in the first place, rather than the scenario I speculated on, that a duplicate had been created but it was subsequently edited with the translation editor and un-synced from the original.

5) You don't press the + button. When you check the duplicate checkbox, a "Duplicate" button appears for you to actually create the duplicate (screenshot).

6) If you have some of these problem posts that were missing a duplicate and in the editor you went ahead and created a translation (so the secondary-language version of the post exists, but is not synced to the original as a duplicate), you could insert an entry in wp_postmeta with the "_icl_lang_duplicate_of" key and the original post ID as the meta value, and that would mark it as a duplicate. (You would perhaps then want to update the original language post—maybe make a trivial change, like to punctuation—so that the mechanism to copy across the content from the original to the duplicate was triggered.)

Where there is no translation (the duplicate was never made and you never made a translation), then you can use the UI and the Duplicate button to create a linked duplicate.

7) Let's see what it throws up. It won't necessarily tell us the cause, but will give us something to work with.

Comments in WordPress are, well, weird, inasmuch as you cannot enable comments for all posts of some type. When registering a custom post type you actually declare support for the ability to enable comments for individual posts.

Comments have to be enabled for each such post, which, as you have seen for yourself, means the column 'comment_status' set to 'open' for the corresponding row in wp_posts.

Regarding where something might go wrong in terms of duplicating a post to other languages, I'd have to first establish how is the comment_status being set to 'open' in the first place, given that the default is 'closed'?

We can continue in this ticket, no problem, but note I am off Monday.

It looks like that code has been proposed (by a user, initially) to force displaying the comments UI where it wouldn't ordinarily be displayed.

That includes the output of a View that lists posts (or a single post).

And it includes a single post being displayed by the theme (perhaps with a Toolset content template) where commenting is turned off (comment_status in wp_posts is set to closed).

If commenting is turned on (comment_status = open) then a single post should display the comments UI without the need for any extra code.

The code you shared doesn't seem to be implicated in the problem.

Reviewing the process, I see that actually the default for comment_status is determined by the settings (stored in wp_options, the option_name default_comment_status), and if that is set to open then the newly created posts will have open comments, whether published via the back end or using a front-end Toolset form.

With front-end forms, when the page containing the form is opened and the form rendered, an auto-draft post is created. Then when the form is submitted, that auto-draft post is updated with the form details. The auto-draft itself will have comment_status open if that is the default, and updating the auto-draft with the form content doesn't touch the comment_status.

So it is very hard to see how the comment_status might wrongly be set to closed.

I tried an experiment to see if I could break something, loading the page that renders the form (which generates the auto-draft), and then deleting the auto-draft directly from wp_posts before submitting the form (to simulate something going wrong when someone doesn't submit the form for an extended period).

But the created form still has the comment_status set to open, when that is the default.

How often does this problem occur?

Perhaps you answered this already and I missed it, but where the comments are closed, is that on both the original language post and the translations, or only on the translations while the original has comments open?

So that sounds like the problem occurs when creating the duplicates with the WPML API hook wpml_make_post_duplicates.

I'd like to update your code that generates the duplicates to catch this when it happens.

Let me work on that and then I'll get back to you, and we can monitor what happens.

As we've gone down a specific route to work on an issue which is distinct from the original, let's continue this in another thread.

I've split this and shared the proposed code to monitor the issue in the other thread, so that I think we can close here, if agreed.