2

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.


2 Answers 2

5

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;
7
  • Hi! I'm having a similar issue, but from what I've seen in my DB, all entries for catalog_category_entity.attribute_set_id = 3 (apart from root category), where for the row eav_attribute_set.attribute_set_id = 3, eav_attribute_set.entity_type_id = 3, and then in the corresponding row eav_entity_type.entity_type_id = 3, eav_entity_type.entity_type_code = catalog_category, which all seems correct? Are you able to give any further pointers? I'm migrating from 1.9.4.0 -> 2.3.5, the initial migration worked fine, this second migration is producing the same issues (404, data-binding)
    – eddhall
    Sep 29, 2020 at 23:30
  • Hi, not sure any other pointers to give : other than making sure you also checked eav_entity_attribute table to see if the join I specified in my original answer returns results with eav_attribute for entity_type_id = 3 (which you have already confirm is catalog_category. From what I remember on this issue is that migrated Ids were detached for all these mentioned tables, some tables still had 3 but then eav_entity_attribute has 112. I am busy with a new migration and once I get this error again (I'm sure I will!) I will try to assist more if this is still not helfpul. Sep 30, 2020 at 8:37
  • Hey, thanks for the reply, I'll check that thanks! That select was returning empty, I'm guessing it shouldn't?
    – eddhall
    Sep 30, 2020 at 9:53
  • Exactly correct, it should show you some entries, it means that your migrated IDs for eav_entity_attribute knows nothing of entity_type_id 3 in other related tables. For reference, I have ran this just now on a 'semi-working migration' database: attribute_set_id, 3, 99 - so I have two attribute_sets attached to categories 3 Sep 30, 2020 at 9:57
  • I think I'm going to roll back the codebase to 2.3.3 as that was the version the initial successful data migration took place on, probably wasn't a great idea to upgrade the site in the middle of a build anyway
    – eddhall
    Oct 2, 2020 at 9:24
2

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

7
  • Do you mean for instance: 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; This returns ID '112' only, then running SELECT * FROM catalog_category_entity cce WHERE cce.attribute_set_id = 112; returns empty resultset. Is that what you meant? Thank you? May 22, 2020 at 8:23
  • Also, how many attribute_set_id items are there supposed to be? I have about a 100 attribute sets, do they all need to be attached to a category, or is it just one or two specific? May 22, 2020 at 8:48
  • Please run also this query: update catalog_category_entity set attribute_set_id = 121 May 22, 2020 at 8:57
  • 1
    I have done this about five minutes ago just to see the effect. The ID was 112, but when I inspected catalog_category_entity, there was an ID of 3 instead of 112. I did the inverse as your suggestion though : UPDATE eav_entity_attribute AS eea SET eea.attribute_set_id = 3 WHERE eea.entity_type_id = 3; - updating eav_entity_attribute rather, because the inheriting attributes have 'parent_id' as 3. This seems to work! Thanks so much :) May 22, 2020 at 9:04
  • 1
    I have upvoted but since I am a new member, it does not add. I have also accepted the answer. Thanks again. May 22, 2020 at 9:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.