Magento EE 1.14.3.7 compatibility

[not-art]

Hi Something Digital team!

The engineers here at Zebit had been using this extension up until we applied the most-recent Magento 1 EE patch we had tested (1.14.3.7).

SomethingDigital_EnterpriseIndexPerf is not listed as compatible with our current Magento EE version (as mentioned, 1.14.3.7), and we proved that it's not compatible after testing it's use post-upgrade... it does not play well with the Visual Merchandiser for Categories:

Issue with SomethingDigital_EnterpriseIndexPerf on Magento 1.14.3.7 patch:

• Go to Edit a Category
• Click the Visual Mechandiser tab
• Update the sort order for the category using Visual Merchandiser's drag & drop
• Save the changes: These changes are published to the site & live almost immediately.
• In 15 minutes when the enterprise_refresh_index job runs, the published changes from the Visual Merchandiser disappear from the site, effectively undoing the changes made earlier.

Expected Result:

• When the enterprise_refresh_index runs, it respects the changes made by the Visual Merchandiser, and does not nuke the changes made by the drag & drop re-sorting.

More Info To Come!

• The Zebit engineer with the primary knowledge of this issue & who worked with our Merch team to implement SomethingDigital_EnterpriseIndexPerf, and then also identified the issue with 1.14.3.7, is out on vacation. If he gets back to us with more details we'll update this issue as-needed.

Please let us know if you'd like any additional details regarding our setup. Cheers!

-Art @ Zebit Engineering

[not-art]

Some extra context from said-mentioned engineer:

There's an issue where the SomethingDigital_EnterpriseIndexPerf indexer is incorrectly setting the sort order for a category when changes to an unrelated category are made. For example, change the sort order for category 1 via VM, things look good. Then go in and make any update to some other unrelated category and the sort order of products in cat 1 will be overwritten.

The sort order will initially be 1, then something like 10000 after the SomethingDigital_EnterpriseIndexPerf indexer runs.

[toddbc]

Interesting. The main change we make to the sorting process is to avoid resetting it if not necessary. We haven't dug into this much since we've focused on Magento 2 - although we do have Magento 1 clients using this who aren't seeing this so far.

But here are some notes that may help.

Basically, this:

SomethingDigital_EnterpriseIndexPerf/app/code/community/SomethingDigital/EnterpriseIndexPerf/Model/Merchandiser/Sorting.php

Lines 20 to 21 in f68b483

	// Only apply an update if it actually changed. It's common that this won't change.
	if ($product['position'] != $position) {

We also avoid resorting multiple times, which by default causes lots of reindexing:

SomethingDigital_EnterpriseIndexPerf/app/code/community/SomethingDigital/EnterpriseIndexPerf/Model/Merchandiser/Indexer.php

Line 77 in 941f998

// Don't apply sorting logic if it's going to be resorted later anyway.

You can see that this prevents the complete category rebuild on cron here:

SomethingDigital_EnterpriseIndexPerf/app/code/community/SomethingDigital/EnterpriseIndexPerf/Model/Observer/Merchandiser.php

Lines 18 to 20 in 941f998

	// Following indexes only works when they're enabled.
	// But when they are, we'll use events.
	if (!$this->isFlatIndexerEnabled()) {

I'm not aware of any - but if this is behaving differently from OOB, it either means that one of the 1.1.4.3.x patches has changed this module's behavior (should be visible in the patches), or else we missed something for a specific combination of settings.

You'll note that existing products are retained in their existing sort order:

SomethingDigital_EnterpriseIndexPerf/app/code/community/SomethingDigital/EnterpriseIndexPerf/Model/Merchandiser/Indexer.php

Lines 53 to 69 in 941f998

	if ($categoryValues['ruled_only'] == 0) {
	// These are already in sorted order. Don't move hero products down, though.
	foreach ($existingProducts as $productId => $position) {
	if (!isset($newProducts[$productId])) {
	$newProducts[$productId] = $iCounter++;
	}
	}
	} else {
	// Apply existing rule-based products in the same order they were in before.
	$ruledLookup = array_flip($ruledProductIds);
	foreach ($existingProducts as $productId => $position) {
	if (!isset($newProducts[$productId]) && isset($ruledLookup[$productId])) {
	$newProducts[$productId] = $iCounter++;
	}
	}
	}

Which is obtained here:

SomethingDigital_EnterpriseIndexPerf/app/code/community/SomethingDigital/EnterpriseIndexPerf/Model/Merchandiser/Indexer.php

Lines 25 to 30 in 941f998

	$categoryProductsResult = $merchandiserResourceModel->getCategoryProduct($categoryId);
	$existingProducts = array();
	foreach ($categoryProductsResult as $productInfo) {
	$existingProducts[$productInfo['product_id']] = $productInfo['position'];
	}
	asort($existingProducts);

But perhaps there's now an issue with retaining that order.

My guess is the behavior is kicking off here:

SomethingDigital_EnterpriseIndexPerf/app/code/community/SomethingDigital/EnterpriseIndexPerf/Model/Observer/Merchandiser.php

Line 31 in 941f998

$merchandiserResourceModel->applySortAction($categoryId);

Although would need to double check your flat indexer setting - we've most heavily tested this with flat indexing enabled.

[not-art]

Thanks todd! We'll dig in to your comments to see if it helps at all in the meantime.

We do have category and product flat index enabled, and the indexer settings for them are to update when scheduled. The enterprise_refresh_index runs every 15 minutes via cron right now.

[tmotyl]

hi @not-art,
Have you found a solution?