korynorthrop

I was able to get rid of one of these undesired posts from the search results by returning an empty string for it’s $post_content in the relevanssi_post_content filter. So, something is working, now to figure out why I’m not able to get the other filters to work properly….Do you have any other ideas of how to troubleshoot this?

Yes, the relevanssi_block_to_render function is returning null for the desired blocks, which I verified by PHP error_log messages (e.g. right before the return null; I have this error_log( 'Relevanssi: Returning null for block: ' . $block['blockName'] ); and I see this printed out in the PHP log quite a bit as expected).

Using the relevanssi_post_content hook with a priority of 20, I am outputting the $post_content of one of the posts that shouldn’t be indexed because the only place the search term shows up is in one of the custom blocks that is supposedly returned null by the previous hook. However, when I look at the $post_content that is printed to the error log, I still see the unwanted blocks and the search term content inside those block’s markup.

@msaari thanks for the quick reply, I already did that to ensure that the blocks were properly detected (I logged the name of the block to the PHP error log in those Relevanssi hooks). The names are correct (I shortened them in this support ticket for brevity’s sake, but an example of the full block name is “acf/rcp-faqs” and that is what gets printed in the error_log when I checked that I had the right names).

Thanks again for the quick support. I’ll leave the fix in place on our website for now and change it back if I start noticing any weird behavior. I went ahead and made a comment in the Github issue that you referenced earlier, if that helps build your case to making the change.

I can confirm that changing the post watcher to listen on wp_after_insert_post worked as desired.

Will do, can you confirm that it’s this save_post hook that I’d be replacing?

Are you saying to change the save_post hook in WP Search with Algolia codebase to wp_after_insert_post as mentioned and referenced above in the Github issue?

Well that’s definitely fortuitous for me that you already have this kind of behavior on your mind. I hooked into the algolia_watch_post_meta_keys filter and had some success with a caveat.

The WPML language information that I add to each record in our Algolia index is fetched using WPML’s wpml_post_language_details hook which pulls metadata from different WPML database tables, not from the standard postmeta table (the main method that is called is here). So, I couldn’t add any new metakeys to the array of keys in the algolia_watch_post_meta_keys filter. However, there are a few WPML metakeys that exist in the postmeta table, so I used one of them (_wpml_word_count) to serve as a proxy, thinking that this metadata record would get updated around the time the other WPML language metadata is set. That ended up being true, new posts that I create get added to our Algolia index with the proper WPML language attributes.

The caveat is, when I duplicate a new post from English (our site’s default language) into another language on the site, that duplicate page gets pushed to our Algolia index without any of the language data set. When I eventually make an update to that duplicate page (e.g. translate it into the target language or change the slug or do something) then the proper language attributes get assigned to the record.

I think I figured out what’s going on and why I thought that the auto-indexing of new posts wasn’t occurring. We’re running a multilingual site using WPML. All of our posts share the same Algolia index (i.e. they are not separated by language). We add extra WPML language metadata to each post in the Algolia index via the algolia_post_shared_attributes and algolia_searchable_post_shared_attributes hooks.

The metadata that gets added above is an array, which includes a language code and locale. We created a facet using the WPML locale via the algolia_searchable_posts_index_settings and algolia_posts_index_settings hooks so that search results on our website are only shown if the indexed record’s wpml.locale value matches the current language that they’re viewing our website in.

Where I think the issue is happening is that the indexing of the newly created post happens before the save_post tasks that WPML is doing, which means the array of custom WPML metadata being pushed with the new post to our Algolia index is empty.

I was searching in our Algolia index for newly created posts (using a filter for English pages) and nothing came up. However, when I removed that filter and searched through all pages, the new post was there, with null values for the WPML attributes.

So….after that long background information, is there a way to delay the save_post actions that WP Search With Algolia runs so that they happen after WPML assigns the appropriate language data to the new post?

Thanks for pointing me to the Github code. Seems like you have it all accounted for. It’s not something we’ve consistently seen, it might just be a fluke. We have an existing page that was updated and it was no longer in our index. I’ll keep an eye out for any future anomalies or examples of the indexing not working as expected. I appreciate the quick reply!

I also want to let you now that there still are some PHP warnings related to your plugin that I see in our debug.log

[14-Sep-2023 16:05:08 UTC] WordPress database error You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ')' at line 3 for query SELECT quiz_id, question_id, answer_array, question_answer_info, question_type_new, question_settings
				FROM wp_mlw_questions
				WHERE question_id IN () made by require('wp-blog-header.php'), require_once('wp-includes/template-loader.php'), include('/themes/twentytwelve/page.php'), get_template_part, locate_template, load_template, require('/themes/twentytwelve/content-page.php'), the_content, apply_filters('the_content'), WP_Hook->apply_filters, do_shortcode, preg_replace_callback, do_shortcode_tag, QMNQuizManager->display_shortcode
[14-Sep-2023 16:05:38 UTC] PHP Warning:  Undefined array key "type" in /path-to/our-website.com/wp-content/plugins/quiz-master-next/php/classes/class-qmn-plugin-helper.php on line 1046
[14-Sep-2023 16:05:38 UTC] PHP Warning:  Undefined array key "type" in /path-to/our-website.com/wp-content/plugins/quiz-master-next/php/classes/class-qmn-plugin-helper.php on line 1046
[14-Sep-2023 16:05:38 UTC] PHP Warning:  Undefined array key "type" in /path-to/our-website.com/wp-content/plugins/quiz-master-next/php/classes/class-qmn-plugin-helper.php on line 1046
[14-Sep-2023 16:05:38 UTC] PHP Warning:  Undefined array key "type" in /path-to/our-website.com/wp-content/plugins/quiz-master-next/php/classes/class-qmn-plugin-helper.php on line 1046
[14-Sep-2023 16:06:34 UTC] WordPress database error You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ')' at line 3 for query SELECT quiz_id, question_id, answer_array, question_answer_info, question_type_new, question_settings
				FROM wp_mlw_questions
				WHERE question_id IN () made by require('wp-blog-header.php'), require_once('wp-includes/template-loader.php'), include('/themes/twentytwelve/page.php'), get_template_part, locate_template, load_template, require('/themes/twentytwelve/content-page.php'), the_content, apply_filters('the_content'), WP_Hook->apply_filters, do_shortcode, preg_replace_callback, do_shortcode_tag, QMNQuizManager->display_shortcode

@sumitsanadhya it seems that updating the QSM plugin to version 8.1.15 and adding your code snippet to the functions.php file worked. I successfully activated the QSM plugin without getting the critical error. I am able to access WP Admin while your plugin is active and I was able to take a quiz on the front-end.

What does that code snippet do, exactly?

Thank you for your reply. Below is the fresh debug.log output. I removed our actual server path for security purposes.

[08-Sep-2023 16:29:24 UTC] WordPress database error Duplicate entry '' for key 'unique_id' for query ALTER TABLE wp_mlw_results ADD UNIQUE (unique_id) made by require_once('wp-admin/admin.php'), do_action('admin_init'), WP_Hook->do_action, WP_Hook->apply_filters, QSM_Install->update[08-Sep-2023 16:29:24 UTC] PHP Fatal error:  Uncaught TypeError: Cannot access offset of type string on string in /real-path/removed/forsecuritypurposes.com/wp-content/plugins/quiz-master-next/php/classes/class-qsm-migrate.php:148Stack trace:#0 /real-path/removed/forsecuritypurposes.com/wp-content/plugins/quiz-master-next/php/classes/class-qsm-install.php(2161): QSM_Migrate::fix_duplicate_questions()#1 /real-path/removed/forsecuritypurposes.com/wp-includes/class-wp-hook.php(310): QSM_Install->update()#2 /real-path/removed/forsecuritypurposes.com/wp-includes/class-wp-hook.php(334): WP_Hook->apply_filters()#3 /real-path/removed/forsecuritypurposes.com/wp-includes/plugin.php(517): WP_Hook->do_action()#4 /real-path/removed/forsecuritypurposes.com/wp-admin/admin.php(175): do_action()#5 /real-path/removed/forsecuritypurposes.com/wp-admin/plugins.php(10): require_once('/homepages/24/d...')#6 {main}  thrown in /real-path/removed/forsecuritypurposes.com/wp-content/plugins/quiz-master-next/php/classes/class-qsm-migrate.php on line 148[08-Sep-2023 16:29:31 UTC] WordPress database error Duplicate entry '' for key 'unique_id' for query ALTER TABLE wp_mlw_results ADD UNIQUE (unique_id) made by require_once('wp-admin/admin.php'), do_action('admin_init'), WP_Hook->do_action, WP_Hook->apply_filters, QSM_Install->update[08-Sep-2023 16:29:31 UTC] PHP Fatal error:  Uncaught TypeError: Cannot access offset of type string on string in /real-path/removed/forsecuritypurposes.com/wp-content/plugins/quiz-master-next/php/classes/class-qsm-migrate.php:148Stack trace:#0 /real-path/removed/forsecuritypurposes.com/wp-content/plugins/quiz-master-next/php/classes/class-qsm-install.php(2161): QSM_Migrate::fix_duplicate_questions()#1 /real-path/removed/forsecuritypurposes.com/wp-includes/class-wp-hook.php(310): QSM_Install->update()#2 /real-path/removed/forsecuritypurposes.com/wp-includes/class-wp-hook.php(334): WP_Hook->apply_filters()#3 /real-path/removed/forsecuritypurposes.com/wp-includes/plugin.php(517): WP_Hook->do_action()#4 /real-path/removed/forsecuritypurposes.com/wp-admin/admin.php(175): do_action()#5 /real-path/removed/forsecuritypurposes.com/wp-admin/plugins.php(10): require_once('/homepages/24/d...')#6 {main}  thrown in /real-path/removed/forsecuritypurposes.com/wp-content/plugins/quiz-master-next/php/classes/class-qsm-migrate.php on line 148[08-Sep-2023 16:29:55 UTC] WordPress database error Duplicate entry '' for key 'unique_id' for query ALTER TABLE wp_mlw_results ADD UNIQUE (unique_id) made by require_once('wp-admin/admin.php'), do_action('admin_init'), WP_Hook->do_action, WP_Hook->apply_filters, QSM_Install->update[08-Sep-2023 16:29:55 UTC] PHP Fatal error:  Uncaught TypeError: Cannot access offset of type string on string in /real-path/removed/forsecuritypurposes.com/wp-content/plugins/quiz-master-next/php/classes/class-qsm-migrate.php:148Stack trace:#0 /real-path/removed/forsecuritypurposes.com/wp-content/plugins/quiz-master-next/php/classes/class-qsm-install.php(2161): QSM_Migrate::fix_duplicate_questions()#1 /real-path/removed/forsecuritypurposes.com/wp-includes/class-wp-hook.php(310): QSM_Install->update()#2 /real-path/removed/forsecuritypurposes.com/wp-includes/class-wp-hook.php(334): WP_Hook->apply_filters()#3 /real-path/removed/forsecuritypurposes.com/wp-includes/plugin.php(517): WP_Hook->do_action()#4 /real-path/removed/forsecuritypurposes.com/wp-admin/admin.php(175): do_action()#5 /real-path/removed/forsecuritypurposes.com/wp-admin/index.php(10): require_once('/homepages/24/d...')#6 {main}  thrown in /real-path/removed/forsecuritypurposes.com/wp-content/plugins/quiz-master-next/php/classes/class-qsm-migrate.php on line 148[08-Sep-2023 16:29:57 UTC] WordPress database error Duplicate entry '' for key 'unique_id' for query ALTER TABLE wp_mlw_results ADD UNIQUE (unique_id) made by require_once('wp-admin/admin.php'), do_action('admin_init'), WP_Hook->do_action, WP_Hook->apply_filters, QSM_Install->update[08-Sep-2023 16:29:57 UTC] PHP Fatal error:  Uncaught TypeError: Cannot access offset of type string on string in /real-path/removed/forsecuritypurposes.com/wp-content/plugins/quiz-master-next/php/classes/class-qsm-migrate.php:148Stack trace:#0 /real-path/removed/forsecuritypurposes.com/wp-content/plugins/quiz-master-next/php/classes/class-qsm-install.php(2161): QSM_Migrate::fix_duplicate_questions()#1 /real-path/removed/forsecuritypurposes.com/wp-includes/class-wp-hook.php(310): QSM_Install->update()#2 /real-path/removed/forsecuritypurposes.com/wp-includes/class-wp-hook.php(334): WP_Hook->apply_filters()#3 /real-path/removed/forsecuritypurposes.com/wp-includes/plugin.php(517): WP_Hook->do_action()#4 /real-path/removed/forsecuritypurposes.com/wp-admin/admin.php(175): do_action()#5 /real-path/removed/forsecuritypurposes.com/wp-admin/index.php(10): require_once('/homepages/24/d...')#6 {main}  thrown in /real-path/removed/forsecuritypurposes.com/wp-content/plugins/quiz-master-next/php/classes/class-qsm-migrate.php on line 148

@sumitsanadhya thanks for your reply. Well, from my perspective it still seems like a QSM issue. When I disable all other plugins, enable the default 2023 WordPress theme, and activate your plugin, I get the critical error. When your plugin is disabled it goes away. There are no other plugins activated and no customizations on the theme. So, really there’s nothing else I can point to except your plugin being the cause of the error. So how can we move forward?

[ Please do not bump. ]

Can I upload/send it to you somehow? I don’t want to post it on this forum since it has server information in it.