Digest includes very old messages

@belg4mit,

In Subscribe2->Settings under the Email Notifications tab you have the ‘stickies’ option, where it says “
Include Sticky Posts at the top of all Digest Notifications” set to yes. That means all posts marked as sticky will be included in every digest email. Set that option to ‘No’ and that should clear up your issue.

But there are no sticky posts…

option_id 	option_name 	option_value 	autoload
88 	        sticky_posts 	a:0:{}	        yes

@belg4mit,

So, why is that setting enabled than?

The other thing you might have is a filter on Subscribe2 called ‘s2_digest_email’ that is adding data to your email.

Or you might have an issue with the timestamp on certain posts getting updated such that they get included.

Or there might be an issue with the returned timestamp on the server.

Or there might be a plugin / theme conflict.

Things worked fine until the 3.6.1 update.

The option is enabled because sometimes there are sticky posts, sometimes there are not. Currently there are not, therefore sticky posts are not the old ones that are being shown.

My s2_digest_email filter is not doing this

function rebase_digest($message){
  return str_replace("https://", "https://", $message);
}
add_filter('s2_digest_email', 'rebase_digest');

The old posts have not had their timestamps updated. Something with a revision of 26 September, 2013 @ 11:21:51 was included in a weekly digest on 10/18.

I only have one plugin that modifies queries (PressPermit), and the problem persists whether or not it is activated.

@belg4mit,

Maybe try re-installing the 3.6.1 update to WordPress then in Dashboard Updates on the off change a file is corrupted somewhere.

It was the sticky setting, but not because there were sticky posts, rather Subscribe2 was sending a query with an empty post__in condition and the result was extraneous posts being merged into the digest. Here’s a patch that fixes it:

--- class-s2-core.php~  2013-10-17 15:39:29.900675197 -0500
+++ class-s2-core.php   2013-10-18 10:52:31.793602618 -0500
@@ -1454,9 +1454,11 @@

                // Collect sticky posts if desired
                if ( $this->subscribe2_options['stickies'] == 'yes' ) {
-                       $stickies = get_posts(array('post__in' => get_option('sticky_posts')));
-                       if ( !empty($stickies) ) {
-                               $posts = array_merge((array)$stickies, (array)$posts);
+                       $stickIDs = get_option('sticky_posts');
+                       if ( !empty($stickIDs) ) {
+                               $stickies = get_posts(array('post__in' => $stickIDs));
+                               if ( !empty($stickies) )
+                                       $posts = array_merge((array)$stickies, (array)$posts);
                        }
                }

@belg4mit,

Thanks for posting the fix. I’ll look into it but I’m not seeing the same so it’s very strange.

No problem.

Even if you cannot replicate, the patch or something fixes it for some and does not hurt anything. In fact, it’s probably better to check if the sticky option is empty and avoid hitting the database unnecessarily when it is ?? (The second/original test for emptiness is probably overkill)

@belg4mit,

I think there might be more to this.

In testing I created a post on a test site and made it sticky. get_option(‘sticky_posts’) returned the post ID as expected and get_posts(array(‘post__in’ => get_option(‘sticky_posts’))); returned the full post as expected.

Next, change that post from a stick back to a normal post. get_option(‘sticky_posts’) returned null as expected BUT get_posts(array(‘post__in’ => get_option(‘sticky_posts’))); still returned the full post!!

This could well be a bug in WordPress. I’ll look in the core trac.

@belg4mit,

Reading further into the WordPress documentation and looking at the code examples, this bizarre behaviour seems to be the expected behaviour also! I’ll code around it with your patch in the next release.