Magento2: Custom category attributes don't show after upgrading to Magento 2.1.0

[JacobDrummond]

Preconditions

1. PHP 5.6.16
2. MySQL 5.6.21-log
3. Magento 2.1.0

4. Nginx 1.4.6

   Steps to reproduce

5. Install Magento 2.0.2

6. Create custom category attributes using in an InstallData/UpgradeData class.
7. Confirm custom attributes show in the category form in Magento 2.0.2

8. Upgrade to Magento 2.1.0

   Expected result

9. Custom category attributes show in the category admin form, as they did in 2.0.2

   Actual result

10. The custom attributes still appear in the eav_attribute_* tables

11. However, custom category attributes don't show in the category admin form. Only the Magento attributes show.

[mhauri]

Same here.

Creating custom attributes for Products and Categories, only show up for Products but not in Categories. As some imports will create both Product and Category attributes, it will be painful if they aren't visible in the admin backend.

[JacobDrummond]

Thank you for confirming, @mhauri.

Did your custom attributes show in admin forms in earlier versions of Magento 2?

[mhauri]

@JacobDrummond yes they did, it wasn't a problem in 2.0.7.

[mrkhoa99]

@JacobDrummond , @mhauri As far as I know, from Magento 2.1, all category attributes are loaded via UI component. You can read more here:
http://magento.stackexchange.com/questions/127709/magento-2-1-how-to-create-category-attrbute-programmatically
http://magento.stackexchange.com/questions/129977/create-multiselect-with-source-model-in-ui-component

[mhauri]

@mrkhoa99 saw that to, but this can't be the way to go, how do you handle attributes created by an import. This would mean every time the import creates an attribute I have to update my codebase to make them visible. Also it works fine in Products, so why handle them differently.

For me this is still a bug and not a feature.

[JacobDrummond]

I agree with @mhauri: the whole point of EAV attributes is they can be determined at runtime.

What is the rationale for using hardcoded UIComponents to build EAV forms?

[JacobDrummond]

Hi @veloraven,

After reading @mrkhoa99's comment, it appears this bug is intended as a feature.

Two things:

• This feature breaks mission-critical functionality for those upgrading to Magento 2.1.0
• It does not appear to be in the 2.1 release notes.

Are release notes intended to be exhaustive? If not, how would you recommend third-party developers become aware of changes like this?

[alankent]

I am not an expert here, but that has never stopped me responding before! I would expect you should be able to upgrade from 2.0 to 2.1 without stuff disappearing. I don't know the details of why this one was changed. Either something was broken, or if we changed something then the upgrade script should migrate the data. In either case having things disappear from the form "sounds like a bug". But I don't know the details here so I may have to eat my hat.

[JacobDrummond]

Hi @alankent,

Adding Category attributes pre-2.1.0

1. Create category attribute in an UpgradeData file, just like Magento_Catalog does.
2. New attribute shows in admin forms simply by being present in Magento_Eav's tables.

Adding Category attributes post-2.1.0

1. Create category attribute in an UpgradeData file, just like Magento_Catalog does.
2. Register the new attribute in module's XML, by extending category_form.xml.
3. New category attribute shows in admin forms.

Upgrade problems

1. Pre 2.1, third-party developers created category attributes the first way. Client's input data, and everyone was happy.
2. Magento 2.1 introduced category_form.xml, yet it didn't appear to be in the 2.1 release notes. There was no XML-generation script to automatically publish custom EAV definitions to the right XML files in php magento setup:upgrade.
3. All custom category attributes disappeared from admin forms. Clients complained that they couldn't edit custom attributes anymore.

Architecture problems

• The whole point of EAV is you can change attribute definitions at run-time, as opposed to write-time.
• Product admin forms implement EAV perfectly. When you alter a product attribute definitions, the changes propagate immediately.
• By contrast, category attributes must be hard-coded in category_form.xml. This goes against EAV's ethos.
• Many people have complained about this architectural decision. For example, here and #5438.

As VP of Architecture, what do you think Magento's EAV strategy should be?

[tanberry]

Hi @mhauri et all. The Magento DevDocs team can look into what info we can add to the docs around attributes and UI Components and elsewhere for handling some of these specific questions. @JacobDrummond , the write-up you have immediately above this comment is a helpful guide to what we missed explaining in docs, thanks for that.

I'm sorry that this change from 2.0.x was reflected in the 2.1 Rel Notes, nor in the Backward Incompatible Changes doc.

Great question, @JacobDrummond about how the community should be told of such changes. This one should have been in the Rel Notes and the Backwards Incompatible Changes document. It is quite likely reflected in the changelog.md file (I haven't yet looked). But maybe there are other ways? Let us know your thoughts, please?

[JacobDrummond]

@tanberry,

Magento 2.1.1 has been released. There is no accompanying "Backwards Incompatible Changes" document. Is this a documentation gap, or are there truly no backwards incompatibilities?

[tanberry]

Hi @JacobDrummond, we are fixing a break in our bamboo builds that stopped the auto-generation of docs covering our backwards incompatible changes... currently they are not published for 2.1.x. ;-( The fix should be ready next week! Along with our recent realization that even patch releases need a "Highlights" section, we will look at how to call out important backwards incompatible changes in patches, ad not just rely on the auto-generated docs.

[ishakhsuvarov]

@JacobDrummond Looks like a solution has been found for the issue a long time ago and this ticket is not active anymore.
I'm closing this report now.

Thank you for collaboration.

[JacobDrummond]

@ishakhsuvarov,

Looks like a solution has been found

category_form.xml is not a good solution, given that attributes are configurable at run-time (not just write-time).