ribakker

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.

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 have fixed this problem a few minutes ago, in the 1.4.1 version.

Somehow the text you enter in the TinyMCE editor is filtered when it gets saved in the database (i.e. strong-tags are preserved, paragraph tags and br-tags are changed into newlines).

My solution is as follows:

== 1 ==
In rich-text-tags.php search for function kws_rt_tinymce_settings() and add the following two lines under line 182:

$array['convert_newlines_to_brs'] = true;
$array['theme_advanced_buttons1'] = 'bold,italic,strikethrough,|,bullist,numlist,blockquote,|,justifyleft,justifycenter, justifyright,|,link,unlink,wp_more,|,spellchecker,fullscreen,wp_adv,|,code';

The first line is a TinyMCE setting that let’s TinyMCE convert newlines (from database) into br-tags. That’s just one part of the problem.

== 2 ==
In kws_rt_taxonomy.js comment the following two lines: 22 and 25 (the Toggle Rich Text Editor button, that is). That’s the button that causes mayham. In the previous step we have added the default TinyMCE code button to toggle HTML source view.

I’m still looking for a solution to add the ‘Wysiwyg/HTML’ tabs to the upper right of the editor (I think that’s a nicer solution, but so far this works good enough).