alex.ciarlillo

Created pull request for the recommended changes here: https://github.com/bonny/WordPress-CMS-Tree-Page-View/pull/5

The plugin does not throw any errors and appears to work, but currently my dev & test site have too many pages and forms for me to accurately test the changes. I’m not even entirely sure what steps would trigger the bug. I will try to create a stripped down dev environment for testing but if anyone else can test, please clone from my repo and do so.

Another issue I noticed is that the plugin is not using plugins_url(), but rather a hard coded string to determine the directory to load scripts and styles. I see there is another PR to fix this which has not been merged. So if you are going to clone my repo for testing make sure to rename the directory to ‘cms-tree-page-view’.

Great to hear. Cannot wait to give it a try.

thanks

Here is the more complete code. The search parameter is set in the args array:

// setup query args
            $args = array('s' => $_POST['query'],
                'post_type' => $post_type,
                'post_status' => array('publish')
            );

            $query = new WP_Query($args);

            if(isset($post_tax)) {
            /*
                $args['tax_query'] = array(
                                        array(
                                            'taxonomy' => 'faq-topic',
                                            'field' => 'id',
                                            'terms' => array(321)
                                        )
                                    );
             */ 

                $query->query_vars['taxonomy'] = 'faq-topic';
                $query->query_vars['taxonomy_term'] = 'video'; // id: 321
            }

            relevanssi_do_query($query);

edit: in case you are wondering why this might appear unorthodox for a search results page it is because it is actually being used to return the results to an AJAX call in order to populate a drop down with search hints similar to Wikipedia.

It has been some time since I was able to revisit this. I was hoping you might still have a suggestion or two to get this working.

I tried your suggestion above with the following code:

$query = new WP_Query($args);

            if(isset($post_tax)) {
                // I have used debug output to determine I *am* in the loop
                $query->query_vars['taxonomy'] = 'faq-topic';
                $query->query_vars['taxonomy_term'] = 'video'; // id: 321 (tried both by slug and by id)

            }

            relevanssi_do_query($query);

No luck with that either.

Thanks for the quick reply. Just to clarify, I add these fields to the args array?

I have tried this:

if(isset($post_tax)) {
   $args['taxonomy'] = $post_tax;
   $args['taxonomy_term'] = "video"; // hard code for testing
}

and also using the term id:

$args['taxonomy_term'] = 321;

Still the same result (getting results that are not in the queried taxonomy).

edit: Just want to mention I *am* indexing “faq-topic” as a custom taxonomy. I was not previously so I went back changed it and re-indexed, re-tried all methods listed above with same results.

Problem seems to resolve itself when I uncheck “Expand Shortcodes in Post Content”. However, there is NO post content so I don’t see why this should make any difference.

I forgot to note I did a complete var_dump of the post object as well as all of it’s meta data and my search term is not anywhere to be found in there.

Ahh okay makes sense now. So I tried that and am still stumped.

I have set search breakdown to: %body% %title% %tags% %total% %score% %terms%

Here is a screenshot of the results: https://i.imgur.com/JcUmF.jpg

Here is the code I am using to display a single result for this custom post type. I wanted to include this to show the results are printing the_content() as well (which is empty for this custom post type). I cannot figure out where this mystery result is coming from.

21     <div id="post-<?php the_ID(); ?>" <?php post_class(); ?>>
 22         <div class="search-result">
 23             <span class="search-title">
 24                 <a href="<?php echo get_permalink($post->ID); ?>">
 25                     <?php echo get_post_meta($post->ID, '_sdinfo_lname', TRUE) . ', ' . get_post_meta($post->ID, '_sdinfo_fname
 26                 </a>
 27             </span>
 28         </div>
 29         <div class="entry-meta">
 30             <?php echo get_post_meta($post->ID, '_sdjob_title', TRUE); ?>
 31
 32             <?php foreach($depts as $d) : ?>
 33                 <div class="departments">
 34                     <?php echo $d->name; ?>
 35                     <div><?php echo get_post_meta($post->ID, '_sdjob_' . $d->slug . '-office', TRUE); ?></div>
 36                     <div><?php echo get_post_meta($post->ID, '_sdjob_' . $d->slug . '-phone', TRUE); ?></div>
 37                 </div>
 38             <?php endforeach; ?>
 39             <?php the_content(); ?>
 40             <?php the_excerpt(); ?>
 41             <?php var_dump($post); ?>
 42         </div>
 43     </div>

Maybe my coffee just hasn’t kicked in yet, but I’m not sure what you mean by %terms%. Is this a global variable? Is it a post variable? I tried var_dump() on the post and did not see anything relevant (pun intended). Or do you just mean query the post for all it’s taxonomy terms?

I am “debugging” from the search.php template.

Thanks

Okay first thing I did when I got in this morning was basically as you suggested. Instead of changing the REQUEST keys to something else though I simply commented out the lines below and did some error_log output to see what that values actually were. Surprisingly NOTHING showed up. I had the same thought yesterday and briefly looked through net requests in Firebug and didn’t see anything but did not have time to do the above. So now I’m even more perplexed. Then I figure it has to be one of my personal plugins. Disable them all, still no joy. THEN I said screw it and grepped my entire WP directory for references to relevanssi_build_index… and what did I find?

relevanssi/readme.txt: if (!wp_next_scheduled('relevanssi_build_index')) {
relevanssi/readme.txt:  wp_schedule_event( time(), 'daily', 'relevanssi_build_index' );
relevanssi/relevanssi.php:function relevanssi_build_index($extend = false) {
relevanssi/relevanssi.php:            relevanssi_build_index();
relevanssi/relevanssi.php:                      relevanssi_build_index(true);
role-scoper/admin/relevanssi-helper-admin_rs.php:               if ( function_exists( 'relevanssi_build_index' ) )
role-scoper/admin/relevanssi-helper-admin_rs.php:               relevanssi_build_index();

ROLE SCOPER!

Here is the offending file:

1 <?php
  2 class Relevanssi_Admin_Helper_RS {
  3     function rvi_reindex() {
  4         if ( function_exists( 'relevanssi_truncate_cache' ) )
  5             relevanssi_truncate_cache( true );
  6
  7         if ( function_exists( 'relevanssi_build_index' ) )
  8             add_action( 'shutdown', array( 'Relevanssi_Admin_Helper_RS', 'do_reindex' ) );
  9     }
 10
 11     function do_reindex() {
 12         ob_start();  // as of version 2.9.12, no way to rebuild index w/o outputting message
 13         relevanssi_build_index();
 14         ob_end_clean();
 15     }
 16 }
 17 ?>

So I have not yet figured out WHAT this is or WHY it is or how to disable it without hacking the code. But I just wanted to share my findings as soon as possible. I can’t believe I did not think to do this before. Should have been one of the first things I did, but it appears to be a completely un-documented piece of Role Scoper. I’m sure it is there for good reason and maybe I just missed it in the FAQ or Docs for role scoper (will go back and check shortly).

Huzzah!

Always glad to help. You provide a great plugin and reporting on the debugging and such I have to do anyway is the least I can do.

EDIT: Just to be clear, commenting out these lines from the role scoper file will fix the issue:

7         if ( function_exists( 'relevanssi_build_index' ) )
8             add_action( 'shutdown', array( 'Relevanssi_Admin_Helper_RS', 'do_reindex' ) );

Looked into the role-scoper code a bit more. Every time an object is saved it looks for the existance of ‘relvanssi_query’, then calls rvi_index() which hooks relevanssi_build_index() to ‘shutdown’ (called every time PHP execution is about to end). That’s roughly the chain of events leading the problem. Looked into the Role Scoper forums and found that this may be related to relevanssi indexing post excerpts and such which then allows for users to see content that Role Scoper would typically not allow since it is held in the index and not filtered through the usual search results. I’m not delving much further into the issue as we really use Role Scoper for editor roles and not public so this does not apply for us. I will continue to keep up with this thread and look forward to a solution that doesn’t require me to remember to comment those lines out every update ??

Okay I added error_logging to the first line of relevanssi_index_doc.

error_log('relevanssi_index_doc called');

Add New Post. Page did not hang (assuming because it is not processing a huge number of mail() calls).

ciarlill@staff:relevanssi$ grep 'relevanssi_index_doc called' ../../debug.log | wc
    333    1332   16983

So it appears that when addind a new post relevanssi_index_doc is being called for every post that *was* in the index. In my case 333 times.

EDIT: Also added a debug message to relevanssi_build_index. Looks like this is being called on ‘Add New Post’ also.

Okay some more info.

relevanssi_remove_doc query looks perfectly fine. It is getting the correct ID and being called at post creation on publish. The full creation of a post generates like 2-3 or so calls to this. Don’t think the problem is here.

relevanssi_index_doc is doing something crazy. I tried dropping a mail call in 2 places:

Beginning of functon

2154 function relevanssi_index_doc($indexpost, $remove_first = false, $custom_fields = false, $bypassglobalpost = false) {
2155     mail('[email protected]', 'RELEV INDEX CALLED', '');
2156     global $wpdb, $relevanssi_table, $post;
2157     $post_was_null = false;
2158     $previous_post = NULL;

Also after getting the post

2190     // Finally fetch the post again by ID. Complicated, yes, but unless we do this, we might end
2191     // up indexing the post before the updates come in.
2192     $post = get_post($ID);
2193     mail('[email protected]', 'RELEV INDEX CALLED', $post->ID);

Both times this seems to get called HUNDREDS of times. I had to restart Apache and I’m still clearing out my inbox and getting delayed mail. I’m afraid to approach debugging it with this method again but will try some other steps. When I would click ‘Add New’ the page would load but was still busy and would remain so until I closed the tab. Somehow adding the mail() call caused a side effect. I’m not sure if this side effect caused the 100’s of calls or if the 100’s of calls to this function all processing my mail() lead to the page hanging. Like I said I am going to continue to investigate but this is a pretty complex function and a large functional piece of relavanssi itself.

I cannot get an exact count of how many calls yet, but I have a hunch it might match the number of items previously in the index. In my case 333.

Any other ideas of where I could investigate?

Just got back to work on this site. Index was empty so I rebuilt: 333 documents in the index, highest post ID 7958. Viewing the table returns expected 18,682 rows. The results look pretty straightforward and accurate.

Add a new post. Documents in index: 1, highest post ID: 7979 (the ID of the new post). View the table: 1670 rows! all the document IDs are 7979, but I noticed a pattern:

1, 7979, 'uncategorized', 1, 4
2, 7979, 'ciarlill', 1, 5
3, 7979, 'ciarlill', 1, 1
4, 7979, 'test', 1, 1
5, 7979, 'test', 1, 0

This was repeated over and over. The post title was “ciarlill test” and the body was just “test” and it was categorized in “uncategorized”. Not sure why those 5 rows would repeat 334 times.

Rebuild the index again –
Documents in the index: 334 (coincidence??)
Highest post ID indexed: 7979

Viewing the table I get 18,687 rows. (+5 from the last index build) Just to check:

SELECT * FROM<code>www2-wordpress</code>.<code>wp_relevanssi</code> WHERE doc = 7979
14618, 7979, 'uncategorized', 1, 4
14619, 7979, 'ciarlill', 1, 5
14620, 7979, 'ciarlill', 1, 1
14621, 7979, 'test', 1, 1
14622, 7979, 'test', 1, 0

5 rows as expected, not 1670. So I think it is safe to say that something very strange is happening when new content is added. Let me know what other tests I can do or info I can provide to help.

I am having the same issue. Also version 2.9.12. Caching is disabled. Indexing 3-4 custom post types. I can provide more details if you let me know what would be useful.

I was curious about this also. We have a group who needs to receive emails anytime a new page is published, but they are not necessarily administrators as far as the WP roles are concerned. Right now they are in a group “Content Administrators” but people must select that group for notification each time they create a new page.