scmsteve

It has been a while, and the action scheduler entries have not been re-created, so I think this resolved it.

Yes, under the Robots Meta we have the following set:

No Index
No Follow
No Archive
No Image Index
No Snippet

I will again remove the pending scheduled actions and try your suggestion to rebuild the index.

I only want to disable the indexing of the bbPress replies, not everything. How is this accomplished?

We have the replies set to noindex, so I don’t even see how the SearchIndex thing is related. Please explain.

• This reply was modified 2 years, 8 months ago by scmsteve.

I did remove them, but why does it keep re-creating them? How can this be shut off?

Update: I found it is adding it to our /blog/ page. So at least it appears on a page that should be in our sitemap so Google should find it. So the reason Google is not scanning must be something else.

@rankmathteam This is not resolved.

Actually, they ARE from your plugin.

The Hook is:
rank_math/analytics/get_inspections_data

Argument:
0 => ‘/forum/reply/560199/’

Group is:
rank_math/analytics/get_inspections_data

That is your plugin, your code, not someone else’s. So what is the purpose of those 127K+? I assumed they were due to the initial setting of scanning the replies in bbPress, because looking at that post_id it is post_type “reply”.

If we are no longer going to index bbPress replies (turned it off now in the UI), can these scheduled actions be deleted?

It isn’t resolved, someone was going to come back to this and let me know when the problem was corrected.

Ok, My last post because I think this may resolve it. I did not set this up, it was set up quite a long time ago by someone else, but in just revisiting the topic of putting the wp-config.php in a parent folder, they all suggest that setting the ABSPATH (at the bottom, and if it was not already set) in that file should reference the actual document root, and in our case it was returning the location of the wp-config.php file itself. Maybe the way that WordPress normally loads things it defines it properly before loading our wp-config.php file, but when called directly by your ajax.php file it was not. Setting this path properly seems to resolve the issue.

Oh, I removed the @ from the require statement and received the error…

We have our wp-config.php one directory above the public_html directory, as supported by WordPress. So when it tries to load the wp-config.php it is looking for wp-settings.php in that same directory which is not found.

If I moved our wp-config.php to inside the public_html directory, then it works, but for security (however small it is) we do not want it placed there, and so far it has never caused us problems with other plugins.

I put a temporary php file in the same directory in your plugin, and I can call that and it executes, so it is not a permissions/restriction problem. I duplicated portions of your code into that file to verify that your logic is properly finding the wp-config.php and wp-load.php files.

If I try to execute “@require( $config_file )”, as you do in your code, I get the 500 error also. So it is that line that is causing the problem, which may also be why I am seeing no debug log output because it hasn’t initialized yet?

If I fire up a WP-CLI session and issue that @require with the file path, I get a return value of 1 which should indicate success, so by itself that is not the issue.

I also find it interesting that I see this on two test sites running in separate droplets at Digital Ocean as well as our main site running on an entirely different hosting provider, so it seems it is maybe not a specific host configuration issue.

I am not correlating any errors to it. I see those in the webserver logs, but I don’t know the exact action that is causing them to duplicate it.

I did try a get request on that and I get a 500 response code, this is in the webserver log:

“GET /wp-content/plugins/ti-woocommerce-wishlist-premium/includes/api/ajax.php HTTP/1.1” 500 0 “-”

But there is nothing logged to the PHP error log. If I can produce some output I will come back and post it.

What was your solution?

Maybe before you build your query/queries, you could undo their filter and add it back after you have your query built?

if ( class_exists( 'WC_Tab_Manager_Search' ) ) {
	remove_filter( 'posts_clauses', 'WC_Tab_Manager_Search::modify_search_clauses', 20, 2 );
}

if ( class_exists( 'WC_Tab_Manager_Search' ) ) {
	add_filter( 'posts_clauses', 'WC_Tab_Manager_Search::modify_search_clauses', 20, 2 );
}

Just a thought, unsure if there is a cleaner way to handle it. Maybe also catch the result of the remove_filter() call so you know if it was present at all and only selectively add it back if it was there to begin with?

• This reply was modified 3 years ago by scmsteve.

Further, this seems to not be (at least entirely) your fault. ??

That field is added to the search query by the “WooCommerce Tab Manager” plugin when you have it set to make the product tabs searchable. They integrate with the generic WordPress search, and have a special case for Relevanssi….

https://woocommerce.com/document/tab-manager/#section-10

I am not sure how you are building the query such that the plugin feels it needs to inject this into it, but that would resolve the issue. When I turn that “feature” off, the query is quite responsive.

More if I find out how to resolve it with the setting still enabled for site search.