Releases: Smile-SA/elasticsuite
2.10.27
🧰 Maintenance release
Due to Adobe switching the OpenSearch system requirement from OpenSearch from 1.x to OpenSearch 2.x in Magento's patch releases 2.4.4-p13 and 2.4.5-p12, this maintenance release introduces OpenSearch 2.x compatibility with Elasticsuite 2.10, while still maintaining compatibility with OpenSearch 1.x and Elasticsearch 6.x/7.x
📦 Features
- [Core] Adding support for OpenSearch 2.x in 2.10.x by @rbayet in #3582
- [Recommender] 💎 Add greater price limitation configuration for Upsell products by @vahonc
Full Changelog: 2.10.26.1...2.10.27
Contributors
Assets 2
2.11.12.1
🧰 Maintenance release
- 💎 [GoogleAnalytics] Remove debug log by @PierreGauthier
- [Tracker] Ignore docs w/o page.order.items in schema update by @rbayet in #3575
Full Changelog: 2.11.12...2.11.12.1
Contributors
Assets 2
2.10.26.1
🧰 Maintenance release
- 💎 [GoogleAnalytics] Remove debug log by @PierreGauthier
- [Tracker] Ignore docs w/o page.order.items in schema update by @rbayet in #3575
Full Changelog: 2.10.26...2.10.26.1
Contributors
Assets 2
2.11.12
Foreword
This release introduces a new field (page.order.items.date) in the Elasticsuite tracker related behavioral data indices which requires
- updating the mapping of tracker_log_event indices where the field does not exist yet in the mapping
- fixing the mapping of tracker_log_event indices where the field already exists but with the wrong type which requires "cloning" those indices and re-indexing them locally
- in all likelihood, this should concern only the last created tracker_log_event indices (one per store)
- the re-indexing operation should be pretty quick, even with millions of events on such indices
- updating all orders events to propagate the order date to the page.order.items.date structure
- which will take more time the bigger your retention delay and the more numerous your average number of sales per month
The steps above are automated in a Magento data upgrade script, executed by setup:upgrade.
You're advised (if you're not doing it already) to disable your Magento cronjobs prior to deploying the update and running setup:upgrade, and then re-enable your Magento cronjobs after the setup:upgrade is complete.
🏆 Main features
💎 Introducing revenue as a metric
Products accumulated revenue is now available as a behavioral data metric with the ability to create behavioral optimizers on
- Total revenue (accumulated revenue on the whole behavioral data retention delay)
- Cumulative revenue on the last 30 days (accumulated revenue on the "daily" stats window, which is 30 days by default)
- Cumulative revenue on the last 60 days (accumulated revenue on the "weekly" stats window, which is 60 days by default)
- Averaged daily revenue on the last full 7 days (moving average indicated as "on the last 30 days")
- Averaged weekly revenue on the last full 4 weeks (moving average indicated as "on the last _60_days")
(This is a reminder that we haven't introduced yet the ability to extend the moving average metrics computation for all metrics to use the full window available for "daily" and "weekly" stats. This is something that we might introduce later along with the ability to give more weight to the more recent sales/views events)
Changes for the "Based on attribute value" and 💎 "Based on behavioral data" optimizers
Renaming and moving the "Boost value (multiplier)" field
The "Based on attribute value" and 💎 "Based on behavioral data" rely on a per-product value (attribute value or behavioral metric, respectively) to determine their boost.
That raw value is multiplied by a "scale factor" (the same for all products) which is valued at 1 by default but could be changed in the optimizer edit form field "Boost value (multiplier)".
That field has been renamed to be (we hope !) more explicit :
- "Attribute value pre-multiplier" for "Based on attribute value" optimizers
- "Metric value pre-multiplier" for 💎 "Based on behavioral data" optimizers
It is also now located just below the attribute or metric select field.
Preventing "negative boosting" when the product value is too low
The per-product attribute/metric value, multiplied by that "scale factor" / value pre-multiplier can then be passed through a function represented by the "Boost impact" to potentially reduce the actual score boost it will generate
- the High boost impact is the identify function
- if the pre-multiplied attribute/metric value is 10, your product score will be multiplied by 10
- if the pre-multiplied attribute/metric is 100, your product score will be multiplied by 100
- this means huge differences in attribute or metric value will generate huge differences in score multipliers
- the Medium boost impact uses the square root function
- if the pre-multiplied attribute/metric value is 10, your product score will be multiplied by ~3.16
- if the pre-multiplied attribute/metric is 100, your product score will be multiplied by 10
- this helps reduce the range of score multipliers compared to the original range of attribute/metric value between products
- the Low boost impact uses the common (decimal) logarithm to reduce the attribute/metric value+1 more aggressively
- if the pre-multiplied attribute/metric value is 10, your product score will be multiplied by ~1.041
- if the pre-multiplied attribute/metric value is 50, your product score will be multiplied by ~1.707
- if the pre-multiplied attribute/metric is 100, your product score will be multiplied by ~2.004
- this helps reduce dramatically the range of score multipliers compared to the original range of attribute/metric value between products and is very useful for attribute/metric values that can range from 1 to several hundreds thousands (total views, total sales, etc...)
Historically, we only made sure to exclude any product with an invalid value for the function behind each boost impact.
But that didn't prevent some products with a defined but low attribute/metric value from being actually penalized compared to products without any value.
For instance, for an optimizer
- boosting products according to their average daily sales number
- with a "Boost value (multiply)" (now named "Metric value pre-multiplier") of 1 (default value)
- and the "Low impact" selected
a product with an average daily sales of 5 would actually get a score multiplier of 0.77, so lowering its final, compared to a new product with no sales at all yet.
The introduced changes now make sure to exclude any product with an attribute/metric value too low to result in a score multiplier greater than 1 :
- for the High and Medium impact, that will be 1 and lower (divided by the pre-multiplier)
- for the Low impact, that will be 9 and lower (divided by the pre-multiplier)
Given the previous example, the product with an average daily sales of 5 will no longer be penalized, but it won't be boosted either.
The solution in this case, which is the traditional one when using the "Low impact boost" is to use an "Attribute/Metric value pre-multiplier" of 10 instead of 1.
If for whatever reason, you want for a given Attribute value/Behavioral data optimizer, to revert back to the historical behavior, you can do so with switching to Yes the new optimizer parameter "Allow negative boost".
Its default value is No to make all existing optimizers benefit from the new products exclusion mechanism :
📦 Features
- 💎 [BehavioralData] Introduce revenue as a metric by @rbayet
- [Catalog] Implementing Category permissions by @romainruaud in #3566
- 💎 [BehavioralOptimizer] Move up and change label for 'Boost value (multiplier)' by @rbayet
- 💎 [BehavioralOptimizer] Scale function/factor dependant products exclusion by @rbayet
- [CatalogOptimizer] Move up and change label for 'Boost value (multiplier)' by @rbayet in #3563
- [CatalogOptimizer] Scale function/factor dependant products exclusion by @rbayet in #3562
- [CatalogOptimizer] Adding the products SKU in the preview area by @rbayet in #3560
- 💎 [Explain] Display alternative queries weight by @vahonc
- [Healthcheck] Feature #3536 introduce the notion of Severity for checks by @vahonc in #3548
- [Healthcheck] Feature #3536 Severity color coding by @rbayet in #3553
💻 Technical
- [CatalogRule] Adding basic unit tests by @rbayet in #3546
- [Core] Allow providing a value for "missing" values in sort order params by @xi-ao in #3569
- [Healthcheck] No menu decoration if Debug Mode enabled by @rbayet in #3565
- [Tools] Code quality to use PHP 8.1 to support associative array unpa… by @rbayet in #3547
- [Tracker] Make sure the order date is available at the order items level by @rbayet in #3554
- [Virtual Category] Prevent using cached query for sub virtual category by @PierreGauthier in #3486
🐛 Fixes
- 💎 [Explain] All store views optimizers not indexed in percolator by @rbayet
- 💎 [Explain] All store views optimizers not visible in Explain by @rbayet
- [Healthcheck] Fixes #3543 Prevent shift of Admin Menu by @rbayet in #3544
- [Healthcheck] Fixing invalid package version reading by @rbayet in #3545
New Contributors
Full Changelog: 2.11.11...2.11.12
Contributors
Assets 2
2.10.26
Foreword
This release introduces a new field (page.order.items.date) in the Elasticsuite tracker related behavioral data indices which requires
- updating the mapping of tracker_log_event indices where the field does not exist yet in the mapping
- fixing the mapping of tracker_log_event indices where the field already exists but with the wrong type which requires "cloning" those indices and re-indexing them locally
- in all likelihood, this should concern only the last created tracker_log_event indices (one per store)
- the re-indexing operation should be pretty quick, even with millions of events on such indices
- updating all orders events to propagate the order date to the page.order.items.date structure
- which will take more time the bigger your retention delay and the more numerous your average number of sales per month
The steps above are automated in a Magento data upgrade script, executed by setup:upgrade.
You're advised (if you're not doing it already) to disable your Magento cronjobs prior to deploying the update and running setup:upgrade, and then re-enable your Magento cronjobs after the setup:upgrade is complete.
🏆 Main features
💎 Introducing revenue as a metric
Products accumulated revenue is now available as a behavioral data metric with the ability to create behavioral optimizers on
- Total revenue (accumulated revenue on the whole behavioral data retention delay)
- Cumulative revenue on the last 30 days (accumulated revenue on the "daily" stats window, which is 30 days by default)
- Cumulative revenue on the last 60 days (accumulated revenue on the "weekly" stats window, which is 60 days by default)
- Averaged daily revenue on the last full 7 days (moving average indicated as "on the last 30 days")
- Averaged weekly revenue on the last full 4 weeks (moving average indicated as "on the last _60_days")
(This is a reminder that we haven't introduced yet the ability to extend the moving average metrics computation for all metrics to use the full window available for "daily" and "weekly" stats. This is something that we might introduce later along with the ability to give more weight to the more recent sales/views events)
Changes for the "Based on attribute value" and 💎 "Based on behavioral data" optimizers
Renaming and moving the "Boost value (multiplier)" field
The "Based on attribute value" and 💎 "Based on behavioral data" rely on a per-product value (attribute value or behavioral metric, respectively) to determine their boost.
That raw value is multiplied by a "scale factor" (the same for all products) which is valued at 1 by default but could be changed in the optimizer edit form field "Boost value (multiplier)".
That field has been renamed to be (we hope !) more explicit :
- "Attribute value pre-multiplier" for "Based on attribute value" optimizers
- "Metric value pre-multiplier" for 💎 "Based on behavioral data" optimizers
It is also now located just below the attribute or metric select field.
Preventing "negative boosting" when the product value is too low
The per-product attribute/metric value, multiplied by that "scale factor" / value pre-multiplier can then be passed through a function represented by the "Boost impact" to potentially reduce the actual score boost it will generate
- the High boost impact is the identify function
- if the pre-multiplied attribute/metric value is 10, your product score will be multiplied by 10
- if the pre-multiplied attribute/metric is 100, your product score will be multiplied by 100
- this means huge differences in attribute or metric value will generate huge differences in score multipliers
- the Medium boost impact uses the square root function
- if the pre-multiplied attribute/metric value is 10, your product score will be multiplied by ~3.16
- if the pre-multiplied attribute/metric is 100, your product score will be multiplied by 10
- this helps reduce the range of score multipliers compared to the original range of attribute/metric value between products
- the Low boost impact uses the common (decimal) logarithm to reduce the attribute/metric value+1 more aggressively
- if the pre-multiplied attribute/metric value is 10, your product score will be multiplied by ~1.041
- if the pre-multiplied attribute/metric value is 50, your product score will be multiplied by ~1.707
- if the pre-multiplied attribute/metric is 100, your product score will be multiplied by ~2.004
- this helps reduce dramatically the range of score multipliers compared to the original range of attribute/metric value between products and is very useful for attribute/metric values that can range from 1 to several hundreds thousands (total views, total sales, etc...)
Historically, we only made sure to exclude any product with an invalid value for the function behind each boost impact.
But that didn't prevent some products with a defined but low attribute/metric value from being actually penalized compared to products without any value.
For instance, for an optimizer
- boosting products according to their average daily sales number
- with a "Boost value (multiply)" (now named "Metric value pre-multiplier") of 1 (default value)
- and the "Low impact" selected
a product with an average daily sales of 5 would actually get a score multiplier of 0.77, so lowering its final, compared to a new product with no sales at all yet.
The introduced changes now make sure to exclude any product with an attribute/metric value too low to result in a score multiplier greater than 1 :
- for the High and Medium impact, that will be 1 and lower (divided by the pre-multiplier)
- for the Low impact, that will be 9 and lower (divided by the pre-multiplier)
Given the previous example, the product with an average daily sales of 5 will no longer be penalized, but it won't be boosted either.
The solution in this case, which is the traditional one when using the "Low impact boost" is to use an "Attribute/Metric value pre-multiplier" of 10 instead of 1.
If for whatever reason, you want for a given Attribute value/Behavioral data optimizer, to revert back to the historical behavior, you can do so with switching to Yes the new optimizer parameter "Allow negative boost".
Its default value is No to make all existing optimizers benefit from the new products exclusion mechanism :
📦 Features
- 💎 [BehavioralData] Introduce revenue as a metric by @rbayet
- [Catalog] Implementing Category permissions by @romainruaud in #3566
- 💎 [BehavioralOptimizer] Move up and change label for 'Boost value (multiplier)' by @rbayet
- 💎 [BehavioralOptimizer] Scale function/factor dependant products exclusion by @rbayet
- [CatalogOptimizer] Move up and change label for 'Boost value (multiplier)' by @rbayet in #3563
- [CatalogOptimizer] Scale function/factor dependant products exclusion by @rbayet in #3562
- [CatalogOptimizer] Adding the products SKU in the preview area by @rbayet in #3560
- 💎 [Explain] Display alternative queries weight by @vahonc
- [Healthcheck] Feature #3536 introduce the notion of Severity for checks by @vahonc in #3548
- [Healthcheck] Feature #3536 Severity color coding by @rbayet in #3553
💻 Technical
- [CatalogRule] Adding basic unit tests by @rbayet in #3546
- [Core] Allow providing a value for "missing" values in sort order params by @xi-ao in #3569
- [Healthcheck] No menu decoration if Debug Mode enabled by @rbayet in #3565
- [Tools] Code quality to use PHP 8.1 to support associative array unpa… by @rbayet in #3547
- [Tracker] Make sure the order date is available at the order items level by @rbayet in #3554
- [Virtual Category] Prevent using cached query for sub virtual category by @PierreGauthier in #3486
🐛 Fixes
- 💎 [Explain] All store views optimizers not indexed in percolator by @rbayet
- 💎 [Explain] All store views optimizers not visible in Explain by @rbayet
- [Healthcheck] Fixes #3543 Prevent shift of Admin Menu by @rbayet in #3544
- [Healthcheck] Fixing invalid package version reading by @rbayet in #3545
New Contributors
Full Changelog: 2.10.25...2.10.26
Contributors
Assets 2
2.11.11
🏆 Main features
Health-checks feature
We're introducing in this release a new screen in Elasticsuite > System > Healthcheck where are re-located some previous admin system notification messages: invalid configuration for shards and replicas, notifications about ghost indices, etc.
For the time being, it is restricted to some of the basic technical health checks but it will grow from there to include more tracker related or functional health checks.
A decoration mechanism in the admin menu helps you know immediately how many checks are currently failing.
💎 Introducing advanced analysis module and word decompounding for germanic languages
We're introducing a new Elasticsuite Premium module/package smile/module-elasticsuite-advanced-analysis that brings with it support for Hyphenation Word Decompounding which will be useful for germanic languages in order to avoid having to create many synonyms rules between words in their compound and separated forms.
It has been tested for German and Dutch successfully but in a limited scope and it will require on your end to do some fine tuning and provide and deploy data files on your OpenSearch / Elasticsearch cluster.
This mechanism relies on new settings available at the store scope in Elasticsuite > Analyzers Settings > Hyphenation Words decompounder configuration and requires essentially two things
- a XML file containing your language hyphenation patterns (how a word processor is allowed to break your language compound words when it needs to justify text)
- a dictionary that will act has a white list of words allowed to be generated by this hyphenation mechanism: this can be provided directly in admin as a list of words, or as a flat text file to be deployed on your cluster
When enabled, the word decompounder is injected into the text analyzers standard, standard_edge_ngram, shingle before (or after depending in your configuration) the stemmer.
Due to licensing consideration, we cannot provide you directly with adequate data files to configuration the word decompounder, but they are available online
- for Dutch and German, we've relied on OFFO hyphenation patterns provided as a link to a offo-hyphenation_v1.2.zip archive in Elasticsearch online documentation.
- for the Dutch dictionary, good results were obtained using the "OpenTaal-210G-basis-gekeurd" dictionary from OpenTaal.
Decompounding the Dutch word "klauwverzorging" and "afrasteringspalen"
Decompounding the German word "Kaffeetassenwärmer"
📦 Features
- 💎 [AdvancedAnalysis] Module initialization. by @rbayet in Elastic-Suite/magento2-elasticsuite-premium#312
- [Analytics] Feature #3535, add Analytics filters configuration by @vahonc in #3537
- [Core] Feature #3432, add the Healthcheck Page by @vahonc in #3450
- [Core] Add Estonian stemmer by @romainruaud in #3484
- [Core] Adding fine-tuning options for the autocompletion by @rbayet in #3487
- [Indices] Feature #3453: Add detection for closed indices by @vahonc in #3472
- [Indices] Feature #3452, add number of primary shards and replicas in the Indices grid by @vahonc in #3477
- [Tracker] Allow ignoring bots generated tracker hits by @rbayet in #3480
- [Tracker] Feature #3489, change the default tracker strategy to REST/API mode by @vahonc in #3502
- [Catalog][Tracker] Feature #3451, allow to track the redirected search terms by @vahonc in #3503
💻 Technical
- [Analytics] i18n for new filters related settings by @rbayet in #3539
- 💎 [CascadeSearch] Update cascade search UX by @romainruaud in Elastic-Suite/magento2-elasticsuite-premium#314
- [CatalogLayer] Added default attribute label by @mhaagen85 in #3444
- [CatalogSearch] Forcefull add mview trigger removed in 2.4.6 by @rbayet in #3514
- [Core] ProductMetadata/ComposerInformation rework by @rbayet in #3494
- [Core] Adding noop token filters around stemmer by @rbayet in #3510
- [Core] add column type in db_schema.xml, required from magento 2.4.8-beta1 by @Bashev in #3520
- [Core] Ensure Opensearch 2.4.0 will not be used until they fix memory issue by @romainruaud in #3527
- [Healthchecks] tweaks and i18n by @rbayet in #3485
- [Healtchecks] Composer version mismatch check (for OS and ESP packages) by @rbayet in #3495
- [Healthchecks] Hyva compatibility modules check by @rbayet in #3497
- [Healthchecks] Feature #3488, add AbstractCheck class and code refactoring by @vahonc in #3516
- [Healthchecks] Replaced success/warning by passed/failed by @rbayet in #3532
- [HealthChecks] Feature #3490, add search engine config check by @vahonc in #3534
- [HealthChecks] Admin nav. menu decoration by number of warnings by @rbayet in #3492
- 💎 [Healthchecks] Composer mismatch packages declaration by @rbayet in Elastic-Suite/magento2-elasticsuite-premium#308
- 💎 [Healthchecks] Hyva compatibility modules check (esp side) by @rbayet in Elastic-Suite/magento2-elasticsuite-premium#309
- 💎 [InstantSearch] Ensure Instant Search is using the new settings and objects by @romainruaud in Elastic-Suite/magento2-elasticsuite-premium#302
- 💎 [InstantSearch] Handle total lack of indexed price structure by @rbayet in Elastic-Suite/magento2-elasticsuite-premium#319
- 💎 [NeuralSearch] Ensure Neural search remains compatible with Opensearch client >=2.4.0 by @romainruaud in Elastic-Suite/magento2-elasticsuite-premium#317
- 💎 [NeuralSearch] Do not add knn fields into optimizer percolator index by @romainruaud in Elastic-Suite/magento2-elasticsuite-premium#318
- [Tracker] Adding additional Facebook bots by @rbayet in #3482
- [Tools] CI/CD phpstan require with --no-update by @rbayet in #3512
🐛 Fixes
- [Admin] Do not apply the currentcategory filter in admin. by @romainruaud in #3515
- [Analytics] Date picker vs switchers (store, customer group, company) by @rbayet in #3475
- [Analytics] Ignore filtered search pages for avg result count by @rbayet in #3478
- [Analytics] Ignore non-first page for avg. count/0 result pages by @rbayet in #3483
- 💎 [ConfigurableProduct] Avoid GraphQL exceptions when no configurable products by @rbayet in Elastic-Suite/magento2-elasticsuite-premium#310
- [Core] Fixing namespace in some unit tests by @rbayet in #3511
- 💎 [FacetRecommender] Fixing display on all standard page layouts by @rbayet in Elastic-Suite/magento2-elasticsuite-premium#305
- 💎 [GA] Fix result count type by @rbayet in Elastic-Suite/magento2-elasticsuite-premium#307
- 💎 [NeuralSearch] Fixing module dependencies by @rbayet in Elastic-Suite/magento2-elasticsuite-premium#320
- [PageBuilder] Fix #3493, apply a negation to the category_ids condition by @vahonc in #3501
- [Tracker] Fixes #3500 loss of X-Magento-Vary cookie by @rbayet in #3504
- [Tracker] Fix tracker data when redirecting by @romainruaud in #3517
- [Tracker] Fix #3513, Ensure sessionData is always an array by @vahonc in #3519
New Contributors
- @mhaagen85 made their first contribution in #3444
Full Changelog: 2.11.10.1...2.11.11
Contributors
Assets 2
2.10.25
🏆 Main features
Health-checks feature
We're introducing in this release a new screen in Elasticsuite > System > Healthcheck where are re-located some previous admin system notification messages: invalid configuration for shards and replicas, notifications about ghost indices, etc.
For the time being, it is restricted to some of the basic technical health checks but it will grow from there to include more tracker related or functional health checks.
A decoration mechanism in the admin menu helps you know immediately how many checks are currently failing.
💎 Introducing advanced analysis module and word decompounding for germanic languages
We're introducing a new Elasticsuite Premium module/package smile/module-elasticsuite-advanced-analysis that brings with it support for Hyphenation Word Decompounding which will be useful for germanic languages in order to avoid having to create many synonyms rules between words in their compound and separated forms.
It has been tested for German and Dutch successfully but in a limited scope and it will require on your end to do some fine tuning and provide and deploy data files on your OpenSearch / Elasticsearch cluster.
This mechanism relies on new settings available at the store scope in Elasticsuite > Analyzers Settings > Hyphenation Words decompounder configuration and requires essentially two things
- a XML file containing your language hyphenation patterns (how a word processor is allowed to break your language compound words when it needs to justify text)
- a dictionary that will act has a white list of words allowed to be generated by this hyphenation mechanism: this can be provided directly in admin as a list of words, or as a flat text file to be deployed on your cluster
When enabled, the word decompounder is injected into the text analyzers standard, standard_edge_ngram, shingle before (or after depending in your configuration) the stemmer.
Due to licensing consideration, we cannot provide you directly with adequate data files to configuration the word decompounder, but they are available online
- for Dutch and German, we've relied on OFFO hyphenation patterns provided as a link to a offo-hyphenation_v1.2.zip archive in Elasticsearch online documentation.
- for the Dutch dictionary, good results were obtained using the "OpenTaal-210G-basis-gekeurd" dictionary from OpenTaal.
Decompounding the Dutch word "klauwverzorging" and "afrasteringspalen"
Decompounding the German word "Kaffeetassenwärmer"
📦 Features
- 💎 [AdvancedAnalysis] Module initialization. by @rbayet in Elastic-Suite/magento2-elasticsuite-premium#312
- [Analytics] Feature #3535, add Analytics filters configuration by @vahonc in #3537
- [Core] Feature #3432, add the Healthcheck Page by @vahonc in #3450
- [Core] Add Estonian stemmer by @romainruaud in #3484
- [Core] Adding fine-tuning options for the autocompletion by @rbayet in #3487
- [Indices] Feature #3453: Add detection for closed indices by @vahonc in #3472
- [Indices] Feature #3452, add number of primary shards and replicas in the Indices grid by @vahonc in #3477
- [Tracker] Allow ignoring bots generated tracker hits by @rbayet in #3480
- [Tracker] Feature #3489, change the default tracker strategy to REST/API mode by @vahonc in #3502
- [Catalog][Tracker] Feature #3451, allow to track the redirected search terms by @vahonc in #3503
💻 Technical
- [Analytics] i18n for new filters related settings by @rbayet in #3539
- 💎 [CascadeSearch] Update cascade search UX by @romainruaud in Elastic-Suite/magento2-elasticsuite-premium#314
- [CatalogSearch] Forcefull add mview trigger removed in 2.4.6 by @rbayet in #3514
- [Core] ProductMetadata/ComposerInformation rework by @rbayet in #3494
- [Core] Adding noop token filters around stemmer by @rbayet in #3510
- [Healthchecks] tweaks and i18n by @rbayet in #3485
- [Healtchecks] Composer version mismatch check (for OS and ESP packages) by @rbayet in #3495
- [Healthchecks] Hyva compatibility modules check by @rbayet in #3497
- [Healthchecks] Feature #3488, add AbstractCheck class and code refactoring by @vahonc in #3516
- [Healthchecks] Replaced success/warning by passed/failed by @rbayet in #3532
- [HealthChecks] Feature #3490, add search engine config check by @vahonc in #3534
- [HealthChecks] Admin nav. menu decoration by number of warnings by @rbayet in #3492
- 💎 [Healthchecks] Composer mismatch packages declaration by @rbayet in Elastic-Suite/magento2-elasticsuite-premium#308
- 💎 [Healthchecks] Hyva compatibility modules check (esp side) by @rbayet in Elastic-Suite/magento2-elasticsuite-premium#309
- 💎 [InstantSearch] Ensure Instant Search is using the new settings and objects by @romainruaud in Elastic-Suite/magento2-elasticsuite-premium#302
- 💎 [InstantSearch] Handle total lack of indexed price structure by @rbayet in Elastic-Suite/magento2-elasticsuite-premium#319
- [Tracker] Adding additional Facebook bots by @rbayet in #3482
- [Tools] CI/CD phpstan require with --no-update by @rbayet in #3512
🐛 Fixes
- [Admin] Do not apply the currentcategory filter in admin. by @romainruaud in #3515
- [Analytics] Date picker vs switchers (store, customer group, company) by @rbayet in #3475
- [Analytics] Ignore filtered search pages for avg result count by @rbayet in #3478
- [Analytics] Ignore non-first page for avg. count/0 result pages by @rbayet in #3483
- 💎 [ConfigurableProduct] Avoid GraphQL exceptions when no configurable products by @rbayet in Elastic-Suite/magento2-elasticsuite-premium#310
- [Core] Fixing namespace in some unit tests by @rbayet in #3511
- 💎 [FacetRecommender] Fixing display on all standard page layouts by @rbayet in Elastic-Suite/magento2-elasticsuite-premium#305
- 💎 [GA] Fix result count type by @rbayet in Elastic-Suite/magento2-elasticsuite-premium#307
- [PageBuilder] Fix #3493, apply a negation to the category_ids condition by @vahonc in #3501
- [Tracker] Fixes #3500 loss of X-Magento-Vary cookie by @rbayet in #3504
- [Tracker] Fix tracker data when redirecting by @romainruaud in #3517
- [Tracker] Fix #3513, Ensure sessionData is always an array by @vahonc in #3519
Full Changelog: 2.10.24...2.10.25
Contributors
Assets 2
2.11.10.1
2.11.10
🏆 Main features
💎 Introducing the Cascade Search suggestions module
Foreword
Please note that while the description below and the screenshots are in English, the feature has been primarily conceived, developed and tested on a French dataset. Nonetheless, by design, it should also work pretty much fine out-of-the-box for other common romance languages (Spanish, Italian, Portuguese) and English.
On the other hand, more complex languages, or languages that our team are not native speakers of, will need some testing and/or customizing of the Elasticsuite analysis configuration to fare better.
For instance, for germanic languages using word compounding like German and Dutch, adding a word decompounder step in the analysis, if not already done before installing the module might be a requirement.
Please note that the module includes a language restriction setting, so on a multi-store / multi-language setup, you could totally enable it for your French, Spanish and English store views, and simply disable it for the others.
At any case, we're open to any positive or negative feedback about the behavior of the module in any language.
The new Cascade Search premium module (package smile/module-elasticsuite-cascade-search) leverages your behavioral data to suggest finer popular search terms to your users to allow them navigating from a very vague search query to the specific item type they might be looking for.
In the example below, a user initially searches for "table" and several search terms suggestions will be displayed in the search results page above the product lists.
Each suggestion is decorated with the best matching product for the suggested search terms.
The user can then decide to indeed search for "folding table" and on the search results page, additional finer suggestions will be displayed.
The suggestion block automatically disappears when there are no longer finer suggestions popular enough to be displayed.
The module allows to preview and manage suggestions by either blacklisting a suggestion globally, so it will never be shown whatever the context, or blacklisting a suggestion in a specific search context, for instance to remove duplicate suggestions.
For instance, in the example below, when previewing in admin the suggestions for "folding table", we can see that the "market folding table" is globally blacklisted and "folding table in aluminum" is locally blacklisted, ie blacklisted specifically when searching for "folding table".
Post-installation
After adding the package smile/module-elasticsuite-cascade-search to your project, enabling the module Smile_ElasticsuiteCascadeSearch and reviewing the settings, you will need to execute the following commands to rebuild the two new Magento indexers the feature relies upon
php bin/magento indexer:reset elasticsuite_search_events
php bin/magento indexer:reindex elasticsuite_search_events elasticsuite_search_suggestions
Those two new indexers need to be set up in "Update by Schedule".
Please note that since the elasticsuite_search_events indexer can be quite costly to create depending on your Elasticsuite Tracker retention delay, number of stores and traffic (it aggregates, analyzes and re-indexes all popular searches) it is protected from "accidental rebuilding requests" by needing to be in the "Invalid" state to be rebuilt.
Hence the first command above being php bin/magento indexer:reset elasticsuite_search_events.
💎 Making the Elasticsuite Recommender more flexible through Target Rules
While the Elasticsuite recommender allows creating optimizers to boost some products in behavioral data driven related products, cross-sells or upsells product recommendations, it was not possible to force the presence of some very specific products for a given product or set of products like it can be done with the Adobe Commerce Target Rule module.
It is now possible (if you're on a Magento Enterprise/Adobe Commerce version) through the Elasticsuite Premium package smile/module-elasticsuite-recommender-target-rule-proxy that will provide the Smile_ElasticsuiteRecommenderTargetRuleProxy module.
It introduces a new setting "Extend selected products to target rule products" for every recommendation type to allow complementing the manually configured products with products coming from Related Products/Target Rules recommendations.
Elasticsuite Tracker: support of Magento Company B2B module and support of Klarna checkout success page
The Elasticsuite Tracker is now recording the user's customer group and, if the Magento B2B modules are deployed in your environment and if the Company feature enabled, the company he belongs to.
In turn, the Analytics/Search Usage page will display additional selectors to filter the behavioral data based on the customer groups and/or companies.
If your site is using Klarna as a payment method, the Elasticsuite tracker was not able to identify the specific checkout success page as such and record the sale event.
It is now done through a newly introduced DI mechanism which you can use to also add support for other third party or custom Magento layout page identifiers ([module]_[controller]_[action]) to be identified as a checkout success page.
Ability to faster identify Ghost Indices as such
By default, the Elasticsuite Indices screen will identify indices as "Ghost" when
- they fit the pattern of a index created by Elasticsuite for re-indexing data (products, categories, thesaurus, ...) of the current Magento instance
- but do not bear the index alias marking them as "Live"
- and were created 2 days ago or more
Those Ghost indices resulting for a failed full re-indexing processes draw resources from you Elasticsearch/OpenSearch cluster and you're encouraged to remove them as soon as possible (once you're able to determine why they occurred in the first place).
Elasticsuite allows you to remove them manually from the Indices screen and there are third party modules that provide cronjobs to remove them periodically.
Depending on your context, for instance
- if you have a lot of store views and usually lightweight, fast re-indexing product catalogs
- but are currently encountering a lot of issues due to third party modules acting up or an unstable Elasticsearch/OpenSearch cluster
you could end up in a situation with a lot of failed re-indexation indices in an "Unknown" status waiting for that 2 days time period to elapse before they are correctly flagged as "Ghost" so you can remove them.
A new setting is available in Stores > Configuration > Elasticsuite > Base Settings > Indices Settings > Time for an index to be considered Ghost (in seconds) so you can reduce, for instance, that default 2 days period to 6 hours (by setting its value to 21,600 - 6 hours x 3600 seconds) if you know that your catalog product full re-indexing will either succeed or fail in at most 1 hour.
📦 Features
- [Analytics][Tracker] Feature #3340, add company_id and customer_group_id in tracking data by @vahonc in #3459
- [Core] Setting to customize time before an index becomes ghost by @rbayet in #3468
- [Tracker] Extensible page identifier mapping + klarna support out-of-the-box by @romainruaud in #3446
💻 Technical
- [Analytics] Handle case where Magento_Company has been installed, enabled then removed by @rbayet in #3463
- 💎 [Explain] Take into account Thesaurus cache config by @rbayet
- 💎 [InstantSearch] Allow to configure FPC TTL for ACP by @romainruaud
- 💎 [Recommender] Cross-sell leftovers handling and Hÿva compatibility by @rbayet
- 💎 [Recommender] Make the visitor widget compatible with Hÿva by @romainruaud
- 💎 [Recommender][Hyva] Force HTTP cache bypass by @rbayet
- [Thesaurus] Conditional caching settings by @rbayet in #3447
🐛 Fixes
- [Ajax Filter] Prevent fatal error when category is not existing. by @romainruaud in #3455
- [Catalog] Fix #3431, replacing 'onclick' with an inline function to bind the click events by @vahonc in #3443
- [Indices] Fix #3449, handling a false value of Index updated date by @vahonc in #3461
- 💎 [VirtualAttribute] Create temporary tables without FK to prevent failure (errno 150) on some MariaDB/MySQL versions by @rbayet
🔧 Tests
- [Core] Adding a few Search related unit tests by @rbayet in #3454
- [Core] Adding some unit tests by @rbayet in https://github.co...
Contributors
Assets 2
2.10.24
🏆 Main features
💎 Introducing the Cascade Search suggestions module
Foreword
Please note that while the description below and the screenshots are in English, the feature has been primarily conceived, developed and tested on a French dataset. Nonetheless, by design, it should also work pretty much fine out-of-the-box for other common romance languages (Spanish, Italian, Portuguese) and English.
On the other hand, more complex languages, or languages that our team are not native speakers of, will need some testing and/or customizing of the Elasticsuite analysis configuration to fare better.
For instance, for germanic languages using word compounding like German and Dutch, adding a word decompounder step in the analysis, if not already done before installing the module might be a requirement.
Please note that the module includes a language restriction setting, so on a multi-store / multi-language setup, you could totally enable it for your French, Spanish and English store views, and simply disable it for the others.
At any case, we're open to any positive or negative feedback about the behavior of the module in any language.
The new Cascade Search premium module (package smile/module-elasticsuite-cascade-search) leverages your behavioral data to suggest finer popular search terms to your users to allow them navigating from a very vague search query to the specific item type they might be looking for.
In the example below, a user initially searches for "table" and several search terms suggestions will be displayed in the search results page above the product lists.
Each suggestion is decorated with the best matching product for the suggested search terms.
The user can then decide to indeed search for "folding table" and on the search results page, additional finer suggestions will be displayed.
The suggestion block automatically disappears when there are no longer finer suggestions popular enough to be displayed.
The module allows to preview and manage suggestions by either blacklisting a suggestion globally, so it will never be shown whatever the context, or blacklisting a suggestion in a specific search context, for instance to remove duplicate suggestions.
For instance, in the example below, when previewing in admin the suggestions for "folding table", we can see that the "market folding table" is globally blacklisted and "folding table in aluminum" is locally blacklisted, ie blacklisted specifically when searching for "folding table".
Post-installation
After adding the package smile/module-elasticsuite-cascade-search to your project, enabling the module Smile_ElasticsuiteCascadeSearch and reviewing the settings, you will need to execute the following commands to rebuild the two new Magento indexers the feature relies upon
php bin/magento indexer:reset elasticsuite_search_events
php bin/magento indexer:reindex elasticsuite_search_events elasticsuite_search_suggestions
Those two new indexers need to be set up in "Update by Schedule".
Please note that since the elasticsuite_search_events indexer can be quite costly to create depending on your Elasticsuite Tracker retention delay, number of stores and traffic (it aggregates, analyzes and re-indexes all popular searches) it is protected from "accidental rebuilding requests" by needing to be in the "Invalid" state to be rebuilt.
Hence the first command above being php bin/magento indexer:reset elasticsuite_search_events.
💎 Making the Elasticsuite Recommender more flexible through Target Rules
While the Elasticsuite recommender allows creating optimizers to boost some products in behavioral data driven related products, cross-sells or upsells product recommendations, it was not possible to force the presence of some very specific products for a given product or set of products like it can be done with the Adobe Commerce Target Rule module.
It is now possible (if you're on a Magento Enterprise/Adobe Commerce version) through the Elasticsuite Premium package smile/module-elasticsuite-recommender-target-rule-proxy that will provide the Smile_ElasticsuiteRecommenderTargetRuleProxy module.
It introduces a new setting "Extend selected products to target rule products" for every recommendation type to allow complementing the manually configured products with products coming from Related Products/Target Rules recommendations.
Elasticsuite Tracker: support of Magento Company B2B module and support of Klarna checkout success page
The Elasticsuite Tracker is now recording the user's customer group and, if the Magento B2B modules are deployed in your environment and if the Company feature enabled, the company he belongs to.
In turn, the Analytics/Search Usage page will display additional selectors to filter the behavioral data based on the customer groups and/or companies.
If your site is using Klarna as a payment method, the Elasticsuite tracker was not able to identify the specific checkout success page as such and record the sale event.
It is now done through a newly introduced DI mechanism which you can use to also add support for other third party or custom Magento layout page identifiers ([module]_[controller]_[action]) to be identified as a checkout success page.
Ability to faster identify Ghost Indices as such
By default, the Elasticsuite Indices screen will identify indices as "Ghost" when
- they fit the pattern of a index created by Elasticsuite for re-indexing data (products, categories, thesaurus, ...) of the current Magento instance
- but do not bear the index alias marking them as "Live"
- and were created 2 days ago or more
Those Ghost indices resulting for a failed full re-indexing processes draw resources from you Elasticsearch/OpenSearch cluster and you're encouraged to remove them as soon as possible (once you're able to determine why they occurred in the first place).
Elasticsuite allows you to remove them manually from the Indices screen and there are third party modules that provide cronjobs to remove them periodically.
Depending on your context, for instance
- if you have a lot of store views and usually lightweight, fast re-indexing product catalogs
- but are currently encountering a lot of issues due to third party modules acting up or an unstable Elasticsearch/OpenSearch cluster
you could end up in a situation with a lot of failed re-indexation indices in an "Unknown" status waiting for that 2 days time period to elapse before they are correctly flagged as "Ghost" so you can remove them.
A new setting is available in Stores > Configuration > Elasticsuite > Base Settings > Indices Settings > Time for an index to be considered Ghost (in seconds) so you can reduce, for instance, that default 2 days period to 6 hours (by setting its value to 21,600 - 6 hours x 3600 seconds) if you know that your catalog product full re-indexing will either succeed or fail in at most 1 hour.
📦 Features
- [Analytics][Tracker] Feature #3340, add company_id and customer_group_id in tracking data by @vahonc in #3459
- [Core] Setting to customize time before an index becomes ghost by @rbayet in #3468
- [Tracker] Extensible page identifier mapping + klarna support out-of-the-box by @romainruaud in #3446
💻 Technical
- [Analytics] Handle case where Magento_Company has been installed, enabled then removed by @rbayet in #3463
- 💎 [Explain] Take into account Thesaurus cache config by @rbayet
- 💎 [InstantSearch] Allow to configure FPC TTL for ACP by @romainruaud
- 💎 [Recommender] Cross-sell leftovers handling and Hÿva compatibility by @rbayet
- 💎 [Recommender] Make the visitor widget compatible with Hÿva by @romainruaud
- 💎 [Recommender][Hyva] Force HTTP cache bypass by @rbayet
- [Thesaurus] Conditional caching settings by @rbayet in #3447
🐛 Fixes
- [Ajax Filter] Prevent fatal error when category is not existing. by @romainruaud in #3455
- [Catalog] Fix #3431, replacing 'onclick' with an inline function to bind the click events by @vahonc in #3443
- [Indices] Fix #3449, handling a false value of Index updated date by @vahonc in #3461
- 💎 [VirtualAttribute] Create temporary tables without FK to prevent failure (errno 150) on some MariaDB/MySQL versions by @rbayet
🔧 Tests
- [Core] Adding a few Search related unit tests by @rbayet in #3454
- [Core] Adding some unit tests by @rbayet in https://github.co...