I've come across another instance of the comment being set to closed.
Nanny post type, original language EN, ID 63872, comment_status open, with a German duplicate ID 63881, comment_status closed.
Original was created just a couple of days ago.
I reinstalled WP Adminer.. Here's the sql to find the 2 instances:
select ID, post_type, post_date, post_date_gmt, post_modified, post_title, post_status, comment_status
from wp_posts
where post_type in ('nanny', 'family')
and comment_status = 'closed';
I'm also forwarding you the debug.log: hidden link
Hopefully we can find some resolution soon, as I don't like to have the debug.log on all the time as I have to keep hiding it with WordFence for security reasons. Do we need to keep it running?
There's definitely some entries in there related to the duplicate ID 63881:
[25-Mar-2024 10:09:39 UTC] Cron unschedule event error for hook: publish_future_post, Error code: could_not_set, Error message: The cron event list could not be saved., Data: {"schedule":false,"args":["63881"]}
[25-Mar-2024 10:15:12 UTC] Shortcode is_nanny_wpml_original 61722
[25-Mar-2024 10:15:12 UTC] info for post 61722 : stdClass Object
(
[element_id] => 61722
[trid] => 1221698
[language_code] => en
[source_language_code] =>
)
Also, I seem to remember you mentioning previously that "closed" was the standard value for comment_status on posts, so I'm also curious as to why ours all seem to be open at first. The only thing I can think of is that the plugin wpDiscuz is somehow influencing the comments. It's the only "Comment" related plugin we're using.
In any case, the bug, if it is one, is not that critical or at least not critical enough to keep writing the debug.log file which keeps being publicly accessible according to WordFence. The important thing for us would be to ensure that all comment statuses on family and nanny post types remain open.
Perhaps you know of some programmatic way/recommended plugin/Toolset method/cron job or other method to accomplish that? Basically, if I could run this SQL automatically on a regular basis, the case would be resolved.
update wp_posts
set comment_status = 'open'
where post_type in ('nanny', 'family')
and comment_status = 'closed';
I looked at the debug.log, and was puzzled why some of the details I was aiming to output seemed to be missing, from all of the entries.
I set up a local site to walk through the code execution and realised I had a simple omission that meant the part we were interested—showing the comment_status of the newly duplicated post—was not generated.
So I can see there's a certain amount of history for that EN post with ID 63872, the post being created, it being viewed, it being edited, viewed again etc., but what I can't see at the time the duplicate was made is its comment_status.
It would be an option to use the WP scheduling system to run code, say, every 24 hours that fixes and such closed comments.
Or we could persist with debugging the issue, which would mean updating the code I gave you before. You should delete the current debug.log, it's very large, and there is nothing to be gained from keeping the older entries.
In which case change the 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 ) ;
/* 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->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 );
Quick update: We had a few more recent cases but none since the code was changed on 5th of April. Setting all existing cases of "closed" to "open" and deleting debug.log again....
I'll keep checking periodically and get back to you.
Kind regards
Simon
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.