I don't know whether this is related and I'm absolutely happy for this to be handled in a second ticket for clarity, but we also noticed that some duplicate posts are not getting the "Allow Comments" field duplicated correctly in their duplicates even though the meta_key "_icl_lang_duplicate_of" is set correctly. We have the post type set to Allow Comments by default. In fact it is a requirement for those Nannies and Families to be reviewable, but in some cases the Allow Comments is being set to closed instead of open on duplication. Is this a known issue?
As you can see on the screenshot, orignal Nanny post 51809 has wp_posts.comment_status = 'open' but on the duplicate Nanny post 51810 wp_posts.comment_status = 'closed'.
Can it be that there is some kind of time delay when users are creating/editing a Toolset Form? I have a very vague distant memory of something that Waqar once told me in a Toolset ticket, that when a user opens a Toolset Form the draft record is created in the database (cred-auto-draft-XXXXXX) and only when they click Submit that the "final" version of the record (I guess status Published) is then saved to the database. If such a time delay exists, how long is it? Otherwise I can't think of any logical reason why most records save the Allow Comments correctly, but some don't, since the field isn't even exposed anywhere for users to edit.
If you want me to open a second ticket for this, please let me know, or if you open the ticket I can provide more examples/screenshots/context.
Of course I could just update the database to change all comment_status = 'open' to comment_status = 'closed' for all affected post types, but would love to get to the bottom of why this isn't happening automatically.
If you need access to the front end to access the database with Adminer, please let me know. I'm happy to give you credentials.
Simon, let's update your code that generates the duplicates to log the comment status of the original post and the same of each of the generated duplicates in the other languages immediately after they are created.
That should hopefully give us some more details that might help identify the source of the problem.
function sync_language_duplicates_on_submission( $post_id, $form_data ){
// 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 ) ;
/* Debugging for new nanny and new family posts */
if ( in_array( $form_data['id'], [56255,56244] ) ){
// get the trid of the source post
$post = get_post( $post_id );
$trid = apply_filters( 'wpml_element_trid', NULL, $post_id, $post->post_type );
// get the translations
$translations = apply_filters( 'wpml_get_element_translations', NULL, $trid, $post->post_type );
// loop over the translations and log the comment status
error_log("## Checking duplicates of post ID = $post_id ##");
foreach ($translations as $lang => $object) {
// get the post
$duplicate = get_post( $object->element_id );
error_log("** Comment status of $lang post with id = {$duplicate->ID} is {$duplicate->comment_status} **");
}
}
}
}
add_action( 'cred_save_data', 'sync_language_duplicates_on_submission', 12, 2 );
Try leaving that active and monitor the logs to see if you can spot an occasion when the problem occurs.
I agree we should handle these two tickets separately. And while the other ticket is solved for existing cases, we currently enabled the debug.log on your request to wait for the next case to happen for troubleshooting, so I don't think it can be closed yet...
Furthermore, as part of that effort we already modified the same custom code which you are requesting to modify again in this ticket regarding the comment_status.
Here are the original and (currently modified) versions:
ORIGINAL:
function sync_language_duplicates_on_submission( $post_id, $form_data ){
// 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( 921, 929, 16624, 16794, 1250, 1251 );
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 );
CURRENTLY MODIFIED ON PRODUCTION:
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 );
Please advise on how we should combine both the modified version and your new suggested version to handle both tickets simultaneously...
Sorry, I was getting ahead of myself with the other ticket.
You can just add back the line I inserted in the first place to the code changes I shared with you for this ticket, i.e.
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 ) ;
/* Debugging for new nanny and new family posts */
if ( in_array( $form_data['id'], [56255,56244] ) ){
// get the trid of the source post
$post = get_post( $post_id );
$trid = apply_filters( 'wpml_element_trid', NULL, $post_id, $post->post_type );
// get the translations
$translations = apply_filters( 'wpml_get_element_translations', NULL, $trid, $post->post_type );
// loop over the translations and log the comment status
error_log("## Checking duplicates of post ID = $post_id ##");
foreach ($translations as $lang => $object) {
// get the post
$duplicate = get_post( $object->element_id );
error_log("** Comment status of $lang post with id = {$duplicate->ID} is {$duplicate->comment_status} **");
}
}
}
}
add_action( 'cred_save_data', 'sync_language_duplicates_on_submission', 12, 2 );
I think it would be a good idea to set all the existing comment_status = 'closed' to 'open' on the database while we wait for this to happen again.. Do you agree?
I manually set the comment_status on the database to 'open' for all Nanny and Family post type records, however I haven't seen any new cases of the comment_status being set to 'closed' since 11/2/2024. That would correspond roughly to the time after installing the newest version of Toolset Forms.
I would like to give this one another 2 weeks before closing it, since it's such a sporadic problem, if that's OK with you. We still have the debug.log active.
It's no problem to keep this open, but I'll mark it as awaiting your feedback again so that it's not in my queue. You may have to ping to my pong again in a week to stop this being closed automatically.
I've found 2 more instances where the comment_status has been set again to 'closed'. Do you prefer I transfer you the whole debug.log file or just the relevant statements?
First, to connect the posts to the debug.log entries, it should be noted that the posts appear to dated in German time (UTC+1), whereas the debug.log entries use UTC.
Both posts you isolated appear to follow the same pattern, so let's look at the post ID = 25602.
In wp_icl_translations, via the trid = 954795, we can see that 25602 is German, and a translation of the original English post with ID 25595.
In wp_posts we can see that both posts (EN and DE) have a post modified date that is much later than the published date, i.e. these posts have been edited with a form, these updates do not come from a form to publish posts.
Also, we can see that the posts have CRED auto-draft titles. Those are created whenever someone loads a page containing a publish-post form. If a user navigates away from the page without submitting the form the post would remain, but it would have a draft status, while your posts have a status of publish. The only way I know for that to happen is if the publish post form does not include a post title field in the first place. Checking your site, I see that all Nanny posts have CRED auto-draft titles, so I assume that must be the case here.
Here are the corresponding entries we find in the debug.log for these posts:
[10-Mar-2024 06:54:17 UTC] Shortcode is_nanny_wpml_original 25595
[10-Mar-2024 06:54:17 UTC] info for post 25595 : stdClass Object
(
[element_id] => 25595
[trid] => 954795
[language_code] => en
[source_language_code] =>
)
[10-Mar-2024 06:54:17 UTC] Shortcode is_nanny_wpml_original 25595
[10-Mar-2024 06:54:17 UTC] info for post 25595 : stdClass Object
(
[element_id] => 25595
[trid] => 954795
[language_code] => en
[source_language_code] =>
)
[10-Mar-2024 06:54:19 UTC] cred_save_data hook run for post 25595 with form 56257
The final line *does* come from that code, but most of the code isn't executed because we specify an array of form IDs that the code applies to, and form ID 56257 is not such a form. I expect that would be an edit form.
Can you identify where these entries in the debug.log come from, which other code snippet is using error_log statements to log such messages?
That's correct, all Nanny and Family posts just have CRED auto-draft, since they don't have any title.. Is that a bad idea? I'm just thinking that could be horrible for SEO... Do you have any recommendations here?
And again, correct, the modification date is a later one , as it was coming from "Post Form - Edit Native Nanny User (ID: 56257)", the ID matches the ID you quote.
On that edit form, we call the Toolset custom code snippet "func-is-nanny-wpml-original" via the following conditional, to ensure that the Nanny editing her profile is doing so on her WPML language original post, so that when she saves, her changes are propogated correctly to the Nanny WPML language duplicate post.
[wpv-conditional if="( '[is_nanny_wpml_original post='[wpv-post-id]']' eq '0' )"]<h5 style="color: #ff0000; font-weight: bold;">[cred_i18n context="toolset-forms-56257" name='Switch languages to edit']Your profile may only be edited in the language in which it was created originally. To edit your profile, please first switch languages using the flag in the menu.[/cred_i18n]</h5><br>[/wpv-conditional]
As far as I'm aware, nothing else should be writing to debug.log other than the changed custom code we have recently discussed in the two WPML tickets. I personally don't like having debug.log active since it poses such security risks.
OK, so the code snippet for the shortcode is_nanny_wpml_original *does* contain the error_log calls that are responsible for the messages in the log I reported above.
They confirm, then, that the original language (EN) version of the post (ID 25595) was edited with the form ID 56257.
Because that form does not match the list of form IDs to apply the code from our snippet to make duplicates (that applies only to post forms, not edit forms) that code is not applied.
After the EN post has been edited, you see that the DE duplicate has a closed comment status.
But there is nothing I can see to suggest that editing the EN post would change the comment status of the DE duplicate.
In fact, I just set up a multilingual test site with a similar setup to double check that there is not some issue with WPML maintaining the duplicate and losing the comment_status setting in this scenario, and it worked as expected.
Which leads me to think if the comment_status of the DE duplicate was closed after editing the EN original, then it was likely closed before the edit.
So I have manually updated the comment_status of the two posts directly in the database to set them as open.
If you query for posts with comment_status closed again you should find there are no such examples.
Can we continue to monitor to see if any re-emerge?
The topic ‘[Closed] Problem with duplicates not having same comment_status as originals’ is closed to new replies.
Manage Cookie Consent
We use cookies to optimize our website and services. Your consent allows us to process data such as browsing behavior. Not consenting may affect some features.
Functional
Always active
Required for our website to operate and communicate correctly.
Preferences
The technical storage or access is necessary for the legitimate purpose of storing preferences that are not requested by the subscriber or user.
Statistics
We use these to analyze the statistics of our site. Collected information is completely anonymous.The technical storage or access that is used exclusively for anonymous statistical purposes. Without a subpoena, voluntary compliance on the part of your Internet Service Provider, or additional records from a third party, information stored or retrieved for this purpose alone cannot usually be used to identify you.
Marketing
These cookies track your browsing to provide ads relevant to you.
