(SOLVED) Magento 2.3.5 Category backend data-binding not working & Category Frontend Landing Pages not showing (Migrated Data from Magento 1.7x)

magento.stackexchange https://magento.stackexchange.com/questions/332559

Question

The question I want to ask is this: How does knockout data binding work in Magento 2.3.5?

I have migrated data from Magento 1.7.0.2 using Magento Data Migration Tool.

The backend Catalog -> Categories -> (any category) does not pull the data from the database. It seems the values are just defaults.

See image showing current values for Category ID: 7 (Brands) See image showing current values for Category ID: 7 (Brands) After finding the related tables I ran this:

SELECT block.content, eea.attribute_code, eea.attribute_id, cat.*, ccet.*, block.*
   FROM catalog_category_entity_int ccet
   INNER JOIN catalog_category_entity AS cat
   ON ccet.entity_id  = cat.entity_id 
   INNER JOIN eav_attribute eea ON 
   ccet.attribute_id  = eea.attribute_id
   INNER JOIN cms_block as block 
   ON block.block_id = ccet.value 
   WHERE eea.attribute_code = 'landing_page'
   AND ccet.entity_id = 7
   ORDER BY eea.attribute_code ASC;

The results of the database data for ID 7 (as image above):

The results of the database data for ID 7 (as image above)

The query I ran targets landing_page attribute (all other attributes and categories have same issue as discussed here), which returns brands-landing-page (this is the correct item) and all other information - Brands category with Brands Landing Page.

The data-binding (or something else) does not work correctly. This means I cannot save the Category, (as Category Name is EMPTY but required).

How and where can I start to investigate what is wrong, how will I be able if Knockout (or PHP that populates the data and binds to Knockout) works correctly?

Frontend also doesn't display the landing page for the categories where set.

Side notes

  • Most important thing - Data is migrated using data-migration-tool:2.3.5 from Magento 1.7.0.2
  • The landing pages also doesn't show on the frontend (same issue with bindings maybe?)
  • No errors in log files, no errors displayed on page, or browser console
  • I have two Store IDs - 0 admin and 1 custom store Changing Store IDs from 0 to 1 has no effect!

Thank you!

SOLUTION:

My instance was 100% related to data-migration-tool that doesn't correctly update all the related tables. See LitExtension Magento Migration or my answer below for tables involved.


Was it helpful?

Solution

Thanks to LitExtension Magento Migration for pointing me in the right direction. The issue is that catalog_category_entity and eav_entity_attribute tables does not have the same IDs set for entity_type_id = 3.

The issue is related to the data migration tool:

  • The base install for Magento 2.3.5 already contains attribute sets with ID 1-9. ID 3 seems to be named Default, and attached to entity_type_id = 3 (category entity).

  • Once you migrate data (at least in my case), you have to rename the base install attribute set names (named Default_1, Default_2 etc) otherwise the data migration tool just fails. (it complains about duplicate IDs as far as I remember).

  • When you finally migrate data using bin/magento migrate:data path/to/config.xml then it inserts the source Magento 1 attribute sets into destination Magento 2 database. In my case it inserted ID 112 in attribute_set named Default, which is then also inserted into eav_entity_attribute for entity_type_id = 3.

  • However catalog_category_entity still has attribute_set_id set as 3, while eav_entity_attribute is 112, thanks LitExtension Magento Migration for pointing this out.

The solution is either updating the attribute_set_id in catalog_category_entity table as he suggested or updating the eav_entity_attribute table.

  • Confirm IDs in eav_entity_attribute:
SELECT DISTINCT(attribute_set_id) FROM eav_entity_attribute AS eea 
INNER JOIN eav_attribute as eatt on eea.attribute_id = eatt.attribute_id 
WHERE eea.entity_type_id = 3;

For my installation running

SELECT * FROM catalog_category_entity cce;

will show me that there are IDs for parent_id already attached to 3, in other words, inheriting attribute sets so I had to update the eav_entity_attribute table instead.

UPDATE eav_entity_attribute AS eea SET eea.attribute_set_id = 3
WHERE eea.entity_type_id = 3;

Clear cache and refresh the Category page, or the frontend!

EDIT: (New migration from original answer)

Additional Information

Note: my newer migration changed from attribute_set_id 112 to 121 so keep that in mind the slight difference of my original answer.

What I meant originally (that may not be clear) is that on migration some tables have some entries with the original IDs assigned while the other table related has the migrated ID assigned, so related tables have un-synced data.

Before applying the fixes you might have something like this in your migration attempt:

SELECT DISTINCT(attribute_set_id) FROM eav_entity_attribute AS eea 
INNER JOIN eav_attribute as eatt on eea.attribute_id = eatt.attribute_id
WHERE eea.entity_type_id IN (3);

This shows a n attribute_set_id that migration process attached the Magento 1 migrated data to entity_type_id 3. In my case : attribute_set_id 121

  • Finding the attribute_set_id information:
SELECT attribute_set_id, attribute_set_name FROM eav_attribute_set
WHERE attribute_set_id IN (3, 121);

Gives:

3     Default
121   Migration_Default
  • Determining catalog_category_entity attached attribute_set_id:
SELECT COUNT(entity_id) FROM catalog_category_entity
WHERE attribute_set_id IN (121);

Returns 0, no entries found.

  • However:
SELECT COUNT(entity_id) FROM catalog_category_entity cce 
WHERE attribute_set_id IN (3);

Returns 471, these are all my categories that are detached from attribute_set_id 121.

Two solutions are possible:

  • Update 471 rows inside catalog_category_entity to attribute_set_id 121 and then making sure the backend of categories work correctly.

or easier in my opinion

  • update the eav_entity_attribute table to use attribute_set_id 3 instead of 121 (provided that you remember to make sure the attributes used in 3 and 121 attribute sets look the same). Remember: entity_type_id 3 is categories so only update this for categories, not other entity_type_id entities`
UPDATE eav_entity_attribute AS eea SET eea.attribute_set_id = 3
WHERE eea.entity_type_id = 3;

OTHER TIPS

You need to check the eav_entity_attribute table with eav_entity_type = attribute_set_id = 3 whether the attribute of category is assigned with attribute set

Licensed under: CC-BY-SA with attribution
Not affiliated with magento.stackexchange
scroll top