Odd Issue Discovered via Logs

[rinogo]

Oops - sorry about that. I forgot that we need to bootstrap Wordpress before we can make that call. Please add these lines before the lines I referenced previously:

PHP Code:

//Load up the Wordpress environment
include_once('../../../wp-config.php'); 


So, you should have something like this:

PHP Code:

<?php
//Load up the Wordpress environment
include_once('../../../wp-config.php');

featurific_do_cron(true);
?>

That's very strange that the user-specified option doesn't work, because the Wordpress.com Popular Posts option uses the user-specified option to function correctly (See the bolded return statement):

PHP Code:

        case 'popular':
            $days = get_option('featurific_popular_days');
            $popular_posts = stats_get_csv('postviews', "days=$days&limit=0"); //Get all posts with stats over the last $days
            
            $post_list = '';
            foreach ($popular_posts as $post) {
                if($post_list!='')
                    $post_list .= ', ';
                    
                $post_list .= $post['post_id'];
            }
            
            [b]return featurific_get_posts('userspecified', $cat_filter, $n, $post_list);[/b]
            break; 


My guess is that if you let the wp.com popular posts run for a while, it would exhibit the problem as well. :/

Please give the PHP approach a shot and let me know what you find!
-Rich

[rinogo]

An additional thought:

I've been working on another issue with a different user, but I think these two issues might actually be related. I'll paste my response to him below. This solution might work for you as well. (Note that on your installation, '400' might not be the magic value. On your installation, it could be as large as 1000 or as small as 100. You could try experimenting and using the largest value that does not result in errors):

Quote:After some debugging on the code while deployed on the site, I've isolated the problem. The following call to the built-in function 'get_posts()' is failing:

$posts = get_posts(
array(
'numberposts' => FEATURIFIC_MAX_INT, //Get all posts. We initially just used 0 (zero) here, which seemed to return all posts, but this didn't work on some installations. My suspicion is that another plugin was interfering. Regardless, this is a sufficient solution for now.
'orderby' => 'post_date'
)
);

It is very strange that this call should be failing. The most likely solution is that this is due to a conflicting plugin. I think, however, that I found a workaround.

FEATURIFIC_MAX_INT in the code above is the largest integer that PHP can manipulate. We use it in this case to instruct Wordpress to 'get up to FEATURIFIC_MAX_INT posts (essentially, all posts), and order them by post_date'. We can use a smaller number here, but if the number of posts ever exceeds that number, then odd post selection behavior will occur. However, if you try inserting some different values in place of FEATURIFIC_MAX_INT, you'll find some interesting behavior.

1000 crashes, just like before.

500 crashes, but generates an error message:
Fatal error: Allowed memory size of 67108864 bytes exhausted (tried to allocate 71 bytes) in /home/insidepo/public_html/wp-includes/taxonomy.php on line 1885

400 works fine.

Anyway, in spite of this curious behavior, it seems that using 400 in place of 'FEATURIFIC_MAX_INT' will fix the problem (as long as you have less than 400 posts). I've made the change in the code - please try using Featurific and let me know if you experience further problems.

-Rich

[Lincoln]

A couple of things: As for the manual post, I think I just did that wrong since I tried it once, and I don't think I bothered to use commas or check to see if the post number IDs I used were correct.

I gave the last suggestion you tried and it worked! I tried 1000 which resulted in errors, then tried 100 and that finally did the trick. This must be the culprit then! I assume if this is the source of the errors then it would be pointless to set up a manual cron job since it still has to execute "get_posts" anyway?

[rinogo]

Sounds great, Lincoln! I'm glad '100' worked for you. We only have one other confirmed case of this problem...I'm not sure how widespread this problem is. Can you give me an estimate of how many posts you have, and anything else that may characterize your blog? Perhaps a copy/paste of the plugins you have enabled.

-Rich

P.S. You could still set up the manual cron job - it just means that no one would ever get any errors, and no one would ever have to wait for the XML to be generated (since the cron job would be doing the 'waiting)

[Lincoln]

I have 631 posts so far. I tried 700 but that didn't take for some reason, as well as 1000. I even tried 0, but though I didn't get any errors no featured articles showed, obviously.

I've attached a screenshot of all my plugins. I'm pretty sure it's only the WPG2 plugin causing the conflict, so if you hear of other similar issues, ask them if they're using this plugin, or maybe another similar gallery script.

In the meantime I'll keep the setup as is for now, the popular posts option is starting to grow on me.

[rinogo]

Thanks for the update, Lincoln. I'll let you know if we make any additional discoveries on our end!

Have a great day,
-Rich

[Lincoln]

No problem. So far everything is working good. If I change my mind and decide to change to recent posts Ill give the php workaround a try and post the results.

[rinogo]

Sounds great, Lincoln! We haven't heard from you for a while, so we hope everything is going great.

Happy blogging,
-Rich