tahtu

… ah, I found the reason, why WordPress shows the update problem warning to me:

function nw_pre_site_transient_update_core() {
return NULL;
}
add_filter(‘pre_site_transient_update_core’, ‘nw_pre_site_transient_update_core’);

… the result must be false instead of null.

So right now, I don’t see the QM area inside the admin bar highlighted further more.

But the idea with accepting and hiding problems is still not bad, I believe. Maybe other developer have problems…

I have an idea, how you could serve me and improve the QM:

Implement a feature to hide errors, warnings and hint.

Like mentioned before in this topic, I get always a special problem inside the admin panel. QM shows me located here:
wp-includes/update.php:155

Like mentioned before by you, this is a problem of WordPress, which you still reported several years before. So there is not a lot of hope to, that it will be fixed soon.

But you could let me accept and hide this error and not show it to me again later on.

Right now, I have a second problem: A warning about “compact(): Undefined variable: groupby” in wp-includes/class-wp-comment-query.php:853. Without analyzing this problem further more, I believe it could be a problem of WordPress too. (But maybe it based on a problem from me, I know. ?? )

So if I could mark that problem as accepted, I would not longer see the QM area inside the admin bar highlighted. So I would detect new problems better, since right now, I have to search from them. They are not show to me otherwise.

… just my idea, I wanted to share with you…

• This reply was modified 5 years, 5 months ago by tahtu.

Today I installed Relevanssi to compare it with Better Search. Relevanssi is much more complex and has a lot of additional features. But Better Search is much smaller and let do MySQL the relevance calculation. Both solutions have advantages.

So in the moment, it’s not easy for my to show the used SQL query to you, since I uninstalled Better Search for the moment.

But like I suggested to use the WP_Query class to you inside an other topic in this forum a few minutes before, I suggest to you: Do not investigate more time into your SQL generation at all. You waste a lot of time with this and you never can offer all the same features like WP_Query can do. Additional Webmaster like me should know the WP_Query implementation and its filtering with its pre_get_posts action.

Because of this, I will not support you with your own SQL generation, even I have installed the Query Monitor and I know SQL good from previous jobs.

The disvantage of your own SQL gereration implementation forced me to analyse your PHP code to figure out, how I can implement my search restriction to some categories. After that, I had to find out, how WordPress implemented the category <-> post relationship and wrote more SQL code, than I could do this with the well documented WP_Query class.

So with your own SQL generation, you not just wasted a lot of your time, you wasted also a lot of my time. Because of this, I let you know so detailed my knowledge about the WP_Query class to not to waste further time.

I hope you understood my suggestions, and why I don’t support you with your question.

I still don’t know, what is better: Better Search or Relevanssi. Since Better Search let do MySQL the job of calculating and apply it with, I believe Better Search has advantages againt Relevanssi too.

But maybe I wrong… ??

With the pre_get_posts filter of the WP_Query class, I can add filters for the SQL query, which the WP_Query will generate. An example from my site:

function my_pre_get_posts( $query ) {
if ( $query->is_search() )
$query->set( ‘cat’, 1 );
}
add_action( ‘pre_get_posts’, ‘my_pre_get_posts’ );

With this code inside my functions.php of my child theme, the default WP seach will only show post of the category with the term_id 1. So WP_Query generates the related WHERE clause for me and adds the needed wp_term_relationships table to the FROM clause.

Btw: This code works fine with Relevanssi too.

So this is an easy way for me to restrict the search to one category only. More information about the WP_Query class you can find here: WP_Query. The description of the category restriction you can find here on the same page. So you can find out, this is a very complex way to restrict all kinds of searches.

You could implement it by using the posts_fields and posts_search_orderby filters. Just all your MATCH ... AGAINST to the fields with the score alias and replace the whole ORDER BY clause with this score. That’s all and you could delete many of your code implementation. ??

About the Excerpt: I’m not sure, but it look like, Relevanssi does not implement the Excerpt too. I don’t understand this, since Imho Excerpt (content summaries) are much important for each post.

You could easily implent it inside you code by adding a this MATCH ... AGAINST part for the score calculation. If the authors of the post doesn’t fill them, it should not bother the Better Search plugin at all. But if the author filled them, the search result is more precise I think.

Ok, now I understood: The Better Search plugin creates the SQL query completely by it selfs. After I found out this, I’ve found a solution to limit the results to the categories, I want to enclose in the search.

But I still don’t understand, why you do so much work. Just add the “score” to the fields of the normal search query should work too. Ok, you have to change the ORDER BY clausel too. But both of it, you could implement with two small filters, I think. Why did you implement so much code?

Right now, I understood how you realized the relevance implementation: MySQL do this nearly completely. ??

But right now, I don’t understand, why you didn’t add the excerpt field into the score calculation too? It would by very few work for you, I believe. But it would be results in a better order of the result: The author of the post mostly wrote the Excerpt of the post as a summary of it. So if the search pattern works for it too, this shows more relevance, instead of the match s inside the content.

So my suggestion to you: Add the post_excerpt field with a MATCH … AGAINST too. Maybe with a “5” multiplyer (between the post_title and post_content).

Addition, I would prefer, if you would use the standard implementation of querying the posts with the WP_Query class. In that case, it would be easier for webmasters like me to modify the query with the pre_get_posts filter. In that case, I just could define categories with a $query->set( 'cat', 1, 2, 3 ) instead of writing my own SQL code with the additional wp_term_relationships table.

… nevertheless I’m happy about the Better Search plugin! Thanks a lot for your work.

• This reply was modified 5 years, 5 months ago by tahtu.

Resoleved

Thank you for your quick reply.

You are right: The problem based on my code. Until now, I didn’t really understand how QM put his area above my output. But it seems the body styles will be valid for it too…

Thanks a lot!

PS
QM is very helpful for me!

• This reply was modified 5 years, 5 months ago by tahtu.

Ok, you are not interested to implement what I asked about.

Nevertheless thanks a lot for your great software!

Thank you for your response.

In my case, I include the CSS into the HTML completely.

While doing this, AO could analyze the HTML code with regular expressions to detect the used classes. I think, this would not be a lot of work for you, isn’t it?

After this, you could do the same with the CSS code. And than you could apply only the used CSS definitions.

Ok, ok, this is not be implemented within a single day, indeed. But it would be possible, I think.

Maybe you take my ideas as a feature request for the future.

But I agree with you: This would take a lot of time while executing the matches. So maybe it would be senseful only, if an page cache like WP Total Cache is active.

Thank you, Frank, for your explaination!

Sorry, my mistake.

Thank you for your fast response.

• This reply was modified 5 years, 5 months ago by tahtu.
• This reply was modified 5 years, 5 months ago by tahtu.

Thank you John. With your profiling option I can find problems inside my code.

And with your thoughs about profiling, now I know you understand what people like me wants. ??

I aggree with you: It was a mistake to bother you with this issue. WP has to fix it.

Sorry!

I found the reason for the problem: Inside the “wp_posts” table, there was a value for “post_parent”.

I think this happened, because this single posts were formaly pages. I changed it with the “Post Type Switcher” plugin.

Now I’m unsure, if this is problem of Yoast or a problem of Post Type Switcher or my own problem. After I understood the problem, I solved it on my end by myself. But I let this issue unresolved, since I don’t know, if the developer of Yoast wants to know this problem…

Once again: I don’t need further assistance, for me this problem is solved.

This problem belongs to older posts only. Inside new posts, the cagegory is visible.

I checked the older posts: A category is selected.