Support » Plugin: Yet Another Related Posts Plugin (YARPP) » [Plugin: Yet Another Related Posts Plugin] YARPP not working for busy sites

  • wpt


    Hi mitcho,
    Your YARPP is an excellent plugin working well on most sites. I like it very much. But it seems not working well with busy sites. I tried to use it on a busy site ( Alexa ranking between 500 to 600 in the US), YARPP’s heavy query crashed mySQL server instantly. I searched online. Some other people experienced similar problems with busy sites. Since I was not able to find solutions online, I studied your YARPP files and made some changes that YARPP can be used on busy sites.

    Here are what I did:
    By default, YARPP builds cache/index by both front end when users view posts and back end when a post is saved or updated. First, I added an option switch by which users can choose to disable front end cache building and just keep back end cache building. YARPP still displays related links normally. Second, I added an Ajax function which can automatically build cache in the back end like one post per minute. This timed cache building in the back end will not overload the servers.

    With these changes, YAPPED is working well on the busy site.

    If you are interested in including these changes in your future version so YARPP can be used on busy enterprise sites, I can provide you the added codes in three of YARPP files.

    David Y.
    Austin, TX

Viewing 13 replies - 1 through 13 (of 13 total)
  • Plugin Author mitcho (Michael Yoshitaka Erlewine)


    Hi David,

    Definitely do post the code or email me the changes (, x=mitcho).

    I have recently worked with a few partners to test YARPP on busier sites in order to optimize it. The current beta, YARPP 3.4 beta 7 already includes very significant speedups in the core YARPP query. Some throttling similar to what you’ve described is now available as part of the YARPP Experiments plugin I’ve made public. I’d love to get your feedback on these:

    Note that YARPP 3.4 involves a huge amount of code refactoring… so merging your code (probably based on YARPP 3.3) in may not be trivial. But I’d really like to avoid introducing forks of YARPP for, for example, high traffic sites. Instead, I’d like to make sure the appropriate hooks exist in YARPP so that such modifications can be shipped as separate plugins… that’s part of what YARPP Experiments is about.

    Looking forward to hearing your comments. 🙂

    Plugin Author mitcho (Michael Yoshitaka Erlewine)


    Note also that there’s some info in the FAQ for YARPP on “less computationally intensive settings,” though these will become much less relevant with YARPP 3.4. Also, may I suggest following @yarpp on twitter… I recently put out a call to get feedback on busier sites, in fact:!/yarpp/status/134732827987156992



    Hi mitcho,

    Here are the added codes on YARPP Version 3.3.2. to add the automatic back end timed caching feature on YARPP.


    Step 1:
    add an option
    add following line in line 58 in includes.php (Deactivate and then reactive plugin to take effect.)
    ‘backend_caching_only’ => false,

    Step 2:
    add the switch to turn off front end cache building
    changed line 224 in magic.php to
    if (!$backend_caching_only) yarpp_cache_enforce($reference_ID);

    Step 3:
    add following ajax service function to the end of service.php
    function do_cache_one() {
    global $wpdb;
    check_ajax_referer( “nonceyyycache” );

    if (!$_POST[‘divpostid’]) {
    $id=$wpdb->get_var(“select min(reference_ID) from wp_yarpp_related_cache where reference_ID>0” ,0);

    if(!$id) $id = $wpdb->get_var(“select max(ID), count(ID) from $wpdb->posts as p where p.post_status = ‘publish'”,0);

    else {$id = $wpdb->get_var(“select ID, post_title from $wpdb->posts where ID < $id and post_status = ‘publish’ and ifnull(post_title,”) != ” order by ID desc limit 1″,0);
    } else {
    $id = $_POST[‘divpostid’];

    $sql = “select post_parent from $wpdb->posts where ID=’$id'”;
    $parent_ID = $wpdb->get_var($sql);

    if ($parent_ID != $id and $parent_ID)
    $id = $parent_ID;

    // $id must be numeric to be passed to this function
    $id = intval($id);

    $result = yarpp_cache_enforce($id,true);

    $id = $wpdb->get_var(“select ID, post_title from $wpdb->posts where ID < $id and post_status = ‘publish’ and ifnull(post_title,”) != ” order by ID desc limit 1″,0);

    echo $id;
    add_action( ‘wp_ajax_cache_one’, ‘do_cache_one’ );

    step 4:
    add Cache Building options and ajax code in the YARPP setting page:
    add following codes in line 285 in options-meta-boxes.php

    class YARPP_Meta_Box_Cache extends YARPP_Meta_Box {
    function display() {
    global $yarpp_myisam;
    <p><?php _e(‘By default (when unchecked), YARPP builds cache by both front end when users view posts and back end when a post is saved or updated. For most servers, the default setting is recommended.
    For busy servers who can not use YARPP\’s default setting, we\’ve added a new back end only cache building option for you. Just check the check box below and click “Update options” button. Then, you build cache here using the server friendly caching method from the back end only. Click “Start Auto Process” button to automatically build cache one post per minute. The process will stop when all posts are processed. Or you can click “Stop Auto Process” button to stop the process and resume by clicking “Start Auto Process” button again. The cache table will be automatically built from the highest post ID to the lowest post ID.’,’yarpp’);?> </p>

    <table class=”form-table” style=”margin-top: 0; clear:none;”>

    $this->checkbox(‘backend_caching_only’,__(“Disable cache building from front end. Keep back end cache building.”,’yarpp’));

    $nonce = wp_create_nonce( ‘nonceyyycache’ );
    <script type=’text/javascript’>

    function myajax() {
    var myid=jQuery( ‘#divpostid’ ).val();
    type: “post”,url: “admin-ajax.php”,data: { action: ‘cache_one’, divpostid: escape( jQuery( ‘#divpostid’ ).val() ), _ajax_nonce: ‘<?php echo $nonce; ?>’ },
    success: function(data){

    if (data <=0) {
    alert(“process finished at “+ data);
    jQuery(“#formstatus”).html(“Stoped at ID ” +data+” at ” +new Date());
    return false;


    var ycount=jQuery( ‘#ycount’ ).html();
    var yycount= Number(ycount)+1;
    if (yycount==1) jQuery(“#first”).html(data);


    return false;

    var t;
    var x;
    var timer_is_on=0;

    function timedCount() {
    x=60000; // 60 seconds x1000 span time
    t=setTimeout(“timedCount(), myajax()”, x);

    function doTimer() {
    if (!timer_is_on) {



    function stopCount() {


    jQuery(“#formstatus”).html(“Stoped at ” +new Date());

    <style type=’text/css’>
    #loading { clear:both; background:url(images/loading.gif) center top no-repeat; text-align:center;padding:33px 0px 0px 0px; font-size:12px;display:none; font-family:Verdana, Arial, Helvetica, sans-serif; }
    #stop { background:yellow;display:none; border-color:blue;-moz-border-radius: 3px; border-width:1px;border-style:solid; }

    <div class=”wrap”>
    <button type=”button” id=”onepost” onclick=”myajax()”>Process One Post</button>
    <button type=”button” id=”start” onClick=”myajax(); doTimer()” />Start Auto Process</button>
    <button type=”button” id=”stop” onClick=”stopCount()” />Stop Auto Process</button>
    <p>Post ID: <input type=’text’ name=’divpostid’ id=’divpostid’ value=” /></p>

    <span id=’first’></span> – <span id=’last’></span>
    Item processed: <span id=’ycount’>0</span>
    <div id=’formstatus’></div>
    <div id=’loading’>Caching in Process. Click Stop button to stop!</div>


    add_meta_box(‘yarpp_cache_building’, __(‘”Cache Building” options’,’yarpp’), array(new YARPP_Meta_Box_Cache, ‘display’), ‘settings_page_yarpp’, ‘normal’, ‘core’);

    Plugin Author mitcho (Michael Yoshitaka Erlewine)


    Hi wpt,

    Thanks for sharing this. What you’ve implemented is essentially equivalent to what I have in the YARPP Experiments plugin. Please try to use the YARPP Experiments plugin and see if that works for you. I’d love to get your feedback. Thanks!



    I was not able to get yarpp-experiments working. It gave me a waring when I updated a post from the back end:
    Warning: Cannot modify header information – headers already sent by (output started at \wp-content\plugins\yarpp-experiments\yarpp-experiments.php:223) in \wp-includes\pluggable.php on line 934

    I need more time to test it though.

    My comment to your YARPP Experiments at this time is that making the setting page simpler, easier to use for end users.

    Thanks for letting me know about that error. I just fixed it in the latest development build:

    Making the settings page simpler has been a big priority for me, which is why the “Relatedness” and “Pool” options are now hidden by default. This is also why options like throttling are currently relegated to the YARPP Experiments plugin. If I learn through Experiments that there are good options to have, though, I may move them into YARPP proper in the future.

    Hi Mitcho — I tried 3.4b10 + experiments because I run a fairly busy site as well and often disable yarpp during peak times — so I wanted to check out the throttling and more efficient operation you’re working on.

    However, shortly after installing I noticed that many posts were running the exact same set of related post links (and they weren’t particularly relevant). I also couldn’t get yarpp screen option settings to stick — some javascript problem perhaps.

    I rolled back to 3.3.3 and everything returned to expected operation.

    Anyway, I realize 3.4 is beta, so no worries, just wanted to let you know what I saw. I appreciate your continued development of this very useful plugin.

    3.4 is now at Release Candidate, with 3.4b10 being the last beta, so if this is a new issue it would be serious. What browser were you using to access your admin? Which options weren’t sticking? If you could help me reproduce this issue, that would be great.

    Hi Mitcho, I tried to report this via twitter, but not sure if you got it.

    I upgraded from 3.3.3 to 3.4b10. Things were running much faster! However, the settings page seemed a bit messed-up. For example, I could see the ‘disallow by category’ selection I’ve made inside the Pool, but could not add any more categories. Maybe these options were removed from the pool altogether?? I think there were a couple of other odd things on the settings page, but I since went back to 3.3.3

    (not trying to hijack the thread, just thought you’d be interested to know)


    @yoav.aner thanks. That sounds like there’s a problem with the JavaScript/AJAX on the page. Does your browser’s error console show any errors? Are you having trouble with other JavaScript on the page, like collapsing some of the boxes or seeing the menus?

    I tried it again and I see that I’m getting a 404 on /wp-content/plugins/yet-another-related-posts-plugin/js/options.js?ver=3.4b10

    …updating to 3.4.2 (as the settings page suggested) seemed to have resolved this js issue. Would have to check how other things are working though

    Great! Glad that’s resolved.

Viewing 13 replies - 1 through 13 (of 13 total)
  • The topic ‘[Plugin: Yet Another Related Posts Plugin] YARPP not working for busy sites’ is closed to new replies.