[Plugin: Solr for WordPress] Load All Posts not indexing

I have done some research that I’d like to share with you. It is possible that my conclusions are incorrect; that’s probably because I’m still a bit of WP newbee.

First of all, I had already discovered that there was something funny with the ‘Load All Posts’ option on the settings page. So I started doing some research on that one.
The moment you hit the ‘Load All Posts’ (Execute) button, a form gets posted. The form posts to the URL options-general.php?page=solr-for-wordpress/solr-for-wordpress.php. The S4W module has implemented a hook called ‘admin_init’ that runs the s4w_options_init() function when entering the adminpage. So I looked in the aforementioned function.
This function holds the following code (among other code):

$method = $_POST['method'];
    if ($method === "load") {
        $type = $_POST['type'];
        $prev = $_POST['prev'];

        if ($type === 'post' ) {
            s4w_load_all_posts($prev);
            exit;
        } else if ($type === 'page') {
            s4w_load_all_pages($prev);
            exit;
        } else {
            return;
        }
    }

The strange thing is, that the POST values ‘method’, ‘type’ and ‘prev’ don’t exist in the POST value. Some of this logic relies on the name of the submit button being sent through the POST value. But because the name attribute of the submit button contains an underscore, this value doesn’t exist in the POST value. So I have re-arranged this HTML form and PHP code a bit.

Then I went to the s4w_load_all_posts() function. I’m working on a multisite installation. So this function first collects a list of all blogs ID’s and then loops this list. In this loops it collects a list of blog posts. This query generates an error.
It constructs the following query:

$postids = $wpdb->get_results("SELECT ID FROM {$wpdb->base_prefix}{$bloginfo}_posts WHERE post_status = 'publish' AND post_type = 'post' ORDER BY ID;");

Queries like the following are being fired:

SELECT ID FROM wp_2_posts WHERE post_status = 'publish' AND post_type = 'post' ORDER BY ID;

That seems okay. But it runs the following query for blog number ONE:

SELECT ID FROM wp_1_posts WHERE post_status = 'publish' AND post_type = 'post' ORDER BY ID;

While table ‘wp_1_posts’ doesn’t exist. The first blog has no such table names. So I have rewritten the creation of this query a bit.

Like I said, it’s possible that I’m making wrong assumptions and conclusions or maybe these are in fact bugs. In both cases I’d like to hear from you.

I’ve just found out why the ‘Execute’ button was not working. There was a JavaScript error on this page. Shoot, I should have noticed this a while earlier… In solr-for-wordpress.php starting at line 1266 there is this pieca code:

$j('[name=s4w_postload]').click(function() {
            $j(this).after($percentspan);
            disableAll();
            doLoad("post", null);
            $j(this).preventDefault();
        });

The preventDefault() call somehow doesn’t work. So I have temporarily replaced this with ‘return false;’. This works! So now the indexing is triggered correctly.

All this, including what was discussed in my previous posts, counts for the indexing of pages aswell.