`LogService::prune_logs` removes old posts from custom post type

First, thanks a lot for Simple SMTP, which is precisely what we need.

However, after installing Simple SMTP, we noticed that non-recent posts from a custom post type (“lesson”) started to disappear. Investigating the issue, we found that a WP Cron job installed by Simple SMTP was responsible, wpss_clear_logs in particular.

I could reproduce that behaviour even after I disabled all plugins save for the two plugins needed to define the custom post type, namely, Seriously Simple Podcasting (SSP) and Audiothek (a non-public plugin of our own) and the two plugins I used for debugging, Activity Log, and WP Crontrol. Activity Log and WP Crontrol were not installed when the behaviour occurred originally, so if this is an interaction effect, it is an interaction effect with SSP and/or Audiothek.

When I changed

foreach ( $all as $log ) {
    wp_delete_post( $log->ID );
}

in simple-smtp/src/log/class-logservice.php:227 to

foreach ( $all as $log ) {
    /* wp_delete_post( $log->ID ); */
    error_log("DEBUG: {$log->ID} ({$log->post_type})");
}

and triggered wpss_clear_logs using WP Crontrol, I got:

tail -f wp-content/debug.log
[28-May-2024 10:43:43 UTC] DEBUG: 4956 (lesson)
<repeats ca. 2,000 times for different posts>

However, when I added

error_log("DEBUG: {$this->post_type}");

to the beginning of LogService::prune_logs() at simple-smtp/src/log/class-logservice.php:216 and trigger wpss_clear_logs, I got:

tail -f wp-content/debug.log
[28-May-2024 10:43:43 UTC] DEBUG: sbss_email_log

I wondered whether get_posts uses “OR” to connect “post_type” and “date_query”, but that clearly is not so: Firstly, only old posts of our custom post types are deleted, not all posts. Secondly, posts of other types are not deleted at all (though I did not check whether they are just not old enough; there is also a lot of work on our site at the moment, so I might have missed a deletion).

At this point, I strongly suspect that our “pre_get_posts” filter for adding “lesson” to the main loop is responsible:

/* Add CPT_LESSON to the main loop. */
add_action(
    hook_name: 'pre_get_posts',
    callback: function (\WP_Query $query): \WP_Query {
        if ($query->is_home()) {
            $post_types = $query->get('post_type');
            if (is_array($post_types)) {
                $post_types[] = CPT_LESSON;
            } else {
                $post_types = [$post_types, CPT_LESSON];
            }
            $query->set('post_type', $post_types);
        }
        return $query;
    }
);

Note that this code is only called for the front-end, though perhaps wp-cron.php qualifies as front-end. However, $query->is_home() should return false for get_posts when called by wp-cron.php, shouldn’t it?

I’ll update, and likely close, this issue once I had the time to check this. In the meantime, any input is appreciated, of course.

• This topic was modified 6 months ago by Odin Kroeger.
• This topic was modified 6 months ago by Odin Kroeger.
• This topic was modified 6 months ago by Odin Kroeger.
• This topic was modified 6 months ago by Odin Kroeger.