Maxime Michaud

I’ve reviewed the handbook, downloaded Slack, and submitted a request regarding my translations in the WordPressFr translation channel.
For your reference, I found this in the handbook that might help:
https://make.www.ads-software.com/polyglots/handbook/plugin-theme-authors-guide/pte-request/#plugin-theme-author-translation-review-pte-request

The 100% notification banner issue, it seems to persist, but it’s really low priority.

So, on a site with orders every minute like ours, it makes sense.

Normally, our site processes requests quickly, we have the computational power for it, and we have modified the standard behavior to do more at the same time because otherwise, we often fell behind on all tasks and it could lead to huge delays like hours and sometimes a day. We changed that thanks to: https://github.com/woocommerce/action-scheduler-high-volume

Yes, it doesn’t seem to come from Weglot based on its logs. I have an idea of some plugins that could be causing this, but it needs to be investigated more thoroughly. The plugins I suspect might need to be replaced eventually.

That said, it’s great that the Weglot logs have been resolved; it makes the logs a lot more visible ?? And no, I can’t deactivate it. I disabled Weglot in the night, but I won’t risk it with over 1000 orders per day for the others. And the staging is outdated at the moment.

About :

Also, how often would you recommend regenerating the trigram table to ensure it remains up-to-date?

–>

In the meantime, I noticed that the trigram generation continued. Upon inspecting the code, I found that the task was present because WooCommerce was updated, and the code confirms this as normal behavior. The only strange thing is that the message displaying the percentage remained at 100%, even though everything seemed done (no task). However, this is very minor and now gone.

So, this is a good thing ??

This concerns whether the FAQ mention about the meta key query is still valid.

I’ve created an issue regarding this, which you can view here: Issue #21.

In addition, I’ve submitted two pull requests related to continuous integration setup:

• Build: Add GitHub Actions workflow for build and archive – PR #19
• Feat(CI): Add Dependabot config for GitHub Actions daily updates – PR #20

Hello,

I’ve discussed the performance with the head of customer service, who manages over +50 support agents. She wrote back saying, “Hello Max, Yes, I confirm that it’s faster, and the agents also report the same. However, out of about a hundred orders I randomly searched yesterday, let’s say about 20 returned multiple results even though I used a specific number.“

This confirms that the searches are indeed faster, as I had experienced myself. However, this also highlights that the searches can sometimes be imprecise. Therefore, I suggest offering an option within the plugin’s settings that allows users to choose not to use the trigram for certain fields or to select a mode that prioritizes accuracy over performance, like IDs, names, or emails. This strengthens my idea of having a settings page for necessary exclusions, such as excluding IDs from the trigram to ensure precision.

Example on plugin settings page: Checkboxes to exclude certain types like ID, name, email, etc. It is crucial that ID searches remain as precise as they should be. She mentioned that even with a precise ID, it could yield multiple results. I imagine this is because the code searches for partial matches on three characters, even for IDs.

A note for those reading my review, as of today:
The situation may have improved by the time you read this review. Please take the time to check the references mentioned here and the FAQ. You can also check out the author’s article that easily summarizes what the plugin does: How Does It Work – Trigrams.

You can also see my questions, suggestions, and challenges concerning this plugin here:

• Enhancement suggestions for Fast Woo Order Lookup plugin
• Concerns on trigram table update and match accuracy in WooCommerce

Order Count Warning: The idea of an “Order Count Warning” is quite general; any method that could make this feature more precise would be valuable. Given my limited understanding of how this could be implemented in this context, it led me to think about replacing a simple order count with an “Order Complexity Check” to analyze the diversity and complexity of existing orders. Another possible approach could be “Data Density Analysis.”

Performance Suggestion: I’m unsure about the concrete implementation, but a performance simulation might work. This could involve sampling the store’s order data and running it through a mock trigram generation and search process to predict performance improvements.

Compatibility Alerts: I have submitted a pull request to add compatibility details for the plugin. Everything has been clearly outlined in the pull request, and you are free to adjust the versions if you prefer to enforce stricter requirements.

A bit more clarification regarding my previous message. I marked it as a support request because I genuinely want to ensure long-term, hassle-free usage is not problematic. I rarely use the feature (orders search) and receive very little technical feedback (unfortunately), so it usually takes me weeks to come across an issue (with luck).

I want to emphasize again that this is not a critical priority, and I’m very grateful that the plugin exists and works properly. The WordPress Performance Team isn’t very productive, though that’s just my opinion ??

Hello,

Well, I tested it in production (oops) a few minutes ago, it seems that the issue persists, but I don’t see what could also be using preg_replace. I deactivated the plugin, didn’t clear the object cache, but it seemed to be properly deactivated, and it doesn’t seem to be caused by that. Is there a way to isolate the logs differently?

Maybe it could be another plugin on your side. Did you find anything?

Great, I hope it’s going to work correctly. The plugin is enabled, and the generation is complete.

wp_fwol 6.4GB

• This reply was modified 2 months, 1 week ago by Maxime Michaud.

Hmmm, really useful indeed, I was talking about it with a colleague today. Customer service generally often searches for orders, very often using emails, and they don’t specify anything, which makes it very slow. This often ended up in the slow queries file in MariaDB.

SET timestamp=1724494260;
< ( wp_wc_orders.transaction_id LIKE '%cindyf\\_HIDDENDATA%' OR wp_wc_orders.billing_email LIKE 'cindyf\\_st>SELECT search_query_meta.order_idFROM wp_wc_orders_meta as search_query_meta
WHERE search_query_meta.meta_key IN ( '_billing_address_index','_shipping_address_index' )AND search_query_meta.meta_value LIKE '%cindyf\\__HIDDENDATA%'
GROUP BY search_query_meta.order_id
 )  OR
wp_wc_orders.id in (
        SELECT order_id FROM wp_woocommerce_order_items search_query_items WHERE
        search_query_items.order_item_name LIKE '%cindyf\\__HIDDENDATA%')
 ) ) GROUP BY wp_wc_orders.id ORDER BY wp_wc_orders.date_created_gmt DESC LIMIT 0, 100;

Hello,

To clarify, I am not a WordPress developer, but it appears that the str_replace function is being used specifically by Weglot. After updating the plugin (4.2.9), this log started to appear again and was the first noticeable one. While it could be a coincidence and potentially related to something else, it seems unlikely.

We will indeed need to contact support for another issue, which is more of an inconvenience regarding a translation exclusion. It would be great if you could review our latest logs, check this point, and get back to us with any insights.

Thank you for your assistance.

• This reply was modified 2 months, 1 week ago by Maxime Michaud.

No, this should not be disabled if the index is present. I can’t remember where the author mentioned why, but it seems to be to ensure that the changes persist without WordPress interfering. If you want to disable it, please disable the indexes.

Hello, thanks for the quick response, we’ve implemented it.

Unfortunately, it doesn’t seem to resolve the issue.
It only changed the log format, making it a bit harder to diagnose, but the issue remains similar.

[12-Sep-2024 07:04:51 UTC] PHP Deprecated:  strpos(): Passing null to parameter #1 ($haystack) of type string is deprecated in /var/www/*****/wp-includes/functions.php on line 7300
[12-Sep-2024 07:04:51 UTC] PHP Deprecated:  str_replace(): Passing null to parameter #3 ($subject) of type array|string is deprecated in /var/www/*****/wp-includes/functions.php on line 2189
[12-Sep-2024 07:04:51 UTC] PHP Deprecated:  strpos(): Passing null to parameter #1 ($haystack) of type string is deprecated in /var/www/*****/wp-includes/functions.php on line 7300
[12-Sep-2024 07:04:51 UTC] PHP Deprecated:  str_replace(): Passing null to parameter #3 ($subject) of type array|string is deprecated in /var/www/*****/wp-includes/functions.php on line 2189
[12-Sep-2024 07:05:25 UTC] PHP Deprecated:  strpos(): Passing null to parameter #1 ($haystack) of type string is deprecated in /var/www/*****/wp-includes/functions.php on line 7300
[12-Sep-2024 07:05:25 UTC] PHP Deprecated:  str_replace(): Passing null to parameter #3 ($subject) of type array|string is deprecated in /var/www/*****/wp-includes/functions.php on line 2189

These are not errors, but deprecation notices, and they tend to spam quite a lot. ??

I just saw the mention of a GitHub issue on another support topic.
https://github.com/WordPress/performance/issues/132
It’s a shame that it’s not being taken seriously. Personally, I don’t consider it dangerous. Despite being a major schema change that shouldn’t be taken lightly, I believe that a good large-scale implementation, with the right checks, couldn’t hurt for the benefit of WordPress.